ftp.pasteur.org/FAQ/

home *** CD-ROM | disk | FTP | other *** search

/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / internet / tcp-ip / domains-faq / part2 < prev

Wrap

Internet Message Format | 1998-12-17 | 83.1 KB

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.kodak.com!news-nysernet-16.sprintlink.net!news-in-east1.sprintlink.net!news.sprintlink.net!newshub.northeast.verio.net!news.idt.net!newsin.iconnet.net!IConNet!not-for-mail From: cdp2582@hertz.njit.edu (Chris Peckham) Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers,comp.protocols.dns.bind Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2) Supersedes: <cptd-faq-2-911181667@njit.edu> Followup-To: comp.protocols.tcp-ip.domains Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA Lines: 2050 Sender: cdp@chipmunk.iconnet.net Approved: news-answers-request@MIT.EDU Distribution: world Expires: Wednesday, 20 Jan 99 11:47:26 EDT Message-ID: <cptd-faq-2-913826846@njit.edu> References: <cptd-faq-1-913826846@njit.edu> Reply-To: domain-faq@pfmc.net (comp.protocols.tcp-ip.domains FAQ comments) Keywords: BIND,DOMAIN,DNS X-Posting-Frequency: posted during the first week of each month Date: Wed, 16 Dec 1998 16:47:32 GMT NNTP-Posting-Host: chipmunk.iconnet.net NNTP-Posting-Date: Wed, 16 Dec 1998 11:47:32 EDT Xref: senator-bedfellow.mit.edu comp.protocols.tcp-ip.domains:22180 comp.answers:34269 news.answers:146737 comp.protocols.dns.bind:6040 Posted-By: auto-faq 3.3 beta (Perl 5.004) Archive-name: internet/tcp-ip/domains-faq/part2 (Continued from Part 1, where you'll find the introduction and table of contents.) =============================================================================== Section 5. CONFIGURATION Q5.1 Upgrading from 4.9.x to 8.x Q5.2 Changing a Secondary server to a Primary server ? Q5.3 Moving a Primary server to another server Q5.4 How do I subnet a Class B Address ? Q5.5 Subnetted domain name service Q5.6 Recommended format/style of DNS files Q5.7 DNS on a system not connected to the Internet Q5.8 Multiple Domain configuration Q5.9 wildcard MX records Q5.10 How do you identify a wildcard MX record ? Q5.11 Why are fully qualified domain names recommended ? Q5.12 Distributing load using named Q5.13 Round robin IS NOT load balancing Q5.14 Order of returned records Q5.15 resolv.conf Q5.16 How do I delegate authority for sub-domains ? Q5.17 DNS instead of NIS on a Sun OS 4.1.x system Q5.18 Patches to add functionality to BIND Q5.19 How to serve multiple domains from one server Q5.20 hostname and domain name the same Q5.21 Restricting zone transfers Q5.22 DNS in firewalled and private networks Q5.23 Different DNS answers for same RR ----------------------------------------------------------------------------- Question 5.1. Upgrading from 4.9.x to 8.x Date: Wed Jul 9 22:00:07 EDT 1997 Q: Help ! How do I use the Completely new configuration syntax in BIND 8 ? I've attempted to upgrade bind from 4.9.5 to 8.1, but unfortunately it didn't seem to like the same config/zone files.. is this normal or should 8.1 be able to read the same files as 4.9.5 did? A: If you then look in doc/html/config.html, you will find directions on how to convert a 4.9.x .boot file to 8.x .conf file, as well as directions on how to utilize all of the new features of the 8.x .conf file format. ----------------------------------------------------------------------------- Question 5.2. Changing a Secondary server to a Primary server ? Date: Fri Jul 5 23:54:35 EDT 1996 For 4.8.3, it's prudent to kill and restart following any changes to named.boot. In BIND 4.9.3, you only have to kill and restart named if you change a primary zone to a secondary or v-v, or if you delete a zone and remain authoritative for its parent. Every other case should be taken care of by a HUP. (Ed. note: 4.9.3b9 may still require you to kill and restart the server due to some bugs in the HUP code). You will also need to update the server information on the root servers. You can do this by filing a new domain registration form to inform InterNIC of the change. They will then update the root server's SOA records. This process usually takes 10-12 business days after they receive the request. ----------------------------------------------------------------------------- Question 5.3. Moving a Primary server to another server Date: Fri Jul 5 23:54:35 EDT 1996 The usual solution is to move the primary to ns.newserver.com, and have ns.oldserver.com be configured as a secondary server until the change to the root servers takes place after the request has been made to the InterNIC. If you are moving to a different ISP which will change your IP's, the recommend setting for the SOA that would minimize problems for your name servers using the old settings can be done as follows: Gradually lower the TTL value in your SOA (that's the last one of the five numbers) to always be equal to the time left until you change over. (assuming that none of your resource records have individual TTL's set, if so, do likewise with them.) So, the day before, lower to 43200 seconds (12 hours). Then lower every few hours to be the time remaining until the change-over. So, an hour before the change, you may just want to lower it all the way to 60 seconds or so. That way no one can cache information past the change-over. After the change, start gradually incrementing the TTL value, because you'll probably be making changes to work out problems. Once everything stabilizes, move the TTL up to whatever your normal values are. To minimize name servers from using the "old settings", you can do the same thing with the "refresh" interval in the SOA (the second number of the SOA). That will tell the secondaries to refresh every X seconds. Lower that value as you approach the changeover date. You probably don't want to go much below an hour or you'll start the primary thrashing as all the secondaries perpetually refresh. Also see the answer to the "How can I change the IP address of our server ?" in the INTRODUCTION section. ----------------------------------------------------------------------------- Question 5.4. How do I subnet a Class B Address ? Date: Mon Jun 15 23:21:39 EDT 1998 That you need to subnet at all is something of a misconception. You can also think of a class B network as giving you 65,534 individual hosts, and such a network will work. You can also configure your class B as 16,384 networks of 2 hosts each. That's obviously not very practical, but it needs to be made clear that you are not constrained by the size of an octet (remember that many older devices would not work in a network configured in this manner). So, the question is: why do you need to subnet? One reason is that it is easier to manage a subnetted network, and in fact, you can delegate the responsibility for address space management to local administrators on the various subnets. Also, IP based problems will end up localized rather than affecting your entire network. If your network is a large backbone with numerous segments individually branching off the backbone, that too suggests subnetting. Subnetting can also be used to improve routing conditions. You may wish to partition your network to disallow certain protocols on certain segments of your net. You can, for example, restrict IP or IPX to certain segments only by adding a router routing high level protocols, and across the router you may have to subnet. Finally, as far as how many subnets you need depends on the answer to the above question. As far as subnet masks are concerned, the mask can be anything from 255.0.0.0 to 255.255.255.252. You'll probably be looking at 9 or 10 bits for the subnet (last octet 128 or 192 respectively). RFC 1219 discusses the issue of subnetting very well and leaves the network administrator with a large amount of flexibility for future growth. (The following section was contributed by Berislav Todorovic.) A user or an ISP, having a whole /16 sized IP block (former "Class B") network assigned/allocated, has the responsibility of maintaining the reverse domain for the whole network. That policy is currently applied by all regional Internet registries (RIPE NCC, ARIN, APNIC). In other words, if you're assigned a whole "B class" (say, 10.91/16), you're in charge for the whole 91.10.IN-ADDR.ARPA zone. This zone may be organized using two methods, according to the network topology being in use. The first, "brute force" method is to place all PTR records directly into a single zone file. Example: $origin 91.10.in-addr.arpa @ IN SOA (usual stuff) IN NS ns1.mydomain.com. IN NS ns2.mydomain.com. 1.1 IN PTR one-1.mydomain.com. ; ---> 10.91.1.1 2.1 IN PTR one-2.mydomain.com. ; ---> 10.91.1.2 ... 254.1 IN PTR one-254.mydomain.com. ; ---> 10.91.1.254 1.2 IN PTR two-1.mydomain.com. ; ---> 10.91.2.1 While this approach may look simple in the networks with a central management authority (say, campus networks), maintaining such a zone file becomes more and more difficult in the more complex environment. Thus, this becomes a bad method. Furthermore, if you're an ISP, it is more likely that a /16 network will be subnetted and its subnets be assigned to your customers. Therefore, another "smarter" approach is to delegate portions of the reverse domain 91.10.IN-ADDR.ARPA to the end users of the subnets of 10.91/16. There would only be NS records in the zone file, while PTR record insertion would be the responsibility of the end users. For example, if you assign: * 10.91.0.0/22 (10.91.0.0 - 10.91.3.255) to Customer-A.COM * 10.91.4.0/23 (10.91.4.0 - 10.91.5.255) to Customer-B.COM * 10.91.7.0/24 (10.91.7.0 - 10.91.7.255) to Customer-C.COM then each customer will maintain zone files for the reverse domains of their own networks (say, Customer C will maintain the zone 7.91.10.IN-ADDR.ARPA, customer B their 2 zones, Customer A their own 4 zones). In this constellation, the zone file for reverse domain 91.10.IN-ADDR.ARPA will look like this: $origin 91.10.in-addr.arpa @ IN SOA (usual stuff) IN NS ns1.mydomain.com. IN NS ns2.mydomain.com. ; --- Customer-A.COM 0 IN NS ns.customer-A.com. IN NS ns1.mydomain.com. 1 IN NS ns.customer-A.com. IN NS ns1.mydomain.com. 2 IN NS ns.customer-A.com. IN NS ns1.mydomain.com. 3 IN NS ns.customer-A.com. IN NS ns1.mydomain.com. ; --- Customer-B.COM 4 IN NS ns.customer-B.com. IN NS ns1.mydomain.com. 5 IN NS ns.customer-B.com. IN NS ns1.mydomain.com. ; --- Customer-C.COM 7 IN NS ns.customer-C.com. IN NS ns1.mydomain.com. The zone file of the Customer C reverse domain would look like this: $origin 7.91.10.in-addr.arpa @ IN SOA (usual stuff) IN NS ns.customer-C.com. IN NS ns1.mydomain.com. 1 IN PTR one.customer-C.com. 2 IN PTR two.customer-C.com. 3 IN PTR three.customer-C.com. ... ----------------------------------------------------------------------------- Question 5.5. Subnetted domain name service Date: Thu Jul 16 10:50:41 EDT 1998 If you are looking for some examples of handling subnetted class C networks as separate DNS domains, see RFC 2317 for more information. Details follow- You need to delegate down to the fourth octet, so you will have one domain per IP address ! Here is how you can subdelegate a in-addr.arpa address for non-byte aligned subnet masks: Take as an example the net 192.1.1.x, and example subnet mask 255.255.255.240. We first define the domain for the class C net, $origin 1.1.192.in-addr.arpa @ SOA (usual stuff) @ ns some.nameserver ns some.other.nameserver ; delegate a subdomain one ns one.nameserver ns some.nameserver ; delegate another two ns two.nameserver ns some.nameserver ; CNAME pointers to subdomain one 0 CNAME 0.one 1 CNAME 1.one ; through 15 CNAME 15.one ; CNAME pointers to subdomain two 16 CNAME 16.two 17 CNAME 17.two 31 CNAME 31.two ; CNAME as many as required. Now, in the delegated nameserver, one.nameserver $origin one.1.1.192.in-addr.arpa @ SOA (usual stuff) NS one.nameserver NS some.nameserver ; secondary for us 0 PTR onenet.one.domain 1 PTR onehost.one.domain ; through 15 PTR lasthost.one.domain And similar for the two.1.1.192.in-addr.arpa delegated domain. There is additional documentation and a perl script that may be used for this purpose available for anonymous ftp from: ftp.is.co.za : /networking/ip/dns/gencidrzone/gencidrzone ----------------------------------------------------------------------------- Question 5.6. Recommended format/style of DNS files Date: Sun Nov 27 23:32:41 EST 1994 This answer is quoted from an article posted by Paul Vixie: I've gone back and forth on the question of whether the BOG should include a section on this topic. I know what I myself prefer, but I'm wary of ramming my own stylistic preferences down the throat of every BOG reader. But since you ask :-)... Create /var/named. If your system is too old to have a /var, either create one or use /usr/local/adm/named instead. Put your named.boot in it, and make /etc/named.boot a symlink to it. If your system doesn't have symlinks, you're S-O-L (but you knew that). In named.boot, put a "directory" directive that specifies your actual BIND working directory: directory /var/named All relative pathnames used in "primary", "secondary", and "cache" directives will be evaluated relative to this directory. Create two subdirectories, /var/named/pri and /var/named/sec. Whenever you add a "primary" directive to your named.boot, use "pri/WHATEVER" as the path name. And then put the primary zone file into "pri/WHATEVER". Likewise when you add "secondary" directives, use "sec/WHATEVER" and BIND (really named-xfer) will create the files in that subdirectory. (Variations: (1) make a midlevel directory "zones" and put "pri" and "sec" into it; (2) if you tend to pick up a lot of secondaries from a few hosts, group them together in their own subdirectories -- something like /var/named/zones/uucp if you're a UUCP Project name server.) For your forward files, name them after the zone. dec.com becomes "/var/named/zones/pri/dec.com". For your reverse files, name them after the network number. 0.1.16.in-addr.arpa becomes "/var/named/zones/pri/16.1.0". When creating or maintaining primary zone files, try to use the same SOA values everywhere, except for the serial number which varies per zone. Put a $ORIGIN directive at the top of the primary zone file, not because its needed (it's not since the default origin is the zone named in the "primary" directive) but because it make it easier to remember what you're working on when you have a lot of primary zones. Put some comments up there indicating contact information for the real owner if you're proxying. Use RCS and put the "Id" in a ";" comment near the top of the zone file. The SOA and other top level information should all be listed together. But don't put IN on every line, it defaults nicely. For example: ============== @ IN SOA gw.home.vix.com. postmaster.vix.com. ( 1994082501 ; serial 3600 ; refresh (1 hour) 1800 ; retry (30 mins) 604800 ; expire (7 days) 3600 ) ; minimum (1 hour) NS gw.home.vix.com. NS ns.uu.net. NS uucp-gw-1.pa.dec.com. NS uucp-gw-2.pa.dec.com. MX 10 gw.home.vix.com. MX 20 uucp-gw-1.pa.dec.com. MX 20 uucp-gw-1.pa.dec.com. ============== I don't necessarily recommend those SOA values. Not every zone is as volatile as the example shown. I do recommend that serial number format; it's in date format with a 2-digit per-day revision number. This format will last us until 2147 A.D. at which point I expect a better solution will have been found :-). (Note that it would last until 4294 A.D. except that there are some old BINDs out there that use a signed quantity for representing serial number internally; I suppose that as long as none of these are still running after 2047 A.D., that we can use the above serial number format until 4294 A.D., at which point a better solution will HAVE to be found.) You'll note that I use a tab stop for "IN" even though I never again specify it. This leaves room for names longer than 7 bytes without messing up the columns. You might also note that I've put the MX priority and destination in the same tab stop; this is because both are part of the RRdata and both are very different from MX which is an RRtype. Some folks seem to prefer to group "MX" and the priority together in one tab stop. While this looks neat it's very confusing to newcomers and for them it violates the law of least astonishment. If you have a multi-level zone (one which contains names that have dots in them), you can use additional $ORIGIN statements but I recommend against it since there is no "back" operator. That is, given the above example you can add: ============= $ORIGIN home gw A 192.5.5.1 ============= The problem with this is that subsequent RR's had better be somewhere under the "home.vix.com" name or else the $ORIGIN that introduces them will have to use a fully qualified name. FQDN $ORIGIN's aren't bad and I won't be mad if you use them. Unqualified ones as shown above are real trouble. I usually stay away from them and just put the whole name in: ============= gw.home A 192.5.5.1 ============= In your reverse zones, you're usually in some good luck because the owner name is usually a single short token or sometimes two. ============= $ORIGIN 5.5.192.in-addr.arpa. @ IN SOA ... NS ... 1 PTR gw.home.vix.com. ========================================= $ORIGIN 1.16.in-addr.arpa. @ IN SOA ... NS ... 2.0 PTR gatekeeper.dec.com. ============= It is usually pretty hard to keep your forward and reverse zones in sync. You can avoid that whole problem by just using "h2n" (see the ORA book, DNS and BIND, and its sample toolkit, included in the BIND distribution or on ftp.uu.net (use the QUOTE SITE EXEC INDEX command there to find this -- I never can remember where it's at). "h2n" and many tools like it can just read your old /etc/hosts file and churn it into DNS zone files. (May I recommend contrib/decwrl/mkdb.pl from the BIND distribution?) However, if you (like me) prefer to edit these things by hand, you need to follow the simple convention of making all of your holes consistent. If you use 192.5.5.1 and 192.5.5.3 but not (yet) 192.5.5.2, then in your forward file you will have something like ============= ... gw.home A 192.5.5.1 ;avail A 192.5.5.2 pc.home A 192.5.5.3 ============= and in your reverse file you will have something like ============= ... 1 PTR gw.home.vix.com. ;2 PTR avail 3 PTR pc.home.vix.com. ============= This convention will allow you to keep your sanity and make fewer errors. Any kind of automation (h2n, mkdb, or your own perl/tcl/awk/python tools) will help you maintain a consistent universe even if it's also a complex one. Editing by hand doesn't have to be deadly but you MUST take care. ----------------------------------------------------------------------------- Question 5.7. DNS on a system not connected to the Internet Date: Sun Nov 27 23:32:41 EST 1994 You need to create your own root domain name server until you connect to the internet. Your roots need to delegate to mydomain.com and any in-addr.arpa subdomains you might have, and that's about it. As soon as you're connected, rip out the fake roots and use the real ones. It does not actually have to be another server pretending to be the root. You can set up the name server so that it is primary for each domain above you and leave them empty (i.e. you are foo.bar.com - claim to be primary for bar.com and com) If you connect intermittently and want DNS to work when you are connected, and "fail" when you are not, you can point the resolver at the name server at the remote site and if the connection (SLIP/PPP) isn't up, the resolver doesn't have a route to the remote server and since there's only one name server in resolv.conf, the resolver quickly backs off the using /etc/hosts. No problem. You could do the same with multiple name server and a resolver that did configurable /etc/hosts fallback. ----------------------------------------------------------------------------- Question 5.8. Multiple Domain configuration Date: Fri Dec 2 15:40:49 EST 1994 If you want to have multiple domain names pointing to the same destination, such as: ftp ftp.biff.com connects user to -> ftp.biff.com ftp ftp.fred.com connects user to -> ftp.biff.com ftp ftp.bowser.com connects user to -> ftp.biff.com You may do this by using CNAMEs: ftp.bowser.com. IN CNAME ftp.biff.com. You can also do the same thing with multiple A records. ----------------------------------------------------------------------------- Question 5.9. wildcard MX records Date: Sun Nov 27 23:32:41 EST 1994 Does BIND not understand wildcard MX records such as the following? *.foo.com MX 0 mail.foo.com. No. It just doesn't work. Explicit RR's at one level of specificity will, by design, "block" a wildcard at a lesser level of specificity. I suspect that you have an RR (an A RR, perhaps?) for "bar.foo.com" which is blocking the application of your "*.foo.com" wildcard. The initial MX query is thus failing (NOERROR but an answer count of 0), and the backup query finds the A RR for "bar.foo.com" and uses it to deliver the mail directly (which is what you DIDN'T want it to do). Adding an explicit MX RR for the host is therefore the right way to handle this situation. See RFC 1034, Section 4.3.3 ("Wildcards") for more information on this "blocking" behavior, along with an illustrative example. See also RFC 974 for an explanation of standard mailer behavior in the face of an "empty" response to one's MX query. Basically, what it boils down to is, there is no point in trying to use a wildcard MX for a host which is otherwise listed in the DNS. It just doesn't work. ----------------------------------------------------------------------------- Question 5.10. How do you identify a wildcard MX record ? Date: Thu Dec 1 11:10:39 EST 1994 You don't really need to "identify" a wildcard MX RR. The precedence for u@dom is: exact match MX exact match A wildcard MX One way to implement this is to query for ("dom",IN,MX) and if the answer name that comes back is "*." something, you know it's a wildcard, therefore you know there is no exact match MX, and you therefore query for ("dom",IN,A) and if you get something, use it. if you don't, use the previous wildcard response. RFC 974 explains this pretty well. ----------------------------------------------------------------------------- Question 5.11. Why are fully qualified domain names recommended ? Date: Sun Nov 27 23:32:41 EST 1994 The documentation for BIND 4.9.2 says that the hostname should be set to the full domain style name (i.e host.our.domain rather than host). What advantages are there in this, and are there any adverse consequences if we don't? Paul Vixie likes to do it :-) He lists a few reasons - * Sendmail can be configured to just use Dj$w rather than Dj$w.mumble where "mumble" is something you have to edit in by hand. Granted, most people use "mumble" elsewhere in their config files ("tack on local domain", etc) but why should it be a requirement ? * The real reason is that not doing it violates a very useful invariant: gethostbyname(gethostname) == gethostbyaddr(primary_interface_address) If you take an address and go "backwards" through the PTR's with it, you'll get a FQDN, and if you push that back through the A RR's, you get the same address. Or you should. Many multi-homed hosts violate this uncaringly. If you take a non-FQDN hostname and push it "forwards" through the A RR's, you get an address which, if you push it through the PTR's, comes back as a FQDN which is not the same as the hostname you started with. Consider the fact that, absent NIS/YP, there is no "domainname" command analogous to the "hostname" command. (NIS/YP's doesn't count, of course, since it's sometimes-but-only-rarely the same as the Internet domain or subdomain above a given host's name.) The "domain" keyword in resolv.conf doesn't specify the parent domain of the current host; it specifies the default domain of queries initiated on the current host, which can be a very different thing. (As of RFC 1535 and BIND 4.9.2's compliance with it, most people use "search" in resolv.conf, which overrides "domain", anyway.) What this means is that there is NO authoritative way to programmatically discover your host's FQDN unless it is set in the hostname, or unless every application is willing to grovel the "netstat -in" tables, find what it hopes is the primary address, and do a PTR query on it. FQDN /bin/hostnames are, intuitively or not, the simplest way to go. ----------------------------------------------------------------------------- Question 5.12. Distributing load using named Date: Thu Jul 16 10:42:05 EDT 1998 When you attempt to distribute the load on a system using named, the first response be cached, and then later queries use the cached value (This would be for requests that come through the same server). Therefore, it can be useful to use a lower TTL on records where this is important. You can use values like 300 or 500 seconds. If your local caching server has ROUND_ROBIN, it does not matter what the authoritative servers have -- every response from the cache is rotated. But if it doesn't, and the authoritative server site is depending on this feature (or the old "shuffle-A") to do load balancing, then if one doesn't use small TTLs, one could conceivably end up with a really nasty situation, e.g., hundreds of workstations at a branch campus pounding on the same front end at the authoritative server's site during class registration. Not nice. Paul Vixie has an example of the ROUND_ROBIN code in action. Here is something that he wrote regarding his example: I want users to be distributed evenly among those 3 hosts. Believe it or not :-), BIND offers an ugly way to do this. I offer for your collective amusement the following snippet from the ugly.vix.com zone file: hydra cname hydra1 cname hydra2 cname hydra3 hydra1 a 10.1.0.1 a 10.1.0.2 a 10.1.0.3 hydra2 a 10.2.0.1 a 10.2.0.2 a 10.2.0.3 hydra3 a 10.3.0.1 a 10.3.0.2 a 10.3.0.3 Note that having multiple CNAME RR's at a given name is meaningless according to the DNS RFCs but BIND doesn't mind (in fact it doesn't even complain). If you call gethostbyname("hydra.ugly.vix.com") (try it!) you will get results like the following. Note that there are two round robin rotations going on: one at ("hydra",CNAME) and one at each ("hydra1",A) et al. I used a layer of CNAME's above the layer of A's to keep the response size down. If you don't have nine addresses you probably don't care and would just use a pile of CNAME's pointing directly at real host names. {hydra.ugly.vix.com name: hydra2.ugly.vix.com aliases: hydra.ugly.vix.com addresses: 10.2.0.2 10.2.0.3 10.2.0.1 {hydra.ugly.vix.com name: hydra3.ugly.vix.com aliases: hydra.ugly.vix.com addresses: 10.3.0.2 10.3.0.3 10.3.0.1 {hydra.ugly.vix.com name: hydra1.ugly.vix.com aliases: hydra.ugly.vix.com addresses: 10.1.0.2 10.1.0.3 10.1.0.1 {hydra.ugly.vix.com name: hydra2.ugly.vix.com aliases: hydra.ugly.vix.com addresses: 10.2.0.3 10.2.0.1 10.2.0.2 {hydra.ugly.vix.com name: hydra3.ugly.vix.com aliases: hydra.ugly.vix.com addresses: 10.3.0.3 10.3.0.1 10.3.0.2 Please note that this is not a recommended practice and will not work with modern BIND unless you have the entry "multiple-cnames yes" in your named.conf file. ----------------------------------------------------------------------------- Question 5.13. Round robin IS NOT load balancing Date: Mon Mar 9 22:10:51 EST 1998 Round robin != load balancing. It's a very crude attempt at load balancing, and a method that is possible without breaking DNS protocols. If a host is down that is included in a round robin list, then connections to that particular host will fail. In addition, true load balancing should take into consideration the actual LOAD on the system. Information on one such technique, implemented by Roland J. Schemers III at Stanford, may be found at http://www-leland.stanford.edu/~schemers/docs/lbnamed/lbnamed.html. Additional information may be found in RFC 1794. MultiNet for OpenVMS also includes this feature. ----------------------------------------------------------------------------- Question 5.14. Order of returned records Date: Tue Apr 8 20:21:02 EDT 1997 Sorting, is the *resolver's* responsibility. RFC 1123: 6.1.3.4 Multihomed Hosts When the host name-to-address function encounters a host with multiple addresses, it SHOULD rank or sort the addresses using knowledge of the immediately connected network number(s) and any other applicable performance or history information. DISCUSSION: The different addresses of a multihomed host generally imply different Internet paths, and some paths may be preferable to others in performance, reliability, or administrative restrictions. There is no general way for the domain system to determine the best path. A recommended approach is to base this decision on local configuration information set by the system administrator. In BIND 4.9.x's resolver code, the "sortlist" directive in resolv.conf can be used to configure this. The directive may also be used in the named.boot as well. ----------------------------------------------------------------------------- Question 5.15. resolv.conf Date: Fri Feb 10 15:46:17 EST 1995 The question was asked one time, "Why should I use 'real' IP addresses in /etc/resolv.conf and not 0.0.0.0 or 127.0.0.1" ? Paul Vixie writes on the issue of the contents of resolv.conf: It's historical. Some kernels can't unbind a UDP socket's source address, and some resolver versions (notably not including BIND 4.9.2 or 4.9.3's) try to do this. The result can be wide area network traffic with 127.0.0.1 as the source address. Rather than giving out a long and detailed map of version/vendor combinations of kernels/BINDs that have/don't this problem, I just tell folks not to use 127.0.0.1 at all. 0.0.0.0 is just an alias for the first interface address assigned after a system boot, and if that interface is a up-and-down point to point link (PPP, SLIP, whatever), there's no guarantee that you'll be able to reach yourself via 0.0.0.0 during the entire lifetime of any system instance. On most kernels you can finesse this by adding static routes to 127.0.0.1 for each of your interface addresses, but some kernels don't like that trick and rather than give a detailed map of which ones work and which ones don't, I just globally recommend against 0.0.0.0. If you know enough to know that 127.0.0.1 or 0.0.0.0 is safe on your kernel and resolver, then feel free to use them. If you don't know for sure that it is safe, don't use them. I never use them (except on my laptop, whose hostname is "localhost" and whose 0.0.0.0 is 127.0.0.1 since I ifconfig my lo0 before any other interface). The operational advantage to using a real IP address rather than an wormhole like 0.0.0.0 or 127.0.0.1, is that you can then "rdist" or otherwise share identical copies of your resolv.conf on all the systems on any given subnet, not all of which will be servers. The problem was with older versions of the resolver (4.8.X). If you listed 127.0.0.1 as the first entry in resolv.conf, and for whatever reason the local name server wasn't running and the resolver fell back to the second name server listed, it would send queries to the name server with the source IP address set to 127.0.0.1 (as it was set when the resolver was trying to send to 127.0.0.1--you use the loopback address to send to the loopback address). ----------------------------------------------------------------------------- Question 5.16. How do I delegate authority for sub-domains ? Date: Mon Nov 10 22:57:54 EST 1997 When you start having a very big domain that can be broken into logical and separate entities that can look after their own DNS information, you will probably want to do this. Maintain a central area for the things that everyone needs to see and delegate the authority for the other parts of the organization so that they can manage themselves. Another essential piece of information is that every domain that exists must have it NS records associated with it. These NS records denote the name servers that are queried for information about that zone. For your zone to be recognized by the outside world, the server responsible for the zone above you must have created a NS record for your your new servers (NOTE that the new servers DO NOT have to be in the new domain). For example, putting the computer club onto the network and giving them control over their own part of the domain space we have the following. The machine authorative for gu.uwa.edu.au is mackerel and the machine authorative for ucc.gu.uwa.edu.au is marlin. in mackerel's data for gu.uwa.edu.au we have the following @ IN SOA ... IN A 130.95.100.3 IN MX mackerel.gu.uwa.edu.au. IN MX uniwa.uwa.edu.au. marlin IN A 130.95.100.4 ucc IN NS marlin.gu.uwa.edu.au. IN NS mackerel.gu.uwa.edu.au. Marlin is also given an IP in our domain as a convenience. If they blow up their name serving there is less that can go wrong because people can still see that machine which is a start. You could place "marlin.ucc" in the first column and leave the machine totally inside the ucc domain as well. The second NS line is because mackerel will be acting as secondary name server for the ucc.gu domain. Do not include this line if you are not authorative for the information included in the sub-domain. To delegate authority for PTR records, the same concepts apply. stub 10.168.192.in-addr.arpa <subdomain server addr> db.192.168.10 may be added to your primary server's named.boot in recent versions of bind. In other versions (and recent ones :-) ), the following lines may be added to the db.192.168.10 zone file to perform the same function: xxx IN NS <server1> xxx IN NS <server2> xxx IN NS <server3> ; if needed ... xxx IN NS <serverN> ; if needed ----------------------------------------------------------------------------- Question 5.17. DNS instead of NIS on a Sun OS 4.1.x system Date: Sat Dec 7 01:14:17 EST 1996 Comments relating to running bind 4.9.x on a Sun OS 4.1.x system and the effect on sendmail, ftp, telnet and other TCP/IP services bypassing NIS and directly using named is documented quite well in the comp.sys.sun.admin FAQ in questions one and two. You can get them from: * ftp.ece.uc.edu : /pub/sun-faq/FAQs/sun-faq.general * http://www.cis.ohio-state.edu/hypertext/faq/usenet/comp-sys-sun-faq as well as from rtfm.mit.edu in the usual place, etc. ----------------------------------------------------------------------------- Question 5.18. Patches to add functionality to BIND Date: Wed Jan 14 11:57:20 EST 1998 There are others, but these are listed here: * When using the round robin DNS and assigning 3 IPs to a host (for example), a process to guarantee that all 3 IPs are reachable may be found at http://www-leland.stanford.edu/~schemers/docs/lbnamed/lbnamed.html * Patches for 4.9.3-REL that will support the IPv6 AAAA record format may be found at ftp.inria.fr : /network/ipv6/ This is built into more recent versions of BIND (after 4.9.5?) * A patch for 4.9.3-REL that will allow you to turn off forwarding of information from my server may be found at ftp.vix.com : /pub/bind/release/4.9.3/contrib/noforward.tar.gz Also look at ftp.is.co.za : /networking/ip/dns/bind/contrib/noforward.tar.gz * How do I tell a server to listen to a particular interface to listen and respond to DNS queries on ? Mark Andrews has a patch that will tell a 4.9.4 server to listen to a particular interface and respond to DNS queries. It may be found at an unofficial location: http://www.ultra.net/~jzp/andrews.patch.txt This is built into BIND 8.1.1. * A patch to implement "selective forwarding" from Todd Aven at http://www.dns.net/dnsrd/servers.html. ----------------------------------------------------------------------------- Question 5.19. How to serve multiple domains from one server Date: Tue Nov 5 23:44:02 EST 1996 Most name server implementations allow information about multiple domains to be kept on one server, and questions about those domains to be answered by that one server. For instance, there are many large servers on the Internet that each serve information about more than 1000 different domains. To be completely accurate, a server contains information about zones, which are parts of domains that are kept as a single unit. [Ed note: for a definition of zones and domains, see Section 2: The Name Service in the "Name Server Operations Guide" included with the BIND 4.9.5 distribution.] In the configuration of the name server, the additional zones need to be specified. An important consideration is whether a particular server is primary or secondary for any specific zone--a secondary server maintains only a copy of the zone, periodically refreshing its copy from another, specified, server. In BIND, to set up a server as a secondary server for the x.y.z zone, to the configuration file /etc/named.boot add the line secondary x.y.z 10.0.0.1 db.x.y.z where 10.0.0.1 is the IP address of the server that the zone will be copied from, and db.x.y.z is a local filename that will contain the copy of the zone. If this is a question related to how to set up multiple IP numbers on one system, which you do not need to do to act as a domain server for multiple domains, see http://www.thesphere.com/%7Edlp/TwoServers/. ----------------------------------------------------------------------------- Question 5.20. hostname and domain name the same Date: Wed Jul 9 21:47:36 EDT 1997 Q: I have a subdomain sub.foobar.com. I would like to name a host sub.foobar.com. It should also be the mail relay for all hosts in sub.foobar.com. How do I do this ? A: You would add an A record for sub.foobar.com, and multiple MX records pointing to this host (sub.foobar.com). For example: sub.foobar.com. IN A 1.2.3.4 ; address of host ; foo.sub.foobar.com. IN MX 10 sub.foobar.com. bar.sub.foobar.com. IN MX 10 sub.foobar.com. The host, sub.foobar.com, may also need to be to configured to understand that mail addressed to user@sub.foobar.com and possibly other sub.foobar.com hosts should be treated as local. ----------------------------------------------------------------------------- Question 5.21. Restricting zone transfers Date: Wed Jan 14 12:16:35 EST 1998 Q: How do I restrict my zone transfers to my secondaries or other trusted hosts? A: Use the 'xfrnets' directive within the named.boot file or the 'secure_zone' TXT RR within a zone file. The BOG has more information on both of these options. As an example within an 4.9.x named.boot file: xfernets 10.1.2.0&255.255.255.0 44.66.10.0&255.255.255.0 Only Nameservers on these networks will be able to do zone transfers from the server with this configuration. Please note that 'secure_zone' restricts all access to the containing zone, as well as restricting zone transfers :-) . BIND 8.x supports restricting zone transfers on a per-zone basis in the named.conf file, whereas BIND 4.9.x only supports xfrnets as a global option. ----------------------------------------------------------------------------- Question 5.22. DNS in firewalled and private networks Date: Mon Sep 14 22:15:16 EDT 1998 (The following section was contributed by Berislav Todorovic) When talking about private networks, we distinguish between two cases: * Networks consisting of firewall-separated private and public subnetworks * Same domain name used in private and public part of the network * Different domain names used in the public and private subnetwork * Closed networks, not connected the Internet at all * The first case of the "Same domain name", we're talking about DNS configuration, usually referred to as "split DNS". In this case, two different DNS servers (or two separate DNS processes on the same multi-homed machine) have to be configured. One of them ("private DNS") will serve the internal network and will contain data about all hosts in the private part of the network. The other one ("public DNS") will serve Internet users and will contain only the most necessary RR's for Internet users (like MX records for email exchange, A and CNAME records for public Web servers, records for other publicly accessible hosts etc.). Both of them will be configured as primary for the same corporate domain (e.g. DOMAIN.COM). The public DNS will be delegated with the appropriate NIC as authoritative for domain DOMAIN.COM. Private DNS - resolves names from DOMAIN.COM for hosts inside the private network. If asked for a name outside DOMAIN.COM, they should forward the request to the public DNS (forwarders line should be used in the boot file). They should NEVER contact a root DNS on the Internet. The boot file for the private DNS should, therefore, be: primary domain.com ZONE.domain.com primary 1.10.in-addr.arpa REV.10.1 forwarders 172.16.12.10 slave Public DNS - resolves names from DOMAIN.COM for hosts on the public part of the network. If asked for a name outside DOMAIN.COM they should contact root DNS servers or (optionally) forward the request to a forwarder on the ISP network. Boot file for the public DNS should be of the form: primary domain.com ZONE.domain.com primary 12.16.172.in-addr.arpa REV.172.16.12 ... (other domains) Zone files for domain DOMAIN.COM on the public and private DNS should be: ; --- Public DNS - zone file for DOMAIN.COM domain.com. IN SOA ns.domain.com. hostmaster.domain.com. ( ... ) IN NS ns.domain.com. IN NS ns.provider.net. IN MX 10 mail.provider.net. ns IN A 172.16.12.10 www IN A 172.16.12.12 ftp IN A 172.16.12.13 ... ; --- Private DNS - zone file for DOMAIN.COM domain.com. IN SOA ns1.domain.com. hostmaster.domain.com. ( ... ) IN NS ns1.domain.com. IN NS ns2.domain.com. wks1-1 IN A 10.1.1.1 wks1-2 IN A 10.1.1.2 ... The second case of the "Same domain name", is simpler than the previous case: in the internal network, a separate domain name might be used. Recommended domain name syntax is "name.local" (e.g. DOMAIN.LOCAL). Sample configuration: ; --- Private DNS - named.boot primary domain.local ZONE.domain.local ... forwarders 172.16.12.10 slave ; --- Public DNS - named.boot primary domain.com ZONE.domain.com ... IMPLEMENTATION NOTES Location of the DNS service in both cases is irrelevant. Usually, they are located on two different physical servers, each of them connected to the appropriate part of the network (private, public). Certain savings may be done if public DNS service is hosted on the ISP network - in that case, the user will need only one (private) DNS server. Finally, both public and private DNS, in some cases, may be placed on the servers in the private network, behind the firewall. With a Cisco PIX, a statical public/private IP address mapping in this case would be needed. Two servers for the same domain could be even placed on the same physical server, with two different DNS processes running on different IP interfaces. Note that BIND 8 is needed in the latter case. * If the network is not connected to the Internet at all, only private DNS servers are needed. However, due to the lack of Internet connectivity, internal servers will fail to contact the root DNS servers every time a user types, by mistake, an address outside the corporate domain DOMAIN.COM. Some older servers won't even work if they can't reach root servers. To overcome this, it is most proper to create a so-called "fake root zone" on one or more DNS servers in the corporation. That would make all DNS servers within the corporation think there is only one or two DNS servers in the world, all located on the corporation network. Only domain names used within the corporation (DOMAIN.COM, appropriate inverse domains etc.) should be entered in the fake root zone file. Note that no cache line in the boot file of the "root" DNS makes sense. Sample configuration: ; --- named.boot primary domain.com ZONE.domain.com primary 1.10.in-addr.arpa REV.10.1 priamry . ZONE.root ... (other data; NOTE - do *NOT* place any "cache" line here !!!) ; --- ZONE.root - fake root zone file, containing only corporation domains . IN NS ns.domain.com. hostmaster.domain.com. ( ... ) IN NS ns.domain.com. IN NS ns2.domain.com. domain.com. IN NS ns.domain.com. ns.domain.com. IN A 10.1.1.1 domain.com. IN NS ns2.domain.com. ns2.domain.com. IN A 10.1.1.2 1.10.in-addr.arpa. IN NS ns.domain.com. IN NS ns2.domain.com. Other zone files follow standard configuration. ----------------------------------------------------------------------------- Question 5.23. Different DNS answers for same RR Date: Mon Sep 14 22:15:16 EDT 1998 (The following section was contributed by Berislav Todorovic) Many times there is a need for a DNS server to send different answers for same RR's, depending on the IP address of the request sender. For example, many coprporations wish to make their customers to use the "geographically closest" Web server when accessing corporate Web pages. A corporation may impose the following policy: if someone asked for the IP address of WWW.DOMAIN.COM, they may want to: * Answer that the IP address is 172.16.2.3, if the request came from one of the following IP networks: 172.1/16, 172.2/16 or 172.10/16. * Answer that the IP address is 172.16.1.1, if the request came from the IP address 172.16/16 or 172.17.128/18. * By default, for all other requests send the answer that the IP address is 172.16.2.3. The example above will need a DNS to send different A RR's, depending on the source of queries. A similar approach may be imposed for MX's, CNAME's etc. The question which arise here is: IS IT POSSIBLE? [Ed note: There are commercial products such as Cisco's Distributed Director that also will address this issue] The simple answer to the question is: NOT DIRECTLY. This is true if standard DNS software (e.g. BIND) is used on the DNS servers. However, there are two workarounds which may solve this problem: * Using two DNS servers on different UDP ports + UDP redirector * Using two DNS servers on different IP addresses + NAT on the router Solution 1: (tested on a Linux system and should work on other Unix boxes as well). Software needed is: * BIND 8 * udprelay - a package which redirects traffic to other UDP port (sunsite.unc.edu: /pub/Linux/system/network/misc/udprelay-0.2.tar.Z ). Build and install udprelay and bring up two DNS servers on different UDP ports, using different configuration files (i.e., bring one on 5300 and the other one on 5400): // --- named.conf.5300 options { directory "/var/named" listen-on port 5300 { any; }; ... (other options) }; zone "domain.com" { type master; file "domain.com.5300"; }; // --- named.conf.5400 options { directory "/var/named" listen-on port 5400 { any; }; ... (other options) }; zone "domain.com" { type master; file "domain.com.5400"; }; ; domain.com.5300 ... (SOA and other stuff) www IN A 172.16.2.3 ; --- domain.com.5400 ... (SOA and other stuff) www IN A 172.16.1.1 As can be seen, there will be two separate zone files for DOMAIN.COM, depending on which UDP port the server listens to. Each zone file can contain different records. Now, when configure udprelay to forward UDP traffic from port 53 to 5300 or 5400, depending on the remote IP address: relay 172.1.0.0 mask 255.255.0.0 * 53 172.16.1.1 5300 53 relay 172.2.0.0 mask 255.255.0.0 * 53 172.16.1.1 5300 53 relay 172.10.0.0 mask 255.255.0.0 * 53 172.16.1.1 5300 53 relay 172.16.0.0 mask 255.255.0.0 * 53 172.16.1.1 5400 53 relay 172.17.0.0 mask 255.255.0.0 * 53 172.16.1.1 5400 53 relay * * 53 172.16.1.1 5400 53 After starting udprelay, all traffic coming to port 53 will be redirected to 5300 or 5400, depending on the source IP address. NOTE - This solution deals with the UDP part of DNS only. Zone xfers will be able to be done from one DNS server only, since this solution doesn't deal the TCP part of DNS. This is, thus, a partial solution but it works! Solution 2: Bring up two DNS servers on your network, using "private" IP addresses (RFC 1918), say ns1.domain.com (10.1.1.1) and ns2.domain.com (10.1.1.2). Both servers will have the same public address - 172.16.1.1, which will be used to access the servers. Configure them to be both primary for domain DOMAIN.COM. Let one of them (say, ns1) be the "default" DNS, which will be used in most of the cases. Establish NAT on the router, so it translates the public IP address 172.16.1.1 to 10.1.1.1 and delegate your "default" DNS with the appropriate NIC, using its public address 172.16.1.1. Once you're assured everything works, setup your router to translate the public IP address 172.16.1.1 to either 10.1.1.1 or 10.1.1.2, depending on the requestor IP address. After that, depending on the source IP address, the router will return one translation or the latter, thus forwarding the remote side to the appropriate DNS server. =============================================================================== Section 6. PROBLEMS Q6.1 No address for root server Q6.2 Error - No Root Nameservers for Class XX Q6.3 Bind 4.9.x and MX querying? Q6.4 Do I need to define an A record for localhost ? Q6.5 MX records, CNAMES and A records for MX targets Q6.6 Can an NS record point to a CNAME ? Q6.7 Nameserver forgets own A record Q6.8 General problems (core dumps !) Q6.9 malloc and DECstations Q6.10 Can't resolve names without a "." Q6.11 Why does swapping kill BIND ? Q6.12 Resource limits warning in system Q6.13 ERROR:ns_forw: query...learnt Q6.14 ERROR:zone has trailing dot Q6.15 ERROR:Zone declared more then once Q6.16 ERROR:response from unexpected source Q6.17 ERROR:record too short from [zone name] Q6.18 ERROR:sysquery: findns error (3) Q6.19 ERROR:Err/TO getting serial# for XXX Q6.20 ERROR:zonename IN NS points to a CNAME Q6.21 ERROR:Masters for secondary zone [XX] unreachable Q6.22 ERROR:secondary zone [XX] expired Q6.23 ERROR:bad response to SOA query from [address] Q6.24 ERROR:premature EOF, fetching [zone] Q6.25 ERROR:Zone [XX] SOA serial# rcvd from [Y] is < ours Q6.26 ERROR:connect(IP/address) for zone [XX] failed Q6.27 ERROR:sysquery: no addrs found for NS Q6.28 ERROR:zone [name] rejected due to errors ----------------------------------------------------------------------------- Question 6.1. No address for root server Date: Wed Jan 14 12:15:54 EST 1998 Q: I've been getting the following messages lately from bind-4.9.2.. ns_req: no address for root server We are behind a firewall and have the following for our named.cache file - ; list of servers . 99999999 IN NS POBOX.FOOBAR.COM. 99999999 IN NS FOOHOST.FOOBAR.COM. foobar.com. 99999999 IN NS pobox.foobar.com. You can't do that. Your nameserver contacts POBOX.FOOBAR.COM, gets the correct list of root servers from it, then tries again and fails because of your firewall. You will need a 'forwarder' definition, to ensure that all requests are forwarded to a host which can penetrate the firewall. And it is unwise to put phony data into 'named.cache'. Q: We are getting logging information in the form: Apr 8 08:05:22 gute named[107]: sysquery: no addrs found for root NS (A.ROOT-SERVERS.NET) Apr 8 08:05:22 gute named[107]: sysquery: no addrs found for root NS (B.ROOT-SERVERS.NET) Apr 8 08:05:22 gute named[107]: sysquery: no addrs found for root NS (C.ROOT-SERVERS.NET) ... We are running bind 4.9.5PL1 Our system IS NOT behind a firewall. Any ideas ? This was discussed on the mailing list in November of 1996. The short answer was to ignore it as it was not a problem. That being said, you should upgrade to a newer version at this time if you are running a non-current version :-) ----------------------------------------------------------------------------- Question 6.2. Error - No Root Nameservers for Class XX Date: Sun Nov 27 23:32:41 EST 1994 Q: I've received errors before about "No root nameservers for class XX" but they've been because of network connectivity problems. I believe that Class 1 is Internet Class data. And I think I heard someone say that Class 4 is Hesiod?? Does anyone know what the various Class numbers are? From RFC 1700: DOMAIN NAME SYSTEM PARAMETERS The Internet Domain Naming System (DOMAIN) includes several parameters. These are documented in [RFC1034] and [RFC1035]. The CLASS parameter is listed here. The per CLASS parameters are defined in separate RFCs as indicated. Domain System Parameters: Decimal Name References -------- ---- ---------- 0 Reserved [PM1] 1 Internet (IN) [RFC1034,PM1] 2 Unassigned [PM1] 3 Chaos (CH) [PM1] 4 Hesoid (HS) [PM1] 5-65534 Unassigned [PM1] 65535 Reserved [PM1] DNS information for RFC 1700 was taken from ftp.isi.edu : /in-notes/iana/assignments/dns-parameters Hesiod is class 4, and there are no official root nameservers for class 4, so you can safely declare yourself one if you like. You might want to put up a packet filter so that no one outside your network is capable of making Hesiod queries of your machines, if you define yourself to be a root nameserver for class 4. ----------------------------------------------------------------------------- Question 6.3. Bind 4.9.x and MX querying? Date: Sun Nov 27 23:32:41 EST 1994 If you query a 4.9.x DNS server for MX records, a list of the MX records as well as a list of the authorative nameservers is returned. This happens because bind 4.9.2 returns the list of nameserver that are authorative for a domain in the response packet, along with their IP addresses in the additional section. ----------------------------------------------------------------------------- Question 6.4. Do I need to define an A record for localhost ? Date: Sat Sep 9 00:36:01 EDT 1995 Somewhere deep in the BOG (BIND Operations Guide) that came with 4.9.3 (section 5.4.3), it says that you define this yourself (if need be) in the same zone files as your "real" IP addresses for your domain. Quoting the BOG: ... As implied by this PTR record, there should be a ``localhost.my.dom.ain'' A record (with address 127.0.0.1) in every domain that contains hosts. ``localhost.'' will lose its trailing dot when 1.0.0.127.in-addr.arpa is queried for;... The sample files in the BIND distribution show you what needs to be done (see the BOG). Some HP boxen (especially those running HP OpenView) will also need "loopback" defined with this IP address. You may set it as a CNAME record pointing to the "localhost." record. ----------------------------------------------------------------------------- Question 6.5. MX records, CNAMES and A records for MX targets Date: Sun Nov 27 23:32:41 EST 1994 The O'Reilly "DNS and Bind" book warns against using non-canonical names in MX records, however, this warning is given in the context of mail hubs that MX to each other for backup purposes. How does this apply to mail spokes. RFC 974 has a similar warning, but where is it specifically prohibited to us an alias in an MX record ? Without the restrictions in the RFC, a MTA must request the A records for every MX listed to determine if it is in the MX list then reduce the list. This introduces many more lookups than would other wise be required. If you are behind a 1200 bps link YOU DON'T WANT TO DO THIS. The addresses associated with CNAMES are not passed as additional data so you will force additional traffic to result even if you are running a caching server locally. There is also the problem of how does the MTA find all of it's IP addresses. This is not straight forward. You have to be able to do this is you allow CNAMEs (or extra A's) as MX targets. The letter of the law is that an MX record should point to an A record. There is no "real" reason to use CNAMEs for MX targets or separate As for nameservers any more. CNAMEs for services other than mail should be used because there is no specified method for locating the desired server yet. People don't care what the names of MX targets are. They're invisible to the process anyway. If you have mail for "mary" redirected to "sue" is totally irrelevant. Having CNAMEs as the targets of MX's just needlessly complicates things, and is more work for the resolver. Having separate A's for nameservers like "ns.your.domain" is pointless too, since again nobody cares what the name of your nameserver is, since that too is invisible to the process. If you move your nameserver from "mary.your.domain" to "sue.your.domain" nobody need care except you and your parent domain administrator (and the InterNIC). Even less so for mail servers, since only you are affected. Q: Given the example - hello in cname realname mailx in mx 0 hello Now, while reading the operating manual of bind it clearly states that this is *not* valid. These two statements clearly contradict each other. Is there some later RFC than 974 that overrides what is said in there with respect to MX and CNAMEs? Anyone have the reference handy? A: This isn't what the BOG says at all. See below. You can have a CNAME that points to some other RR type; in fact, all CNAMEs have to point to other names (Canonical ones, hence the C in CNAME). What you can't have is an MX that points to a CNAME. MX RR's that point to names which have only CNAME RR's will not work in many cases, and RFC 974 intimates that it's a bad idea: Note that the algorithm to delete irrelevant RRs breaks if LOCAL has a alias and the alias is listed in the MX records for REMOTE. (E.g. REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This can be avoided if aliases are never used in the data section of MX RRs. Here's the relevant BOG snippet: aliases {ttl addr-class CNAME Canonical name ucbmonet IN CNAME monet The Canonical Name resource record, CNAME, speci- fies an alias or nickname for the official, or canonical, host name. This record should be the only one associated with the alias name. All other resource records should be associated with the canonical name, not with the nickname. Any resource records that include a domain name as their value (e.g., NS or MX) must list the canoni- cal name, not the nickname. ----------------------------------------------------------------------------- Question 6.6. Can an NS record point to a CNAME ? Date: Wed Mar 1 11:14:10 EST 1995 Can I do this ? Is it legal ? @ SOA (.........) NS ns.host.this.domain. NS second.host.another.domain. ns CNAME third third IN A xxx.xxx.xxx.xxx No. Only one RR type is allowed to refer, in its data field, to a CNAME, and that's CNAME itself. So CNAMEs can refer to CNAMEs but NSs and MXs cannot. BIND 4.9.3 (Beta11 and later) explicitly syslogs this case rather than simply failing as pre-4.9 servers did. Here's a current example: Dec 7 00:52:18 gw named[17561]: "foobar.com IN NS" \ points to a CNAME (foobar.foobar.com) Here is the reason why: Nameservers are not required to include CNAME records in the Additional Info section returned after a query. It's partly an implementation decision and partly a part of the spec. The algorithm described in RFC 1034 (pp24,25; info also in RFC 1035, section 3.3.11, p 18) says 'Put whatever addresses are available into the additional section, using glue RRs [if necessary]'. Since NS records are speced to contain only primary names of hosts, not CNAMEs, then there's no reason for algorithm to mention them. If, on the other hand, it's decided to allow CNAMEs in NS records (and indeed in other records) then there's no reason that CNAME records might not be included along with A records. The Additional Info section is intended for any information that might be useful but which isn't strictly the answer to the DNS query processed. It's an implementation decision in as much as some servers used to follow CNAMEs in NS references. ----------------------------------------------------------------------------- Question 6.7. Nameserver forgets own A record Date: Fri Dec 2 16:17:31 EST 1994 Q: Lately, I've been having trouble with named 4.9.2 and 4.9.3. Periodically, the nameserver will seem to "forget" its own A record, although the other information stays intact. One theory I had was that somehow a site that the nameserver was secondary for was "corrupting" the A record somehow. A: This is invariably due to not removing ALL of the cached zones when you moved to 4.9.X. Remove ALL cached zones and restart your nameservers. You get "ignoreds" because the primaries for the relevant zones are running old versions of BIND which pass out more glue than is required. named-xfer trims off this extra glue. ----------------------------------------------------------------------------- Question 6.8. General problems (core dumps !) Date: Sun Dec 4 22:21:22 EST 1994 Paul Vixie says: I'm always interested in hearing about cases where BIND dumps core. However, I need a stack trace. Compile with -g and not -O (unless you are using gcc and know what you are doing) and then when it dumps core, get into dbx or gdb using the executable and the core file and use "bt" to get a stack trace. Send it to me <paul@vix.com> along with specific circumstances leading to or surrounding the crash (test data, tail of the debug log, tail of the syslog... whatever matters) and ideally you should save your core dump for a day or so in case I have questions you can answer via gdb/dbx. ----------------------------------------------------------------------------- Question 6.9. malloc and DECstations Date: Mon Jan 2 14:19:22 EST 1995 We have replaced malloc on our DECstations with a malloc that is more compact in memory usage, and this helped the operation of bind a lot. The source is now available for anonymous ftp from ftp.cs.wisc.edu : /pub/misc/malloc.tar.gz ----------------------------------------------------------------------------- Question 6.10. Can't resolve names without a "." (Answer written by Mark Andrews) You are not using a RFC 1535 aware resolver. Depending upon the age of your resolver you could try adding a search directive to resolv.conf. e.g. domain <domain> search <domain> [<domain2> ...] If that doesn't work you can configure you server to serve the parent and grandparent domains as this is the default search list. "domain langley.af.mil" has an implicit "search langley.af.mil af.mil mil" in the old resolvers, and you are timing out trying to resolve the address with one of these domains tacked on. When resolving internic.net the following will be tried in order. internic.net.langley.af.mil internic.net.af.mil internic.net.mil internic.net. RFC 1535 aware resolvers try qualified address first. internic.net. internic.net.langley.af.mil internic.net.af.mil internic.net.mil RFC 1535 documents the problems associated with the old search algorithim, including security issues, and how to alleviate some of the problems. ----------------------------------------------------------------------------- Question 6.11. Why does swapping kill BIND ? Date: Thu Jul 4 23:20:20 EDT 1996 The question was: I've been diagnosing a problem with BIND 4.9.x (where x is usually 3BETA9 or 3REL) for several months now. I finally tracked it down to swap space utilization on the unix boxes. This happens under (at least) under Linux 1.2.9 & 1.2.13, SunOS 4.1.3U1, 4.1.1, and Solaris 2.5. The symptom is that if these machines get into swap at all bind quits resolving most, if not all queries. Mind you that these machines are not "swapping hard", but rather we're talking about a several hundred K TEMPORARY deficiency. I have noticed while digging through various archives that there is some referral to "bind thrashing itself to death". Is this what is happening ? And the answer is: Yes it is. Bind can't tolerate having even a few pages swapped out. The time required to send responses climbs to several seconds/request, and the request queue fills and overflows. It's possible to shrink memory consumption a lot by undefining STATS and XSTATS, and recompiling. You could nuke DEBUG too, which will cut the code size down some, but probably not the data size. If that doesn't do the job then it sounds like you'll need to move DNS onto a separate box. BIND tends to touch all of its resident pages all of the time with normal activity... if you look at the RSS verses the total process size, you will always see the RSS within, usually, 90% of the total size of the process. This means that *any* paging of named-owned pages will stall named. Thus, a machine running a heavily accessed named process cannot afford to swap *at all*. (Paul Vixie continues on this subject): I plan to try to get BIND to exhibit slightly better locality of reference in some future release. Of course, I can only do this if the query names also exhibit some kind of hot spots. If someone queries all your names often, BIND will have to touch all of its VM pool that often. (Right now, BIND touches everything pretty often even if you're just hammering on some hot spots -- that's the part I'd like to fix. Malloc isn't cooperating.) ----------------------------------------------------------------------------- Question 6.12. Resource limits warning in system Date: Sun Feb 15 22:04:43 EST 1998 When bind-8.1.1 is started the following informational message appears in the syslog... Feb 13 14:19:35 ns1named[1986]: "cannot set resource limits on this system" What does this mean ? A: It means that BIND doesn't know how to implement the "coresize", "datasize", "stacksize", or "files" process limits on your OS. If you're not using these options, you may ignore the message. ----------------------------------------------------------------------------- Question 6.13. ERROR:ns_forw: query...learnt Date: Sun Feb 15 23:08:06 EST 1998 The following message appears in syslog: Jan 22 21:59:55 server1 named[21386]: ns_forw: query(testval) contains our address (dns1.foobar.org:1.2.3.4) learnt (A=:NS=) what does it mean ? A: This means that when it was looking up the NS records for the domain containing "testval" (i.e. the root domain), it found an NS record pointing to dns1.foobar.org, and the A record for this is 1.2.3.4. This is server1's own IP address, but it's not authoritative for the root domain. The (A-:NS=) part of the message means that it didn't learn these NS records from any other machine. You may have listed dns1.foobar.org in your root server cache file, even though it's not configured as a root server. \question 09jul:linuxq ERROR:recvfrom: Connection refused Date: Wed Jul 9 21:57:40 EDT 1997 DNS on my linux system is reporting the error \verbatim Mar 26 12:11:20 idg named[45]: recvfrom: Connection refused When I start or restart the named program I get no errors. What could be causing this ? A: Are you running the BETA9 version of bind 4.9.3 ? It is a bug that does no harm and the error reporting was corrected in later releases. You should upgrade to a newer version of bind. ----------------------------------------------------------------------------- Question 6.14. ERROR:zone has trailing dot Date: Wed Jul 9 22:11:51 EDT 1997 If syslog reports "zone has trailing dot", the zone information contains a trailing dot in the named.boot file where it does not belong. example: secondary domain.com. xxx.xxx.xxx.xxx S-domain.com ^ ----------------------------------------------------------------------------- Question 6.15. ERROR:Zone declared more then once Date: Wed Jul 9 22:12:45 EDT 1997 If syslog reports "Zone declared more then once", A zone is specified multiple times in the named.boot file example: secondary domain.com 198.247.225.251 S-domain.com secondary zone.com 198.247.225.251 S-zone.com primary domain.com P-domain.com domain.com is declared twice, once as primary, and once as secondary ----------------------------------------------------------------------------- Question 6.16. ERROR:response from unexpected source Date: Wed Jul 9 22:12:45 EDT 1997 If syslog reports "response from unexpected source", BIND (pre 4.9.3) has a bug if implimented on a multi homed server. This error indicates that the response to a query came from an address other then the one sent to. So, if ace gets a response from an unexpected source, ace will ignore the response. ----------------------------------------------------------------------------- Question 6.17. ERROR:record too short from [zone name] Date: Mon Jun 15 21:34:49 EDT 1998 If syslog report "record too short from [zone name]", The secondary server is trying to pull a zone from the primary server. For some reason, the primary sent an incomplete zone. This usually is a problem at the primary server. To troubleshoot, try this: dig [zonename] axfr @[primary IP address] Often, this is caused by a line broken in the middle. When the primary server's "named.boot" file contains "xfrnets" entries for other servers and the secondary is not listed, this error can occur. Creating an "xfrnets" entry for the secondary will solve the error. ----------------------------------------------------------------------------- Question 6.18. ERROR:sysquery: findns error (3) Date: Wed Jul 9 22:17:09 EDT 1997 If syslog reports "sysquery: findns error (3)" or "qserial_query(zonename): sysquery FAILED", there is no ns record for the zone. or the NS record is not defined correctly. ----------------------------------------------------------------------------- Question 6.19. ERROR:Err/TO getting serial# for XXX Date: Wed Jul 9 22:18:41 EDT 1997 If syslog reports "Err/TO getting serial# for XXX", there could be a number of possible errors: - An incorrect IP address in named.boot, - A network reachibility problem, - The primary is lame for the zone. An external check to see if you can retrieve the SOA is the best way to work out which it is. ----------------------------------------------------------------------------- Question 6.20. ERROR:zonename IN NS points to a CNAME Date: Wed Jul 9 22:20:29 EDT 1997 If syslog reports "zonename IN NS points to a CNAME" or "zonename IN MX points to a CNAME", named is 'reminding' you that due to various RFCs, an NS or MX record cannot point to a CNAME. EXAMPLE 1 --------- domain.com IN SOA (...stuff...) IN NS ns.domain.com. ns IN CNAME machine.domain.com. machine IN A 1.2.3.4 The IN NS record points to ns, which is a CNAME for machine. This is what results in the above error EXAMPLE 2 --------- domain.com IN SOA (...stuff...) IN MX mail.domain.com. mail IN CNAME machine.domain.com. machine IN A 1.2.3.4 This would cause the MX variety of the error. The fix is point MX and NS records to a machine that is defined explicitly by an IN A record. ----------------------------------------------------------------------------- Question 6.21. ERROR:Masters for secondary zone [XX] unreachable Date: Wed Jul 9 22:24:27 EDT 1997 If syslog reports "Masters for secondary zone [XX] unreachable", the initial attempts to load a zone failed, and the name server is still trying. If this occurs multiple times, a problem exists, likely on the primary server. This is a fairly generic error, and could indicate a vast number of problems. It might be that named is not running on the primary server, or they do not have the correct zone file. If this keeps up long enough a zone might expire. ----------------------------------------------------------------------------- Question 6.22. ERROR:secondary zone [XX] expired Date: Wed Jul 9 22:25:53 EDT 1997 If syslog reports "secondary zone [XX] expired", there has been a expiration of a secondary zone on this server. An expired zone is one in which a transfer hasn't successfully been completed in the amount of time specified before a zone expires. This problem could be anything which prevents a zone transfer: The primary server is down, named isn't running on the primary, named.boot has the wrong IP address, etc. ----------------------------------------------------------------------------- Question 6.23. ERROR:bad response to SOA query from [address] Date: Wed Jan 14 12:15:11 EST 1998 If syslog reports "bad response to SOA query from [address], zone [name]", a syntax error may exist in the SOA record of the zone your server is attempting to pull. It may also indicate that the primary server is lame, possibly due to a syntax error somewhere in the zone file. ----------------------------------------------------------------------------- Question 6.24. ERROR:premature EOF, fetching [zone] Date: Wed Jul 9 22:28:26 EDT 1997 If syslog reports "premature EOF, fetching [zone]", a syntax error exists on the zone at the primary location, likely towards the End of File (EOF) location. ----------------------------------------------------------------------------- Question 6.25. ERROR:Zone [XX] SOA serial# rcvd from [Y] is < ours Date: Wed Jul 9 22:30:03 EDT 1997 If syslog reports "Zone [name] SOA serial# rcvd from [address] is < ours", the zone transfer failed because the primary machine has a lower serial number in the SOA record than the one on file on this server. ----------------------------------------------------------------------------- Question 6.26. ERROR:connect(IP/address) for zone [XX] failed Date: Wed Jan 14 12:21:40 EST 1998 If syslog reports "connect(address) for zone [name] failed: No route to host" or "connect(address) for zone [name] failed: Connection timed out", it could be that there is no route to the specified host or a slow primary system. Try a traceroute to the address specified to isolate the problem. The problem may be a mistyped IP address in named.boot. A very slow primary machine or a connection may have been initialized, then connectivity lost for some reason, etc. Try networking troubleshooting tools like ping and traceroute, then try connecting to port 53 using nslookup or dig. If syslog reports "connect(address) for zone [name] failed: Connection refused", the destination address is not allowing the connection. Either the destination is not running DNS (port 53), or possibly filtering the connection from you. It is also possible that the named.boot is pointing to the wrong address. ----------------------------------------------------------------------------- Question 6.27. ERROR:sysquery: no addrs found for NS Date: Wed Jul 9 22:37:01 EDT 1997 If syslog reports "sysquery: no addrs found for NS" , the IN NS record may be pointing to a host with no IN A record. ----------------------------------------------------------------------------- Question 6.28. ERROR:zone [name] rejected due to errors Date: Wed Jul 9 22:37:51 EDT 1997 If syslog reports "primary zone [name] rejected due to errors", there will likely be another more descriptive error along with this, like "zonefile: line 17: database format error". That zone file should be investigated for errors. =============================================================================== Section 7. ACKNOWLEDGEMENTS Q7.1 How is this FAQ generated ? Q7.2 What formats are available ? Q7.3 Contributors ----------------------------------------------------------------------------- Question 7.1. How is this FAQ generated ? Date: Mon Jun 15 21:45:53 EDT 1998 This FAQ is maintained in BFNN (Bizzarre Format with No Name). This allows me to create ASCII, HTML, and GNU info (postscript coming soon) from one source file. The perl script "bfnnconv.pl" that is available with the linux FAQ is used to generate the various output files from the BFNN source. This script is available at txs-11.mit.edu : /pub/linux/docs/linux-faq/linux-faq.source.tar.gz ----------------------------------------------------------------------------- Question 7.2. What formats are available ? Date: Fri Dec 6 16:51:31 EST 1996 You may obtain one of the following formats for this document: * ASCII: http://www.intac.com/~cdp/cptd-faq/cptd-faq.ascii * BFNN: http://www.intac.com/~cdp/cptd-faq/cptd-faq.bfnn * GNU info: http://www.intac.com/~cdp/cptd-faq/cptd-faq.info * HTML: http://www.intac.com/~cdp/cptd-faq/index.html ----------------------------------------------------------------------------- Question 7.3. Contributors Date: Thu Jul 16 10:45:57 EDT 1998 Many people have helped put this list together. Listed in e-mail address alphabetical order, the following people have contributed to this FAQ: * <BERI@etf.bg.ac.yu> (Berislav Todorovic) * <Benoit.Grange@inria.fr> (Benoit.Grange) * <D.T.Shield@csc.liv.ac.uk> (Dave Shield) * <Karl.Auer@anu.edu.au> (Karl Auer) * <Todd.Aven@BankersTrust.Com> * <adam@comptech.demon.co.uk> (Adam Goodfellow) * <andras@is.co.za> (Andras Salamon) * <barmar@bbnplanet.com> (Barry Margolin) * <barr@pop.psu.edu> (David Barr) * <bj@herbison.com> (B.J. Herbison) * <bje@cbr.fidonet.org> (Ben Elliston) * <brad@birch.ims.disa.mil> (Brad Knowles) * <ckd@kei.com> (Christopher Davis) * <cdp2582@hertz.njit.edu> (Chris Peckham) * <cricket@hp.com> (Cricket Liu) * <cudep@csv.warwick.ac.uk> (Ian 'Vato' Dickinson [ID17]) * <dj@netscape.com> (David Jagoda) * <djk@cyber.com.au> (David Keegel) * <dillon@best.com> (Matthew Dillon) * <dparter@cs.wisc.edu> (David Parter) * <e07@nikhef.nl> (Eric Wassenaar) * <fitz@think.com> (Tom Fitzgerald) * <fwp@CC.MsState.Edu> (Frank Peters) * <gah@cco.caltech.edu> (Glen A. Herrmannsfeldt) * <glenn@popco.com> (Glenn Fleishman) * <harvey@indyvax.iupui.edu> (James Harvey) * <hubert@cac.washington.edu> (Steve Hubert) * <ivanl@pacific.net.sg> (Ivan Leong) * <jpass@telxon.com> (Jim Pass) * <jhawk@panix.com> (John Hawkinson) * <jmalcolm@uunet.uu.net> (Joseph Malcolm) * <jprovo@augustus.ultra.net> (Joe Provo) * <jrs@foliage.com> (J. Richard Sladkey) * <jsd@gamespot.com> (Jon Drukman) * <jwells@pacificcoast.net> (John Wells) * <kop@meme.com> (Karl O. Pinc) * <kevin@cfc.com> (Kevin Darcy) * <lamont@abstractsoft.com> (Sean T. Lamont) * <lavondes@tidtest.total.fr> (Michel Lavondes) * <mark@ucsalf.ac.uk> (Mark Powell) * <marka@syd.dms.CSIRO.AU> (Mark Andrews) * <mathias@unicorn.swi.com.sg> (Mathias Koerber) * <mfuhr@dimensional.com> (Michael Fuhr) * <mike@westie.gi.net> (Michael Hawk) * <mjo@iao.ford.com> (Mike O'Connor) * <nick@flapjack.ieunet.ie> (Nick Hilliard) * <oppedahl@popserver.panix.com> (Carl Oppedahl) * <patrick@oes.amdahl.com> (Patrick J. Horgan) * <paul@software.com> (Paul Wren) * <pb@fasterix.frmug.fr.net> (Pierre Beyssac) * <ph10@cus.cam.ac.uk> (Philip Hazel) * <phil@netpart.com> (Phil Trubey) * <raj@ceeri.ernet.in> (Raj Singh) * <rocky@panix.com> (R. Bernstein) * <rv@seins.Informatik.Uni-Dortmund.DE> (Ruediger Volk) * <sedwards@sedwards.com> (Steve Edwards) * <shields@tembel.org> (Michael Shields) * <spsprunk@pop.srv.paranet.com> (Stephen Sprunk) * <tanner@george.arc.nasa.gov> (Rob Tanner) * <vixie@vix.com> (Paul A Vixie) * <wag@swl.msd.ray.com> (William Gianopoulos) * <whg@inel.gov> (Bill Gray) * <wolf@pasteur.fr> (Christophe Wolfhugel) Thank you !