diff options
Diffstat (limited to 'contrib/bind/doc/misc/FAQ.2of2')
| -rw-r--r-- | contrib/bind/doc/misc/FAQ.2of2 | 1298 |
1 files changed, 0 insertions, 1298 deletions
diff --git a/contrib/bind/doc/misc/FAQ.2of2 b/contrib/bind/doc/misc/FAQ.2of2 deleted file mode 100644 index 40e16494b5bfb..0000000000000 --- a/contrib/bind/doc/misc/FAQ.2of2 +++ /dev/null @@ -1,1298 +0,0 @@ -Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers -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-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-847336183@njit.edu> -Nntp-Posting-Host: hertz.njit.edu -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-849940949@njit.edu> -Date: Sat, 7 Dec 1996 06:42:49 GMT -Approved: news-answers-request@MIT.EDU -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.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. - ------------------------------------------------------------------------------ - -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 - -That you need to subnet at all is something of a misconception. You can -also think of a class B network as giving you 65,534 individual hosts, and -such a network will work. You can also configure your class B as 16,384 -networks of 2 hosts each. That's obviously not very practical, but it -needs to be made clear that you are not constrained by the size of an -octet (remember that many older devices would not work in a network -configured in this manner). - -So, the question is: why do you need to subnet? One reason is that it is -easier to manage a subnetted network, and in fact, you can delegate the -responsibility for address space management to local administrators on the -various subnets. Also, IP based problems will end up localized rather -than affecting your entire network. - -If your network is a large backbone with numerous segments individually -branching off the backbone, that too suggests subnetting. - -Subnetting can also be used to improve routing conditions. - -You may wish to partition your network to disallow certain protocols on -certain segments of your net. You can, for example, restrict IP or IPX to -certain segments only by adding a router routing high level protocols, -and across the router you may have to subnet. - -Finally, as far as how many subnets you need depends on the answer to the -above question. As far as subnet masks are concerned, the mask can be -anything from 255.0.0.0 to 255.255.255.252. You'll probably be looking at -9 or 10 bits for the subnet (last octet 128 or 192 respectively). RFC -1219 discusses the issue of subnetting very well and leaves the network -administrator with a large amount of flexibility for future growth. - ------------------------------------------------------------------------------ - -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 - -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. - ------------------------------------------------------------------------------ - -Question 5.6. DNS on a system not connected to the Internet - -Date: Sun Nov 27 23:32:41 EST 1994 - -You need to create your own root domain name server until you connect to -the internet. Your roots need to delegate to mydomain.com and any -in-addr.arpa subdomains you might have, and that's about it. As soon as -you're connected, rip out the fake roots and use the real ones. - -It does not actually have to be another server pretending to be the root. -You can set up the name server so that it is primary for each domain above -you and leave them empty (i.e. you are foo.bar.com - claim to be primary -for bar.com and com) - -If you connect intermittently and want DNS to work when you are connected, -and "fail" when you are not, you can point the resolver at the name server -at the remote site and if the connection (SLIP/PPP) isn't up, the resolver -doesn't have a route to the remote server and since there's only one name -server in resolv.conf, the resolver quickly backs off the using -/etc/hosts. No problem. You could do the same with multiple name server -and a resolver that did configurable /etc/hosts fallback. - ------------------------------------------------------------------------------ - -Question 5.7. Multiple Domain configuration - -Date: Fri Dec 2 15:40:49 EST 1994 - -If you want to have multiple domain names pointing to the same -destination, such as: - - ftp ftp.biff.com connects user to -> ftp.biff.com - ftp ftp.fred.com connects user to -> ftp.biff.com - ftp ftp.bowser.com connects user to -> ftp.biff.com - -You may do this by using CNAMEs: - - ftp.bowser.com. IN CNAME ftp.biff.com. - -You can also do the same thing with multiple A records. - ------------------------------------------------------------------------------ - -Question 5.8. wildcard MX records - -Date: Sun Nov 27 23:32:41 EST 1994 - -Does BIND not understand wildcard MX records such as the following? - - *.foo.com MX 0 mail.foo.com. - -No. It just doesn't work. - -Explicit RR's at one level of specificity will, by design, "block" a -wildcard at a lesser level of specificity. I suspect that you have an RR -(an A RR, perhaps?) for "bar.foo.com" which is blocking the application of -your "*.foo.com" wildcard. The initial MX query is thus failing (NOERROR -but an answer count of 0), and the backup query finds the A RR for -"bar.foo.com" and uses it to deliver the mail directly (which is what you -DIDN'T want it to do). Adding an explicit MX RR for the host is therefore -the right way to handle this situation. - -See RFC 1034, Section 4.3.3 ("Wildcards") for more information on this -"blocking" behavior, along with an illustrative example. See also RFC 974 -for an explanation of standard mailer behavior in the face of an "empty" -response to one's MX query. - -Basically, what it boils down to is, there is no point in trying to use a -wildcard MX for a host which is otherwise listed in the DNS. - -It just doesn't work. - ------------------------------------------------------------------------------ - -Question 5.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: - - exact match MX - exact match A - wildcard MX - -One way to implement this is to query for ("dom",IN,MX) and if the answer -name that comes back is "*." something, you know it's a wildcard, -therefore you know there is no exact match MX, and you therefore query for -("dom",IN,A) and if you get something, use it. if you don't, use the -previous wildcard response. - -RFC 974 explains this pretty well. - ------------------------------------------------------------------------------ - -Question 5.10. Why are fully qualified domain names recommended ? - -Date: Sun Nov 27 23:32:41 EST 1994 - -The documentation for BIND 4.9.2 says that the hostname should be set to -the full domain style name (i.e host.our.domain rather than host). What -advantages are there in this, and are there any adverse consequences if we -don't? - -Paul Vixie likes to do it :-) He lists a few reasons - - -* Sendmail can be configured to just use Dj$w rather than Dj$w.mumble - where "mumble" is something you have to edit in by hand. Granted, most - people use "mumble" elsewhere in their config files ("tack on local - domain", etc) but why should it be a requirement ? -* The real reason is that not doing it violates a very useful invariant: - gethostbyname(gethostname) == gethostbyaddr(primary_interface_address) - - If you take an address and go "backwards" through the PTR's with it, - you'll get a FQDN, and if you push that back through the A RR's, you get - the same address. Or you should. Many multi-homed hosts violate this - uncaringly. - - If you take a non-FQDN hostname and push it "forwards" through the A - RR's, you get an address which, if you push it through the PTR's, comes - back as a FQDN which is not the same as the hostname you started with. - Consider the fact that, absent NIS/YP, there is no "domainname" command - analogous to the "hostname" command. (NIS/YP's doesn't count, of - course, since it's sometimes-but-only-rarely the same as the Internet - domain or subdomain above a given host's name.) The "domain" keyword in - resolv.conf doesn't specify the parent domain of the current host; it - specifies the default domain of queries initiated on the current host, - which can be a very different thing. (As of RFC 1535 and BIND 4.9.2's - compliance with it, most people use "search" in resolv.conf, which - overrides "domain", anyway.) - - What this means is that there is NO authoritative way to - programmatically discover your host's FQDN unless it is set in the - hostname, or unless every application is willing to grovel the "netstat - -in" tables, find what it hopes is the primary address, and do a PTR - query on it. - - FQDN /bin/hostnames are, intuitively or not, the simplest way to go. - ------------------------------------------------------------------------------ - -Question 5.11. Distributing load using named - -Date: Wed Mar 1 11:04:43 EST 1995 - -When you attempt to distribute the load on a system using named, the first -response be cached, and then later queries use the cached value (This -would be for requests that come through the same server). Therefore, it -can be useful to use a lower TTL on records where this is important. You -can use values like 300 or 500 seconds. - -If your local caching server has ROUND_ROBIN, it does not matter what the -authoritative servers have -- every response from the cache is rotated. - -But if it doesn't, and the authoritative server site is depending on this -feature (or the old "shuffle-A") to do load balancing, then if one doesn't -use small TTLs, one could conceivably end up with a really nasty -situation, e.g., hundreds of workstations at a branch campus pounding on -the same front end at the authoritative server's site during class -registration. - -Not nice. - -Paul Vixie has an example of the ROUND_ROBIN code in action. Here is -something that he wrote regarding his example: - - >I want users to be distributed evenly among those 3 hosts. - - Believe it or not :-), BIND offers an ugly way to do this. I offer - for your collective amusement the following snippet from the - ugly.vix.com zone file: - - hydra cname hydra1 - cname hydra2 - cname hydra3 - hydra1 a 10.1.0.1 - a 10.1.0.2 - a 10.1.0.3 - hydra2 a 10.2.0.1 - a 10.2.0.2 - a 10.2.0.3 - hydra3 a 10.3.0.1 - a 10.3.0.2 - a 10.3.0.3 - - Note that having multiple CNAME RR's at a given name is - meaningless according to the DNS RFCs but BIND doesn't mind (in - fact it doesn't even complain). If you call - gethostbyname("hydra.ugly.vix.com") (try it!) you will get - results like the following. Note that there are two round robin - rotations going on: one at ("hydra",CNAME) and one at each - ("hydra1",A) et al. I used a layer of CNAME's above the layer of - A's to keep the response size down. If you don't have nine - addresses you probably don't care and would just use a pile of - CNAME's pointing directly at real host names. - - {hydra.ugly.vix.com - name: hydra2.ugly.vix.com - aliases: hydra.ugly.vix.com - addresses: 10.2.0.2 10.2.0.3 10.2.0.1 - - {hydra.ugly.vix.com - name: hydra3.ugly.vix.com - aliases: hydra.ugly.vix.com - addresses: 10.3.0.2 10.3.0.3 10.3.0.1 - - {hydra.ugly.vix.com - name: hydra1.ugly.vix.com - aliases: hydra.ugly.vix.com - addresses: 10.1.0.2 10.1.0.3 10.1.0.1 - - {hydra.ugly.vix.com - name: hydra2.ugly.vix.com - aliases: hydra.ugly.vix.com - addresses: 10.2.0.3 10.2.0.1 10.2.0.2 - - {hydra.ugly.vix.com - name: hydra3.ugly.vix.com - aliases: hydra.ugly.vix.com - addresses: 10.3.0.3 10.3.0.1 10.3.0.2 - ------------------------------------------------------------------------------ - -Question 5.12. Order of returned records - -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. - ------------------------------------------------------------------------------ - -Question 5.13. resolv.conf - -Date: Fri Feb 10 15:46:17 EST 1995 - -The question was asked one time, "Why should I use 'real' IP addresses in -/etc/resolv.conf and not 0.0.0.0 or 127.0.0.1" ? - -Paul Vixie writes on the issue of the contents of resolv.conf: - - It's historical. Some kernels can't unbind a UDP socket's source - address, and some resolver versions (notably not including BIND - 4.9.2 or 4.9.3's) try to do this. The result can be wide area - network traffic with 127.0.0.1 as the source address. Rather than - giving out a long and detailed map of version/vendor combinations of - kernels/BINDs that have/don't this problem, I just tell folks not to - use 127.0.0.1 at all. - - 0.0.0.0 is just an alias for the first interface address assigned - after a system boot, and if that interface is a up-and-down point to - point link (PPP, SLIP, whatever), there's no guarantee that you'll - be able to reach yourself via 0.0.0.0 during the entire lifetime of - any system instance. On most kernels you can finesse this by adding - static routes to 127.0.0.1 for each of your interface addresses, but - some kernels don't like that trick and rather than give a detailed - map of which ones work and which ones don't, I just globally - recommend against 0.0.0.0. - - If you know enough to know that 127.0.0.1 or 0.0.0.0 is safe on your - kernel and resolver, then feel free to use them. If you don't know - for sure that it is safe, don't use them. I never use them (except - on my laptop, whose hostname is "localhost" and whose 0.0.0.0 is - 127.0.0.1 since I ifconfig my lo0 before any other interface). The - operational advantage to using a real IP address rather than an - wormhole like 0.0.0.0 or 127.0.0.1, is that you can then "rdist" or - otherwise share identical copies of your resolv.conf on all the - systems on any given subnet, not all of which will be servers. - -The problem was with older versions of the resolver (4.8.X). If you -listed 127.0.0.1 as the first entry in resolv.conf, and for whatever -reason the local name server wasn't running and the resolver fell back to -the second name server listed, it would send queries to the name server -with the source IP address set to 127.0.0.1 (as it was set when the -resolver was trying to send to 127.0.0.1--you use the loopback address to -send to the loopback address). - ------------------------------------------------------------------------------ - -Question 5.14. How do I delegate authority for sub-domains ? - -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 - - @ 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. - ------------------------------------------------------------------------------ - -Question 5.15. DNS instead of NIS on a Sun OS 4.1.x system - -Date: Sat Dec 7 01:14:17 EST 1996 - -Comments relating to running bind 4.9.x on a Sun OS 4.1.x system and the -effect on sendmail, ftp, telnet and other TCP/IP services bypassing NIS -and directly using named is documented quite well in the -comp.sys.sun.admin FAQ in questions one and two. You can get them from: - -* ftp.ece.uc.edu : /pub/sun-faq/FAQs/sun-faq.general -* http://www.cis.ohio-state.edu/hypertext/faq/usenet/comp-sys-sun-faq - -as well as from rtfm.mit.edu in the usual place, etc. - ------------------------------------------------------------------------------ - -Question 5.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 - -Q: I've been getting the following messages lately from bind-4.9.2.. - ns_req: no address for root server - -We are behind a firewall and have the following for our named.cache file - - - ; list of servers - . 99999999 IN NS POBOX.FOOBAR.COM. - 99999999 IN NS FOOHOST.FOOBAR.COM. - foobar.com. 99999999 IN NS pobox.foobar.com. -You can't do that. Your nameserver contacts POBOX.FOOBAR.COM, gets the -correct list of root servers from it, then tries again and fails because -of your firewall. - -You will need a 'forwarder' definition, to ensure that all requests are -forwarded to a host which can penetrate the firewall. And it is unwise to -put phony data into 'named.cache'. - ------------------------------------------------------------------------------ - -Question 6.2. Error - No Root Nameservers for Class XX - -Date: Sun Nov 27 23:32:41 EST 1994 - -Q: I've received errors before about "No root nameservers for class XX" - but they've been because of network connectivity problems. - I believe that Class 1 is Internet Class data. - And I think I heard someone say that Class 4 is Hesiod?? - Does anyone know what the various Class numbers are? -From RFC 1700: - - DOMAIN NAME SYSTEM PARAMETERS - The Internet Domain Naming System (DOMAIN) includes several - parameters. These are documented in [RFC1034] and [RFC1035]. The - CLASS parameter is listed here. The per CLASS parameters are - defined in separate RFCs as indicated. - - Domain System Parameters: - - Decimal Name References - -------- ---- ---------- - 0 Reserved [PM1] - 1 Internet (IN) [RFC1034,PM1] - 2 Unassigned [PM1] - 3 Chaos (CH) [PM1] - 4 Hesoid (HS) [PM1] - 5-65534 Unassigned [PM1] - 65535 Reserved [PM1] - -DNS information for RFC 1700 was taken from -ftp.isi.edu : /in-notes/iana/assignments/dns-parameters - -Hesiod is class 4, and there are no official root nameservers for class 4, -so you can safely declare yourself one if you like. You might want to -put up a packet filter so that no one outside your network is capable of -making Hesiod queries of your machines, if you define yourself to be a -root nameserver for class 4. - ------------------------------------------------------------------------------ - -Question 6.3. Bind 4.9.x and MX querying? - -Date: Sun Nov 27 23:32:41 EST 1994 - -If you query a 4.9.x DNS server for MX records, a list of the MX records -as well as a list of the authorative nameservers is returned. This -happens because bind 4.9.2 returns the list of nameserver that are -authorative for a domain in the response packet, along with their IP -addresses in the additional section. - ------------------------------------------------------------------------------ - -Question 6.4. Do I need to define an A record for localhost ? - -Date: Sat Sep 9 00:36:01 EDT 1995 - -Somewhere deep in the BOG (BIND Operations Guide) that came with 4.9.3 -(section 5.4.3), it says that you define this yourself (if need be) in -the same zone files as your "real" IP addresses for your domain. Quoting -the BOG: - - - ... As implied by this PTR - record, there should be a ``localhost.my.dom.ain'' - A record (with address 127.0.0.1) in every domain - that contains hosts. ``localhost.'' will lose its - trailing dot when 1.0.0.127.in-addr.arpa is queried - for;... - -The sample files in the BIND distribution show you what needs to be done -(see the BOG). - -Some HP boxen (especially those running HP OpenView) will also need -"loopback" defined with this IP address. You may set it as a CNAME -record pointing to the "localhost." record. - ------------------------------------------------------------------------------ - -Question 6.5. MX records, CNAMES and A records for MX targets - -Date: Sun Nov 27 23:32:41 EST 1994 - -The O'Reilly "DNS and Bind" book warns against using non-canonical names -in MX records, however, this warning is given in the context of mail hubs -that MX to each other for backup purposes. How does this apply to mail -spokes. RFC 974 has a similar warning, but where is it specifically -prohibited to us an alias in an MX record ? - -Without the restrictions in the RFC, a MTA must request the A records for -every MX listed to determine if it is in the MX list then reduce the list. -This introduces many more lookups than would other wise be required. If -you are behind a 1200 bps link YOU DON'T WANT TO DO THIS. The addresses -associated with CNAMES are not passed as additional data so you will force -additional traffic to result even if you are running a caching server -locally. - -There is also the problem of how does the MTA find all of it's IP -addresses. This is not straight forward. You have to be able to do this is -you allow CNAMEs (or extra A's) as MX targets. - -The letter of the law is that an MX record should point to an A record. - -There is no "real" reason to use CNAMEs for MX targets or separate As for -nameservers any more. CNAMEs for services other than mail should be used -because there is no specified method for locating the desired server yet. - -People don't care what the names of MX targets are. They're invisible to -the process anyway. If you have mail for "mary" redirected to "sue" is -totally irrelevant. Having CNAMEs as the targets of MX's just needlessly -complicates things, and is more work for the resolver. - -Having separate A's for nameservers like "ns.your.domain" is pointless -too, since again nobody cares what the name of your nameserver is, since -that too is invisible to the process. If you move your nameserver from -"mary.your.domain" to "sue.your.domain" nobody need care except you and -your parent domain administrator (and the InterNIC). Even less so for -mail servers, since only you are affected. - -Q: Given the example - - - hello in cname realname - mailx in mx 0 hello - - Now, while reading the operating manual of bind it clearly states - that this is *not* valid. These two statements clearly contradict - each other. Is there some later rfc than 974 that overrides what is - said in there with respect to MX and CNAMEs? Anyone have the - reference handy? - -A: This isn't what the BOG says at all. See below. You can have a CNAME - that points to some other RR type; in fact, all CNAMEs have to point - to other names (Canonical ones, hence the C in CNAME). What you - can't have is an MX that points to a CNAME. MX RR's that point to - names which have only CNAME RR's will not work in many cases, and - RFC 974 intimates that it's a bad idea: - - Note that the algorithm to delete irrelevant RRs breaks if LOCAL has - a alias and the alias is listed in the MX records for REMOTE. (E.g. - REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This - can be avoided if aliases are never used in the data section of MX - RRs. - - Here's the relevant BOG snippet: - - aliases {ttl addr-class CNAME Canonical name - ucbmonet IN CNAME monet - - The Canonical Name resource record, CNAME, speci- - fies an alias or nickname for the official, or - canonical, host name. This record should be the - only one associated with the alias name. All other - resource records should be associated with the - canonical name, not with the nickname. Any - resource records that include a domain name as - their value (e.g., NS or MX) must list the canoni- - cal name, not the nickname. - ------------------------------------------------------------------------------ - -Question 6.6. Can an NS record point to a CNAME ? - -Date: Wed Mar 1 11:14:10 EST 1995 - -Can I do this ? Is it legal ? - - - @ SOA (.........) - NS ns.host.this.domain. - NS second.host.another.domain. - ns CNAME third - third IN A xxx.xxx.xxx.xxx - -No. Only one RR type is allowed to refer, in its data field, to a CNAME, -and that's CNAME itself. So CNAMEs can refer to CNAMEs but NSs and MXs -cannot. - -BIND 4.9.3 (Beta11 and later) explicitly syslogs this case rather than -simply failing as pre-4.9 servers did. Here's a current example: - - Dec 7 00:52:18 gw named[17561]: "foobar.com IN NS" \ - points to a CNAME (foobar.foobar.com) - -Here is the reason why: - -Nameservers are not required to include CNAME records in the Additional -Info section returned after a query. It's partly an implementation -decision and partly a part of the spec. The algorithm described in RFC -1034 (pp24,25; info also in RFC 1035, section 3.3.11, p 18) says 'Put -whatever addresses are available into the additional section, using glue -RRs [if necessary]'. Since NS records are speced to contain only primary -names of hosts, not CNAMEs, then there's no reason for algorithm to -mention them. If, on the other hand, it's decided to allow CNAMEs in NS -records (and indeed in other records) then there's no reason that CNAME -records might not be included along with A records. The Additional Info -section is intended for any information that might be useful but which -isn't strictly the answer to the DNS query processed. It's an -implementation decision in as much as some servers used to follow CNAMEs -in NS references. - ------------------------------------------------------------------------------ - -Question 6.7. Nameserver forgets own A record - -Date: Fri Dec 2 16:17:31 EST 1994 - -Q: Lately, I've been having trouble with named 4.9.2 and 4.9.3. - Periodically, the nameserver will seem to "forget" its own A record, - although the other information stays intact. One theory I had was - that somehow a site that the nameserver was secondary for was - "corrupting" the A record somehow. - -A: This is invariably due to not removing ALL of the cached zones - when you moved to 4.9.X. Remove ALL cached zones and restart - your nameservers. - - You get "ignoreds" because the primaries for the relevant zones are - running old versions of BIND which pass out more glue than is - required. named-xfer trims off this extra glue. - ------------------------------------------------------------------------------ - -Question 6.8. General problems (core dumps !) - -Date: Sun Dec 4 22:21:22 EST 1994 - -Paul Vixie says: - - I'm always interested in hearing about cases where BIND dumps core. - However, I need a stack trace. Compile with -g and not -O (unless - you are using gcc and know what you are doing) and then when it - dumps core, get into dbx or gdb using the executable and the core - file and use "bt" to get a stack trace. Send it to me - <paul@vix.com> along with specific circumstances leading to or - surrounding the crash (test data, tail of the debug log, tail of the - syslog... whatever matters) and ideally you should save your core - dump for a day or so in case I have questions you can answer via - gdb/dbx. - ------------------------------------------------------------------------------ - -Question 6.9. malloc and DECstations - -Date: Mon Jan 2 14:19:22 EST 1995 - -We have replaced malloc on our DECstations with a malloc that is more -compact in memory usage, and this helped the operation of bind a lot. The -source is now available for anonymous ftp from - -ftp.cs.wisc.edu : /pub/misc/malloc.tar.gz - ------------------------------------------------------------------------------ - -Question 6.10. Can't resolve names without a "." - -(Answer written by Mark Andrews) You are not using a RFC 1535 aware -resolver. Depending upon the age of your resolver you could try adding a -search directive to resolv.conf. - - e.g. - domain <domain> - search <domain> [<domain2> ...] - -If that doesn't work you can configure you server to serve the parent and -grandparent domains as this is the default search list. - -"domain langley.af.mil" has an implicit "search langley.af.mil af.mil mil" -in the old resolvers, and you are timing out trying to resolve the -address with one of these domains tacked on. - -When resolving internic.net the following will be tried in order. - internic.net.langley.af.mil - internic.net.af.mil - internic.net.mil - internic.net. - -RFC 1535 aware resolvers try qualified address first. - - internic.net. - internic.net.langley.af.mil - internic.net.af.mil - internic.net.mil -RFC 1535 documents the problems associated with the old search -algorithim, including security issues, and how to alleviate some of the -problems. - ------------------------------------------------------------------------------ - -Question 6.11. 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. - - 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 ! - |