diff options
Diffstat (limited to 'contrib/bind/doc/misc/FAQ.2of2')
| -rw-r--r-- | contrib/bind/doc/misc/FAQ.2of2 | 1449 |
1 files changed, 808 insertions, 641 deletions
diff --git a/contrib/bind/doc/misc/FAQ.2of2 b/contrib/bind/doc/misc/FAQ.2of2 index ae453c9..40e1649 100644 --- a/contrib/bind/doc/misc/FAQ.2of2 +++ b/contrib/bind/doc/misc/FAQ.2of2 @@ -1,247 +1,227 @@ Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers -Path: vixie!news1.digital.com!uunet!in1.uu.net!usc!rutgers!njitgw.njit.edu!hertz.njit.edu!cdp2582 -From: cdp@njit.edu (Chris Peckham) +Path: vixie!news1.digital.com!su-news-hub1.bbnplanet.com!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.mathworks.com!news.kei.com!uhog.mit.edu!rutgers!njitgw.njit.edu!hertz.njit.edu!cdp2582 +From: cdp2582@hertz.njit.edu (Chris Peckham) Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2) -Message-ID: <cptd-faq-2-810621452@njit.edu> +Message-ID: <cptd-faq-2-849940949@njit.edu> Followup-To: comp.protocols.tcp-ip.domains Originator: cdp2582@hertz.njit.edu Keywords: BIND,DOMAIN,DNS Sender: news@njit.edu -Supersedes: <cptd-faq-2-807632375@njit.edu> +Supersedes: <cptd-faq-2-847336183@njit.edu> Nntp-Posting-Host: hertz.njit.edu -X-Posting-Frequency: posted on the 1st of each month +X-Posting-Frequency: posted during the first week of each month Reply-To: domain-faq@njit.edu (comp.protocols.tcp-ip.domains FAQ comments) Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA -References: <cptd-faq-1-810621452@njit.edu> -Date: Sat, 9 Sep 1995 04:38:21 GMT +References: <cptd-faq-1-849940949@njit.edu> +Date: Sat, 7 Dec 1996 06:42:49 GMT Approved: news-answers-request@MIT.EDU -Expires: Sat 14 Oct 95 00:37:32 EDT -Lines: 1110 -Xref: vixie comp.protocols.tcp-ip.domains:6019 comp.answers:13882 news.answers:49919 +Expires: Sat 11 Jan 97 02:42:29 EDT +Lines: 1277 +Xref: vixie comp.protocols.tcp-ip.domains:12905 comp.answers:22441 news.answers:85683 Posted-By: auto-faq 3.1.1.2 Archive-name: internet/tcp-ip/domains-faq/part2 -Revision: 1.5 1995/05/12 18:50:41 - - -This FAQ is edited and maintained by Chris Peckham, <cdp@njit.edu>. -The latest version may always be found for anonymous ftp from - - ftp://rtfm.mit.edu/pub/usenet/news.answers/internet/tcp-ip/domains-faq - ftp://ftp.njit.edu/pub/dns/Comp.protocols.tcp-ip.domains.FAQ - -If you can contribute any answers for items in the TODO section, please do -so by sending e-mail to domain-faq@njit.edu ! If you know of any items that -are not included and you feel that they should be, send the relevant -information to domain-faq@njit.edu. - - ------------------------------- - -Date: Fri May 12 14:41:47 EDT 1995 -Subject: Table of Contents - -Table of Contents -================= -Part 1 ------- - 0. TO DO - 1. INTRODUCTION / MISCELLANEOUS - 1.1 What is this newsgroup ? - 1.2 More information - 1.3 What is BIND and where is the latest version of BIND ? - 1.4 How can I find the route between systems ? - 1.5 Finding the hostname if you have the tcp-ip address - 1.6 How to register a domain name - 1.7 Change of Domain name - 1.8 How memory and CPU does DNS use ? - 1.9 Other things to consider when planning your servers - 1.10 Proper way to get NS and reverse IP records into DNS - 1.11 How to get my address assign from NIC? - 1.12 Is there a block of private IP addresses I can use? - 1.13 Cache failed lookups - 1.14 What does an NS record really do ? - 1.15 DNS ports - 1.16 Obtaining the latest cache file - 2. UTILITIES - 2.1 Utilities to administer DNS zone files - 2.2 DIG - Domain Internet Groper - 2.3 DNS packet analyzer - 2.4 host - 2.5 Programming with DNS - 2.6 A source of information relating to DNS - 3. DEFINITIONS - 3.1 TCP/IP Host Naming Conventions - 3.2 Slaves and servers with forwarders - 3.3 When is a server authoritative? - 3.4 Underscore in host-/domain names - 3.5 Lame delegation - 3.6 What does opt-class field do? - 3.7 Top level domains - 3.8 Classes of networks - 3.9 What is CIDR ? - 3.10 What is the rule for glue ? - -Part 2 ------- - 4. CONFIGURATION - 4.1 Changing a Secondary server to a Primary - 4.2 How do I subnet a Class B Address ? - 4.3 Subnetted domain name service - 4.4 Recommended format/style of DNS files - 4.5 DNS on a system not connected to the Internet - 4.6 Multiple Domain configuration - 4.7 wildcard MX records - 4.8 How to identify a wildcard MX record - 4.9 Why are fully qualified domain names recommended ? - 4.10 Distributing load using named - 4.11 Order of returned records - 4.12 resolv.conf - 4.13 Delegating authority - 4.14 DNS instead of NIS on a Sun OS 4.1.x system - 5. PROBLEMS - 5.1 No address for root server - 5.2 Error - No Root Nameservers for Class XX - 5.3 Bind 4.9.x and MX querying? - 5.4 Some root nameservers don't know localhost - 5.5 MX records and CNAMES and separate A records for MX targets - 5.6 NS is a CNAME - 5.7 Nameserver forgets own A record - 5.8 General problems (core dumps !) - 5.9 malloc and DECstations - 6. ACKNOWLEDGEMENTS - ------------------------------- - -Date: Fri Dec 2 15:31:06 EST 1994 -Subject: Q4.1 - Changing a Secondary server to a Primary - -Q: Do I need to do anything special when I change a server from a secondary - to a primary ? - -A: 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). +Revision: 1.13 1996/12/07 06:42:15 + + +(Continued from Part 1, where you'll find the introduction and +table of contents.) + + +=============================================================================== + +Section 5. CONFIGURATION + + Q5.1 Changing a Secondary server to a Primary server ? + Q5.2 Moving a Primary server to another server + Q5.3 How do I subnet a Class B Address ? + Q5.4 Subnetted domain name service + Q5.5 Recommended format/style of DNS files + Q5.6 DNS on a system not connected to the Internet + Q5.7 Multiple Domain configuration + Q5.8 wildcard MX records + Q5.9 How do you identify a wildcard MX record ? + Q5.10 Why are fully qualified domain names recommended ? + Q5.11 Distributing load using named + Q5.12 Order of returned records + Q5.13 resolv.conf + Q5.14 How do I delegate authority for sub-domains ? + Q5.15 DNS instead of NIS on a Sun OS 4.1.x system + Q5.16 Patches to add functionality to BIND + Q5.17 How to serve multiple domains from one server + +----------------------------------------------------------------------------- + +Question 5.1. 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. + +----------------------------------------------------------------------------- - 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.2. 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 +recommened 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 witht 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.3. How do I subnet a Class B Address ? Date: Fri Apr 28 13:34:52 EDT 1995 -Subject: Q4.2 - How do I subnet a Class B Address ? -Q: I just received a Class B internet address and I am wondering where to - get an RFC or other information on how to properly to the TCP/IP - sub-netting. - -A: 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). RFC1219 discusses the issue of subnetting very well - and leaves the network administrator with a large amount of flexibility - for future growth. - - ------------------------------- - -Date: Sun Nov 27 23:32:41 EST 1994 -Subject: Q4.3 -Subnetted domain name service +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). -Q: After doing some reading (DNS and BIND, Albitz&Liu), I don't really - find any examples of handling subnetted class C networks as separate - DNS domains. - -A: This is possible, just messy. 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: +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. - 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. - - ------------------------------- +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. + +----------------------------------------------------------------------------- + +Question 5.4. Subnetted domain name service + +Date: Mon Aug 5 23:00:16 EDT 1996 + +If you are looking for some examples of handling subnetted class C +networks as separate DNS domains, see the Internet Draft + +draft-ietf-cidrd-classless-inaddr-02.txt + +for more information. This file is available for anonymous ftp at + +ds.internic.net : +/internet-drafts/draft-ietf-cidrd-classless-inaddr-02.txt + +or other IETF mirror sites (ftp.is.ca.za [Africa], nic.nordu.net [Europe], +munnari.oz.au [Pacific Rim], ds.internic.net [US East Coast], or +ftp.isi.edu [US West Coast]). + +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.vix.com : /pub/bind/contrib/gencidrzone + +----------------------------------------------------------------------------- + +Question 5.5. Recommended format/style of DNS files Date: Sun Nov 27 23:32:41 EST 1994 -Subject: Q4.4 - Recommended format/style of DNS files -Q: Are there any suggestions for how to layout DNS configuration files - (both forward and reverse)? - -A: This answer is quoted from an article posted by Paul Vixie: - +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 @@ -399,189 +379,174 @@ pc.home A 192.5.5.3 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.6. DNS on a system not connected to the Internet + Date: Sun Nov 27 23:32:41 EST 1994 -Subject: Q4.5 - DNS on a system not connected to the Internet - -Q: How do I use DNS on a system that is not connected to the Internet or - set BIND up with an internal root server ? - -A: 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) - -Q: What if you connect intermittently and want DNS to work when you are - connected, and "fail" when you are not ? - -A: 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. - ------------------------------- - +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.7. Multiple Domain configuration + Date: Fri Dec 2 15:40:49 EST 1994 -Subject: Q4.6 -Multiple Domain configuration - -Q: I have seen sites that seem to have multiple domain names pointing to the - same destination. I would like to implement this and have found no - information explaining how to do it. What I would like to do is: - +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 - -A: This is done through CNAME records: - + +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. - - ------------------------------- - +You can also do the same thing with multiple A records. + +----------------------------------------------------------------------------- + +Question 5.8. wildcard MX records + Date: Sun Nov 27 23:32:41 EST 1994 -Subject: Q4.7 - wildcard MX records -Q: Does BIND not understand wildcard MX records such as the following? - +Does BIND not understand wildcard MX records such as the following? + *.foo.com MX 0 mail.foo.com. - -A: 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. - ------------------------------- -Date: Thu Dec 1 11:10:39 EST 1994 -Subject: Q4.8 - How to identify a wildcard MX record +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. -Q: How do you identify a wildcard MX record ? +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.9. 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: -A: 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. - ------------------------------- + +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.10. Why are fully qualified domain names recommended ? Date: Sun Nov 27 23:32:41 EST 1994 -Subject: Q4.9 - Why are fully qualified domain names recommended ? - -Q: Why are fully qualified domain names recommended ? - -A: 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? - -A: 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: - +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. - ------------------------------- + + 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.11. Distributing load using named Date: Wed Mar 1 11:04:43 EST 1995 -Subject: Q4.10 - Distributing load using named - -Q: If you attempt to distribute the load on a system using named, won't - the first response be cached, and then later queries use the cached - value? (This would be for requests that come through the same - server.) - -A: Yes. So 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. +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. - 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. +If your local caching server has ROUND_ROBIN, it does not matter what the +authoritative servers have -- every response from the cache is rotated. - Not nice. +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. -A: Paul Vixie has an example of the ROUND_ROBIN code in action. Here is - something that he wrote regarding his example: +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. @@ -613,46 +578,37 @@ A: Paul Vixie has an example of the ROUND_ROBIN code in action. Here is 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} + {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} + {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} + {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} + {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} + {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 - ------------------------------- - -Date: Sun Dec 4 22:12:32 EST 1994 -Subject: Q4.11 - Order of returned records +----------------------------------------------------------------------------- -Q: Is there any way to tell named to return records, specifically - address records, in the order in which they are listed in the - database? +Question 5.12. Order of returned records - It would appear that named consistently applies a sorting algorithm - to address records which seems to be virtually guaranteed to be - pessimal for our routers, which have many A records. +Sorting, is the *resolver's* responsibility. RFC 1123: -A: Sorting, is the *resolver's* responsibility. RFC 1123: 6.1.3.4 Multihomed Hosts @@ -672,19 +628,19 @@ A: Sorting, is the *resolver's* responsibility. RFC 1123: 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. +In BIND 4.9.x's resolver code, the "sortlist" directive in resolv.conf +can be used to configure this. ------------------------------- +----------------------------------------------------------------------------- -Date: Fri Feb 10 15:46:17 EST 1995 -Subject: Q4.12 - resolv.conf +Question 5.13. resolv.conf +Date: Fri Feb 10 15:46:17 EST 1995 -Q: Why should I use "real" IP addresses in /etc/resolv.conf and not 0.0.0.0 - or 127.0.0.1. +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" ? -A: Paul Vixie writes on the issue of the contents of resolv.conf: +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 @@ -714,41 +670,40 @@ A: Paul Vixie writes on the issue of the contents of resolv.conf: otherwise share identical copies of your resolv.conf on all the systems on any given subnet, not all of which will be servers. -A: 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). +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). ------------------------------- +----------------------------------------------------------------------------- -Date: Mon Jan 2 13:50:13 EST 1995 -Subject: Q4.13 - Delegating authority +Question 5.14. How do I delegate authority for sub-domains ? -Q: How do I delegate authority for domains within my domain ? +Date: Sat Dec 7 02:04:17 EST 1996 + +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 -A: 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 machine in your 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. @@ -759,41 +714,118 @@ A: When you start having a very big domain that can be broken into logical 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. +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. ------------------------------- +----------------------------------------------------------------------------- -Date: Wed Mar 1 11:45:00 EST 1995 -Subject: Q4.14 - DNS instead of NIS on a Sun OS 4.1.x system +Question 5.15. DNS instead of NIS on a Sun OS 4.1.x system -Q: I would appreciate any comments on whether running bind 4.9.x will - enable sendmail, ftp, telnet and other TCP/IP services to bypass - NIS and connect directly to named. - -A: How to do this is documented quite well in the comp.sys.sun.admin FAQ in - questions one and two. You can get them from: +Date: Sat Dec 7 01:14:17 EST 1996 - ftp://thor.ece.uc.edu/pub/sun-faq/FAQs/sun-faq.general - http://www.cis.ohio-state.edu/hypertext/faq/usenet/comp-sys-sun-faq +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: - as well as from rtfm.mit.edu in the usual place, etc. - +* 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.16. Patches to add functionality to BIND + +Date: Tue Nov 5 23:53:47 EST 1996 + +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/ + +* 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 + +* 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 + +----------------------------------------------------------------------------- + +Question 5.17. 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/. + +=============================================================================== + +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 Err/TO errors being reported + Q6.12 Why does swapping kill BIND ? + +----------------------------------------------------------------------------- + +Question 6.1. No address for root server Date: Mon Jan 2 13:49:43 EST 1995 -Subject: Q5.1 - No address for root server - Q: I've been getting the following messages lately from bind-4.9.2.. ns_req: no address for root server @@ -803,27 +835,26 @@ We are behind a firewall and have the following for our named.cache file - . 99999999 IN NS POBOX.FOOBAR.COM. 99999999 IN NS FOOHOST.FOOBAR.COM. foobar.com. 99999999 IN NS pobox.foobar.com. - -A: 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'. - ------------------------------- +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'. + +----------------------------------------------------------------------------- + +Question 6.2. Error - No Root Nameservers for Class XX Date: Sun Nov 27 23:32:41 EST 1994 -Subject: Q5.2 - Error - No Root Nameservers for Class XX 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? - -A: From RFC 1700: +From RFC 1700: DOMAIN NAME SYSTEM PARAMETERS The Internet Domain Naming System (DOMAIN) includes several @@ -844,44 +875,37 @@ A: From RFC 1700: 65535 Reserved [PM1] DNS information for RFC 1700 was taken from +ftp.isi.edu : /in-notes/iana/assignments/dns-parameters - ftp://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. - 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 -Subject: Q5.3 - Bind 4.9.x and MX querying? - -Q: If I 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. Why ? - -A: 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. - ------------------------------- +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. -Date: Sat Sep 9 00:36:01 EDT 1995 -Subject: Q5.4 - Some root nameservers don't know localhost +----------------------------------------------------------------------------- + +Question 6.4. Do I need to define an A record for localhost ? -Q: Do I need to define an A record for localhost ? +Date: Sat Sep 9 00:36:01 EDT 1995 - Where is the A record for 127.0.0.1 defined? I see where - the PTR record is defined pointing to localhost, but can't find - where the A record is. And is the A record supposed to be - localhost.MY_DOMAIN or just localhost ? +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: -A: 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'' @@ -890,57 +914,54 @@ A: Somewhere deep in the BOG (BIND Operations Guide) that came with 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). +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. +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 -Subject: Q5.5 - MX records and CNAMES and separate A records for MX targets - -Q: 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. I don't see - how this applies to mail spokes. RFC 974 has a similar warning, but - I can not see where it specifically prohibits using an alias in an - MX record. - -A: 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. + +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 - @@ -968,7 +989,7 @@ A: This isn't what the BOG says at all. See below. You can have a CNAME Here's the relevant BOG snippet: - aliases {ttl} addr-class CNAME Canonical name + aliases {ttl addr-class CNAME Canonical name ucbmonet IN CNAME monet The Canonical Name resource record, CNAME, speci- @@ -981,12 +1002,14 @@ A: This isn't what the BOG says at all. See below. You can have a CNAME 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 -Subject: Q5.6 - NS is a CNAME -Q: Can I do this ? Is it legal ? +Can I do this ? Is it legal ? + @ SOA (.........) NS ns.host.this.domain. @@ -994,43 +1017,39 @@ Q: Can I do this ? Is it legal ? 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. -A: 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: +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) + Dec 7 00:52:18 gw named[17561]: "foobar.com IN NS" \ + points to a CNAME (foobar.foobar.com) - Here is the reason why: +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. +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 -Subject: Q5.7 - Nameserver forgets own A record - 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 @@ -1044,17 +1063,14 @@ A: This is invariably due to not removing ALL of the cached zones 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. - ------------------------------- -Date: Sun Dec 4 22:21:22 EST 1994 -Subject: Q5.8 - General problems (core dumps !) +----------------------------------------------------------------------------- -Q: I am running bind 4.9.3b9p1 on a DEC alpha OSF/1 V3.0 and have had it - core dump while in debug mode. The last lines printed to named.run - were [...] +Question 6.8. General problems (core dumps !) -A: Paul Vixie says: +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 @@ -1067,65 +1083,216 @@ A: Paul Vixie says: 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 -Subject: Q5.9 - malloc and DECstations -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 +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://ftp.cs.wisc.edu/pub/misc/malloc.tar.gz - +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. Err/TO errors being reported + +Date: Sun May 5 23:46:32 EDT 1996 + +Why are errors like + + Apr 2 20:41:58 nameserver named[25846]: Err/TO getting serial# for + "foobar.domain1.com" + Apr 2 20:41:59 nameserver named[25846]: Err/TO getting serial# for + "foobar.domain2.com" + +reported ? These generally indicate that there is one of the following +problems: + +* A network problem between you and the primary, +* A bad IP address in named.boot, +* 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.12. 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. ------------------------------- - -Date: Fri Apr 28 13:56:32 EDT 1995 -Subject: Q6 - Acknowledgements - -Listed in e-mail address alphabetical order, the following people have -contributed to this FAQ: - -Benoit.Grange@inria.fr (Benoit.Grange) -D.T.Shield@csc.liv.ac.uk (Dave Shield) -adam@comptech.demon.co.uk (Adam Goodfellow) -andras@is.co.za (Andras Salamon) -barmar@nic.near.net (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) -cdp@hertz.njit.edu (Chris Peckham) -cricket@hp.com (Cricket Liu) -cudep@csv.warwick.ac.uk (Ian 'Vato' Dickinson [ID17]) -dparter@cs.wisc.edu (David Parter) -e07@nikhef.nl (Eric Wassenaar) -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) -jmalcolm@uunet.uu.net (Joseph Malcolm) -jhawk@panix.com (John Hawkinson) -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) -mjo@iao.ford.com (Mike O'Connor) -nick@flapjack.ieunet.ie (Nick Hilliard) -patrick@oes.amdahl.com (Patrick J. Horgan) -ph10@cus.cam.ac.uk (Philip Hazel) -rv@seins.Informatik.Uni-Dortmund.DE (Ruediger Volk) -shields@tembel.org (Michael Shields) -tanner@george.arc.nasa.gov (Rob Tanner) -vixie@vix.com (Paul A Vixie) -wag@swl.msd.ray.com (William Gianopoulos {84718}) -whg@inel.gov (Bill Gray) -wolf@pasteur.fr (Christophe Wolfhugel) + 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.) + +=============================================================================== + +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: Fri Dec 6 16:51:31 EST 1996 + +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. + +----------------------------------------------------------------------------- + +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.users.pfmc.net/~cdp/cptd-faq/cptd-faq.ascii +* BFNN: http://www.users.pfmc.net/~cdp/cptd-faq/cptd-faq.bfnn +* GNU info: http://www.users.pfmc.net/~cdp/cptd-faq/cptd-faq.info +* HTML: http://www.users.pfmc.net/~cdp/cptd-faq/index.html + +----------------------------------------------------------------------------- + +Question 7.3. Contributors + +Date: Sat Dec 7 01:29:29 EST 1996 + +Many people have helped put this list together. Listed in e-mail address +alphabetical order, the following people have contributed to this FAQ: + +* <Benoit.Grange@inria.fr> (Benoit.Grange) +* <D.T.Shield@csc.liv.ac.uk> (Dave Shield) +* <Todd.Aven@BankersTrust.Com> +* <adam@comptech.demon.co.uk> (Adam Goodfellow) +* <andras@is.co.za> (Andras Salamon) +* <barmar@nic.near.net> (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]) +* <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) +* <jhawk@panix.com> (John Hawkinson) +* <jmalcolm@uunet.uu.net> (Joseph Malcolm) +* <jprovo@augustus.ultra.net> (Joe Provo) +* <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) +* <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) +* <rocky@panix.com> (R. Bernstein) +* <rv@seins.Informatik.Uni-Dortmund.DE> (Ruediger Volk) +* <shields@tembel.org> (Michael Shields) +* <tanner@george.arc.nasa.gov> (Rob Tanner) +* <vixie@vix.com> (Paul A Vixie) +* <wag@swl.msd.ray.com> (William Gianopoulos {84718) +* <whg@inel.gov> (Bill Gray) +* <wolf@pasteur.fr> (Christophe Wolfhugel) Thank you ! |
