diff options
Diffstat (limited to 'contrib/bind/doc/misc/FAQ.2of2')
| -rw-r--r-- | contrib/bind/doc/misc/FAQ.2of2 | 1131 |
1 files changed, 1131 insertions, 0 deletions
diff --git a/contrib/bind/doc/misc/FAQ.2of2 b/contrib/bind/doc/misc/FAQ.2of2 new file mode 100644 index 0000000..ae453c9 --- /dev/null +++ b/contrib/bind/doc/misc/FAQ.2of2 @@ -0,0 +1,1131 @@ +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) +Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2) +Message-ID: <cptd-faq-2-810621452@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> +Nntp-Posting-Host: hertz.njit.edu +X-Posting-Frequency: posted on the 1st 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 +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 + +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). + + 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. + +------------------------------- + +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 + +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: + + 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. + + +------------------------------ + +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: + + 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 interally; 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 + synch. 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. + +------------------------------ + +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. + +------------------------------ + +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: + + 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: + + ftp.bowser.com. IN CNAME ftp.biff.com. + + You can also do the same thing with multiple A 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? + + *.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 + + +Q: How do you identify a wildcard MX record ? + +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. + +------------------------------ + +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: + + 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. + +------------------------------ + +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. + + 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. + +A: 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 + + +------------------------------ + +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? + + 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. + +A: 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. + +------------------------------ + +Date: Fri Feb 10 15:46:17 EST 1995 +Subject: Q4.12 - resolv.conf + + +Q: 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: + + 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. + +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). + +------------------------------ + +Date: Mon Jan 2 13:50:13 EST 1995 +Subject: Q4.13 - Delegating authority + +Q: How do I delegate authority for domains within my domain ? + +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. + 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. + + +------------------------------ + +Date: Wed Mar 1 11:45:00 EST 1995 +Subject: Q4.14 - 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: + + 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 + + as well as from rtfm.mit.edu in the usual place, etc. + + +------------------------------ + +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 + +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. + +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'. + +------------------------------ + +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: + + 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://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. + +------------------------------ + +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. + +------------------------------ + +Date: Sat Sep 9 00:36:01 EDT 1995 +Subject: Q5.4 - Some root nameservers don't know localhost + +Q: Do I need to define an A record for localhost ? + + 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 ? + +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'' + 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. + +------------------------------ + +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. + +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. + +------------------------------ + +Date: Wed Mar 1 11:14:10 EST 1995 +Subject: Q5.6 - NS is a CNAME + +Q: 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 + + +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: + + 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. + + +------------------------------ + +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 + 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. + +------------------------------ + +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 [...] + +A: 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. + +------------------------------ + +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 + + ftp://ftp.cs.wisc.edu/pub/misc/malloc.tar.gz + + +------------------------------ + +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) + +Thank you ! + |
