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