#################################### ## djbdns notes -- www.djbdns.org ## #################################### split horizon FAQ http://homepages.tesco.net./~J.deBoynePollard/FGA/dns-split-horizon.html#TaggedRecords djbdns FAQ http://www.fefe.de/djbdns/ life with djbdns http://lifewithdjbdns.org http://homepages.tesco.net/~J.deBoynePollard/FGA/dns-shaped-firewall-holes.html tinydns.org has a lot great information. such as tinydns/dnscache log format talk .. ##----------- the IP in file /service/tinydns/env/IP should be this computer IP. even so it's a internal computer. ##----------- add our 192.168.0.1 ip into /etc/dhcpd.conf 's name-server entry. then do a dhcpd restart. this way the network clients which running under dhcp will be updated for the nameserver(which holds the dns cache by dnscache) ##----------- DNS server list order it doesn't matterh. Caches will choose one of the servers for your domain at random. ##----------- primary && secondary First note that "primary" and "secondary" have nothing to do with DNS nameserving; they only describe roles in the zone data replication process provided with BIND, called "zone transfer", whose command within the DNS protocol is called is AXFR. A primary offers zone data service; the component in djbdns that offers this is axfrdns. A secondary is a client of such service; the corresponding djbdns component is axfr-get. It pulls zone data into tinydns-data format. ##----------- Having all content DNS servers, for a domain, reachable by the rest of Internet via a single path, that was blocked, was exactly the error that Microsoft made back in January 2001. ##----------- Bounce && DNS for mail server > ...there is one case where third-party DNS service *does* stop the > mail from bouncing. If I am doing my own name serving alone, I also > control the lookups to an off-site backup mail server. If my > connection goes down, my main mail server is indeed not reachable, and > mail does bounce... Mail does not bounce unless it is an _extended_ outage. A DNS error should cause deferrals until the mail is a week old, for instace, not a bounce. > ... unless my backup mail server can instead be found; however, no > one can find my backup mail server since I am the sole lookup for it. > OTOH, if I have 3rd party dns, my backup mail server can still be > found, and mail dumped there until my outage is over. No mail bounces. How long should your backup mail server wait before bouncing the mail back to the sender? Bounces are not bad, they notify the sender that the recipient has not received the message, and should be contacted by some other means if it is important. in fact, I'd be quite happy to see users of such software have most of their e-mail bounce so that they'll recognize the problem and fix it. ##----------- problems i had. /etc/resolv.conf always being rewritten with my isp nameserver that is using DHCP for the gateway machine. but i want to use my own dns server so it is suppose to have 'nameserver 192.168.0.1' in it. as for redhat, we should have 'dhcpcd -R' the dhcp client run during boot. or add PEERDNS=nO to /etc/sysconfig/network-scripts/ifcfg-eth1 it's /etc/sysconfig/network-scripts/ifup control the dhcpcd boot. If /etc/resolv.conf does not exist, dnsqr will try to send queries to 127.0.0.1 where nothing is listening on it. so i got connection refused for command 'dnsqr a cozy300.easyya.com' ##----------- external cache server. i want to query my ISP dns server when the domain is not in my own dnscache. and save it into dnscache afterwards. this should faster than query the top root server for unknown domain. [root@cozy166 dnscache]#more root/servers/@ 24.153.22.66 24.153.22.67 [root@cozy166 dnscache]#echo 1 > env/FORWARDONLY then set the DHCP server to use 192.168.0.1 for all network clients in the dhcp.conf. #------------ test DNS server. working & being used ? #netstat -anp | grep 53 #dnstrace any www.tlprinting.com a.root-servers.net > tlp #dnstracesort < tlp | less http://cr.yp.to/djbdns/run-server.html#testing wait a while, check log in /service/tinydns/log/main/current #------------ old cache solution..a no! >Is there a way to cause the DNS's of the world to flush their cache of my data >and get the current data? Or, do I have to wait until those machines' >TTL eventually flush the data (which doesn't seem to be happening!)? No, there's no way to get remote name servers to flush their caches, short of calling the people who administer them and asking them to stop and restart their servers. You'd normally have to wait until the name servers flushed the problem records according to their TTLs. And no, unfortunately, there's no good way to tell the original source of bad data. Quite often, however, it comes from your parent name servers, particularly if the data are old addresses for your name servers. in djbdns, a patch can be applied to tinydns so cache can be saved and loaded later. ##------------ change nameserver ip The correct procedure to change nameservers is as follows: (1) Set up the zone on the new servers. (2) Add (on old, new, and parent servers) the new NS records. (3) Wait a few days. (4) Remove (on old, new, and parent servers) the old NS records. (5) Wait a few days. (6) Remove the zone from the old servers. Step #3 is important to work around a very widespread BIND cache bug: http://cr.yp.to/djbdns/bugtraq/20000112082807-15140-qmail@cr-yp-to Step #6 is important because the DNS protocol allows the old servers to continue controlling the domain for any amount of time. Caches are under no obligation to double-check with parent servers. Evidently #6 was not carried out here. Without seeing logs, we can't tell whether that's the source of the problem. ##------------- To stop tinydns forever: rm /service/tinydns cd /etc/tinydns svc -dx . ./log ##------------- upgrade a service directory? I need to change ./run Create ./run.new and atomically rename ./run.new to ./run. Then use svc -t . to send a TERM signal to the daemon. supervise will start the new ./run after the daemon exits. It is not safe to edit ./run in place. supervise may restart ./run at any moment. The system may be rebooted at any moment. ##------------- /service/dnscache/log/main/current to see what dnscache is doing behind the scenes, read /service/dnscache/log/main/current. line like 'cached type name' means that dnscache needs some records and found them in the cache. ##------------- commands dnstrace any www.tlprinting.com a.root-servers.net > AOL & dnstracesort < AOL | less ## trace dns lookup. dnsname ip/ptr ## reverse lookup for ip/ptr address. dnsqr [any|ns|mx|etc...] fqdn # list domain name info. dnsqr ns 9.145.135.in-addr.arpa dnsq ptr 2.29.76.64.in-addr.arpa 65.48.28.33 dnsip fqdn # list ip of fqdn. svc -t /service/dnscache ## restart dnscache and completely flush the cache!! svc -du /service/dnscache ## Restart dnscache svc - controls services monitored by supervise `supervise dir` supervise - starts and monitors a service. supervise switches to the directory and starts ./run. It restarts ./run if ./run exits. You can use svc(8) to start ./run and to give other commands to supervise ##------------------------ four steps to checking address First, check that the address is in /service/tinydns/root/data in tinydns-data format: +www.heaven.af.mil:1.8.7.4 IP addresses can be assigned by + lines, = lines, @ lines, . lines, and & lines. Second, use tinydns-get to check that the address is in /service/tinydns/root/data.cdb: cd /service/tinydns/root tinydns-get a www.heaven.af.mil 65.48.28.33 The output will have a line saying answer: www.heaven.af.mil 86400 A 1.8.7.4 If you want to check reverse lookups, replace a www.heaven.af.mil with ptr 4.7.8.1.in-addr.arpa. Third, check that the IP address of tinydns is one of this computer's addresses: cat /service/tinydns/env/IP netstat -n -i Fourth, check that the tinydns service is up: svstat /service/tinydns If tinydns-get reported more than 512 bytes, you also need TCP service; check that the axfrdns service is up. Fifth, ask tinydns about the name: dnsq a www.heaven.af.mil 1.8.7.200 dnsq a www.heaven.af.mil 1.8.7.201 Here 1.8.7.200 and 1.8.7.201 are the IP addresses of your DNS servers. The output of dnsq should be identical to the previous output of tinydns-get. Sixth, ask your DNS cache for the address: dnsqr a www.heaven.af.mil If dnscache can't find the address, the problem is almost certainly that the parent servers haven't delegated the relevant domains to your tinydns. Read the log in /service/dnscache/log/main/current to see which servers dnscache is contacting and what information they are providing. For a thorough debugging scan, use dnstrace ##------------------------ resolv.conf If the host is a name server, the resolv.conf file must exist and contain a nameserver reference to itself as well as a default domain. A domain entry tells the resolver routines which default domain name to append to names that do not end with a . (period). There can be only one domain entry A search entry defines the list of domains to search when resolving a name. Only one domain entry or search entry can be used. If the domain entry is used, the default search list is the default domain. A search entry should be used when a search list other than the default is required. The entry is of the form: we probably don't need the 'search' line in resolv.conf. since what it does is he `search' line specifies what domains should be searched for any host names you want to connect to. might also apply to the "domain' line. assume have 'search subdomain.your-domain.edu your-domain.edu' in resolv.conf. If a client tries to look up foo, then foo.subdomain.your-domain.edu is tried first, then foo.your-domain.edu, and finally foo. You may not want to put in too many domains in the search line, as it takes time to search them all. The example assumes you belong in the domain subdomain.your-domain.edu; your machine, then, is probably called your-machine.subdomain.your-domain.edu. The search line should not contain your TLD (Top Level Domain, `edu' in this case). If you frequently need to connect to hosts in another domain you can add that domain to the search line like this: (Remember to remove the leading spaces, if any) search subdomain.your-domain.edu your-domain.edu other-domain.com and so on. note the lack of periods at the end of the domain names. This is important. ##------------------------------------- dnscache resolver http://cr.yp.to/djbdns/run-cache-x.html setup external cache on cozy166 that is running an external cache for computers in the network. dnscache is used to query site url and cache the answer(ips). so if computer A1 used as the dnscache(aka resolver), the url that client queries will be cached in A1 for later use. first it must be made clear that resolver and authoritive name servers are completely different things. A resolver asks for a domain. (for example yildiz.edu.tr) in a reverse order. It first queries who holds information for .tr. That question is asked to Root-Servers. The answer obtained by resolver and cached in RAM. Following "tr", the root server for "tr" TLD is queried for authoritive name server of "edu.tr". This continues until last authoritive name server is queried (authoritive name server of yildiz.edu.tr). And finally "http://www.yildiz.edu.tr/" is obtained from 193.140.1.1 ( yildiz.edu.tr's authoritive name server) #--------------------------- proxy dns server and content dns server http://homepages.tesco.net./~J.deBoynePollard/FGA/dns-server-roles.html dnscache is a (caching) proxy server, which acts as either a forwarding or a resolving proxy server according to the presence or absence of the FORWARDONLY environment variable Proxy servers act as intermediaries between DNS clients (such as an application calling the gethostbyname() library function) and other DNS servers. They handle outgoing queries. They answer those queries from data that are obtained by sending one or more queries to other DNS servers. Usually they cache those data, reducing traffic and latency in the case that the data are frequently requested. tinydns, axfrdns, walldns, and rbldns are content servers. Content servers publish DNS content to the world. #------------- hidden primary DNS server With the proposed configuration, our two ISP's would host each host a > single "secondary" dns server, getting zone updates from our "hidden" > primary. Our domain registration and whois records would only list the > ISP's name server. Similarly, the zone file(s) would only have NS > records for the ISP's name servers. The true primary server would not > be listed anywhere. many registrars will prompt you to enter a "primary" and a "secondary" name server for your zone, but they have absolutely no way of checking whether a name server you list is actually the zone's primary master. And it's quite common to use a hidden primary setup. #------------ turn off dnscache log or partialy disable. dnscache has logging on by default. A busy dnscache process will keep a hard drive very busy just writing logs so I disable all logging. I do so by editing /usr/local/dnscache/log/run and replacing the logging line with: exec setuidgid bin multilog -* While tuning the cache, it's helpful to log stats. You can easily do that like so: exec setuidgid bin multilog t '-*' +'*stats *' ./main Essentially that discards everything except lines that start with the word stats. Of course, you have to restart the logging process after making changes to run. That's pretty easy too: svc -h /usr/local/dnscache/log man multilog for more detail on this command. #------------ Why are there only 13 root name servers It's a technical limitation. UDP-based DNS messages can be up to 512 bytes long, and only 13 NS records and their corresponding A records will fit into a DNS message that size. #--------------------------- content dns server j> Hello ! I have some difficulties to untertand the j> differences among the three "content" server provided in j> djbdns: tinydns, walldns and rbldns. The primary difference is where the content actually comes from. "tinydns" and "axfrdns" both read the content that the serve up from a CDB format database, the file "root/data.cdb". This is created with "tinydns-data" from a source file (usually "root/data"). They are general purpose content servers, since anything that one likes can be in their database. "walldns" creates the content from scratch on the fly. "walldns" is a specialised content server. It serves up a bidirectional mapping between IP version 4 addresses A.B.C.D and names in the form "D.C.B.A.in-addr.arpa.". (This mapping is what provides the "wall". Anyone trying to perform a reverse lookup of A.B.C.D will receive "D.C.B.A.in-addr.arpa.". Anyone trying to perform a double-reverse lookup will get A.B.C.D back again. Make "walldns" the content DNS server for the reverse lookup domains that your ISP delegates to you, and the rest of Internet will obtain these opaque names if they try to look up your IP addresses.) Since this mapping is fixed, and can be easily calculated upon request, "walldns" has no need for a database. "rbldns" is another specialised content server. It also reads from a database named "root/data.cdb". But this database only holds information about TXT records. ("rbldns" serves up the sort of DNS data that organisations such as ORBS and MAPS publish. Use it if you want to run your own such publically available service, or if you want to run a private whitelist or blacklist of your own for your own SMTP server(s).) Since it is specialised, it can use a database schema that is more efficient and compact than that of the general-purpose content servers' database. ##----------------- Iterative and Recursive lookups In an iterative lookup, the server tells the client "I don't know the answer, try asking ". In a recursive lookup, the server asks one of the other servers on your behalf, and then relays the answer back to you. DNS clients (sometimes called stub resolvers), such as your browser, resolve names by contacting a nearby DNS cache. Recursive servers are usually used by stub resolvers (the name lookup software on end systems). They're configured to ask a specific set of servers, and expect those servers to return an answer rather than a referral. By configuring the servers with recursion, they will cache answers so that if two clients try to look up the same thing it won't have to ask the remote server twice, thus speeding things up. Servers that aren't intended for use by stub resolvers (e.g. the root servers, authoritative servers for domains). Disabling recursion reduces the load on them. ##----------------- glue record more about this on http://cr.yp.to/djbdns/notes.html A glue record is an A record for a name that appears on the right-hand side of a NS record. So, if you have this: sub.foobar.com. IN NS dns.sub.foobar.com. dns.sub.foobar.com. IN A 1.2.3.4 then the second record is a glue record. You need glue records when -- and only when -- you are delegating authority to a nameserver that "lives" in the domain you are delegating *and* you aren't a secondary server for that domain. In other words, in the example above, you need to add an A record for dns.sub.foobar.com since it "lives" in the domain it serves. ( e.g example.com has ns1.example.com delagate to it). @@@ A PROBLEM ABOUT Gluelessness. How much gluelessness must a cache tolerate? Currently dnscache allows three levels of gluelessness. Suppose you're a DNS cache, and you want the address of www.espn.tv. You happen to know the address of a .tv DNS server, so you ask it for the address of www.espn.tv. ``I don't know, but I know that .espn.tv has two DNS servers, ns-1.disney.corp and ns-2.disney.corp,'' it says. ``Try asking them.'' So you contact ns-1.disney.corp. But what's the address of ns-1.disney.corp? You have to put the original question on hold while you search for the address of ns-1.disney.corp. You happen to know an address of a .corp DNS server, so you ask it for the address of ns-1.disney.corp. ``I don't know, but I know that .disney.corp has two DNS servers, zone.espn.tv and night.espn.tv,'' it says. ``Try asking them.'' Bottom line: You can't reach espn.tv, and you can't reach disney.corp. If zone.espn.tv had been a DNS server for .espn.tv, the .tv server would have provided glue for zone.espn.tv, i.e., the IP address of zone.espn.tv. So you would have been able to contact zone.espn.tv There can be trouble even when there are no loops. Suppose a BIND cache is looking up www.espn.tv in the following situation: espn.tv NS ns-1.disney.corp espn.tv NS ns-2.disney.corp disney.corp NS ns-1.disney.corp disney.corp NS ns-2.disney.corp When BIND sees the glueless delegation to ns-1.disney.corp, it drops the www.espn.tv query and begins a ``sysquery'' for ns-1.disney.corp, hoping to have the ns-1.disney.corp address cached by the time the www.espn.tv query is retried. (The BIND developers refer to this bug as ``no query restart.'') Clients generally don't retry more than four times, so an initial query for a domain with four levels of gluelessness will fail; an initial query for a domain with three levels of gluelessness will be very likely to fail, and very slow if it succeeds. #--------------- split horizon( location code ) last part of this is more accurate and correct. >> - In your '%in' line, you only *need* specify the dnscache IP address >> (192.168.0.1 and 65.48.28.33 the external ip). It's up to you to >> decide whether you want to >> allow internal users to directly hit tinydns (for troubleshooting >> purposes, most likely). If all of your internal hosts are using the dnscache, then dnscache will query tinydns *on there behalf*; ergo, tinydns will see requests coming from the dnscache IP address, not from the actual original internal client IP addresses. Creating a dnscache/root/servers/easyya.com file is not a part of setting up djbdns split horizon DNS. If you do not create a dnscache/root/servers/easyya.com file, then your dnscache will follow the usual process to identify the DNS content server for easya.com, which will (should, but right now probably won't, see below) point it back to the tinydns IP address. using a dnscache/root/servers/easyya.com file will allow your internal users to still get information from your tinydns service (for easyya.com) even if your Internet connection is down, since dnscache will not be relying on access to the DNS root servers to identify the DNS content Server for easyya.com. ## in my case, all queries are sent to my isp's dns caching server 24.153.22.66 as one for now. 24.153.22.16 requested and was given data on cozy166.easyya.com In brief: - A request was received by dnscache (not tinydns) on 192.168.0.1 from 192.168.0.12 for resolution of cozy166.easyya.com - dnscache sent to request to the NS's it has cached as authoritative for easyya.com: 24.153.22.[66,67] ([ns,dns].wlfdle.rnc.net.cable.rogers.com) - tinydns received a request from 24.153.22.16 (dns2-a.wlfdle.rnc.net.cable.rogers.com) for resolution of cozy166.easyya.com, and responded; *it replied with nxdomain because it did not see the request coming from an IP address associated with the 'in' location code, which is the location code associated with the only tinydns data entry for cozy166.easyya.com* - dnscache received a reply to it's request and sent its own reply to 192.168.0.12 --- follow this if see conflict with the above --- 192.168.0.1 is the address that dnscache is *listening* to for queries from internal clients. But when dnscache *sends* its own queries, for example to your tinydns, the OS kernel chooses an IP address to use as the source address of the query. This is because you have 0.0.0.0 in dnscache's env/IPSEND. If you want the queries sent by dnscache to come from a particular address, you can put that address in env/IPSEND. but there will be problems resolving outside names if you used 192.168.0.1 as the source address. resolving inside names is fine. So I'd suggest leaving dnscache as it is, and instead modifying your tinydns data so that 65.48.28.33 is also considered part of the internal location: %in:65.48.28.33 You do not have to remove the old %in 192.168.0.1 line; you can use both. ## from http://linuxjournal.com/article.php?sid=7084 dns swtiching. The linchpin of any server migration is the process of moving DNS records. Although people prefer to use names, such as www.lerner.co.il, network connections use numeric IP addresses, such as 69.55.225.93. Translating the human-readable names into computer-usable numbers is the role of DNS, the Domain Name System. Intelligent manipulation of DNS records is a critical part of any server transfer. The main problem with DNS is not host-to-IP translation but, rather, the fact that DNS results are cached. After all, you want to avoid a DNS request to your server for each HTTP request that someone makes. Such requests would place undue load on your server and would unnecessarily delay the servicing of HTTP requests. So when you make a DNS request, you're not actually asking the original, authoritative server for an answer. Rather, you're asking your local DNS server for an answer. If it can provide one from its cache of recent results, it will do so without turning to the main server. In other words, nslookup www.lerner.co.il executes a DNS request against your ISP's DNS server. That server might return a result from its cache, or it might turn to the authoritative server for the lerner.co.il domain. When you move a server from one machine to another, then, you want to reduce the TTL (time to live) setting on the DNS server to a low number, so that DNS servers caching this information do not return false answers. I've found that reducing the TTL to 300 seconds (five minutes) is more than adequate. Once the system has been migrated completely, you can increase the TTL to a more typical value, such as six hours, to reduce the load on your DNS servers. If you are moving your HTTP server from one provider to another, here is an outline of what you can do to have a successful migration: *Make sure a DNS server at your new provider is able and willing to serve DNS (forward and backward) with your current IP addresses and hostnames. That is, the DNS server at your new provider should point people to your old provider. Set the TTL to five minutes. *Update the WHOIS records for your domain, indicating that your new provider is the authoritative DNS server. It may take one or two days for this to filter through the entire DNS system. If your new DNS server is providing results identical to your old one, the only ways to tell if things have worked are to perform a WHOIS lookup or to use nslookup -type=ns yourdomain.com. *Once the WHOIS records have been updated, start moving things over. Make sure that all of the software you need is configured correctly, that all modules are set correctly and that the DNS servers have been updated. If your new DNS server isn't responding to queries for your domain, you will be in deep trouble when the WHOIS records point to the new server as an authority. *When everything seems to be identical (running rsync from the old system to the new one is a good way to ensure that it is), switch the DNS definitions such that the hostname resolves to the new IP address, rather than to the old one. Depending on the type of server you're running, you might want to turn off the HTTP server on the old system to reduce some of the confusion that might occur as a result of the switchover. For example, switching off the old HTTP server before you switch DNS ensures that the log files do not have any overlap, allowing you to append them together and use Webalizer or Analog to look around appropriately. At this stage, everything should be working correctly on the new system. But, you should check as many links as possible, particularly those that invoke CGI programs, server-side includes and nonstandard modules or those that require unusual permissions. As always, your HTTP server's error log is your best friend during this process; if and when things go wrong, you can consult the error log to see what is happening.