diff options
| author | peter <peter@FreeBSD.org> | 1996-08-29 19:20:22 +0000 |
|---|---|---|
| committer | peter <peter@FreeBSD.org> | 1996-08-29 19:20:22 +0000 |
| commit | 2d3cf9fcaf1ca2528c5fe3ba683d1f6c1268dc41 (patch) | |
| tree | 8652a0312f865a787c6c1c3003491b4e62ce0ea7 /contrib/bind/doc/misc | |
| download | FreeBSD-src-2d3cf9fcaf1ca2528c5fe3ba683d1f6c1268dc41.zip FreeBSD-src-2d3cf9fcaf1ca2528c5fe3ba683d1f6c1268dc41.tar.gz | |
Take #2. Import bind-4.9.4-P1 into the intended directory!
This has most of the non-essential stuff removed (ie: what is not built)
bmake glue to follow.
Diffstat (limited to 'contrib/bind/doc/misc')
| -rw-r--r-- | contrib/bind/doc/misc/FAQ.1of2 | 1339 | ||||
| -rw-r--r-- | contrib/bind/doc/misc/FAQ.2of2 | 1131 | ||||
| -rw-r--r-- | contrib/bind/doc/misc/IPv6 | 72 | ||||
| -rw-r--r-- | contrib/bind/doc/misc/dns-setup | 1081 | ||||
| -rw-r--r-- | contrib/bind/doc/misc/style.txt | 172 |
5 files changed, 3795 insertions, 0 deletions
diff --git a/contrib/bind/doc/misc/FAQ.1of2 b/contrib/bind/doc/misc/FAQ.1of2 new file mode 100644 index 0000000..ab55bea --- /dev/null +++ b/contrib/bind/doc/misc/FAQ.1of2 @@ -0,0 +1,1339 @@ +Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers +Path: vixie!news1.digital.com!uunet!in1.uu.net!usc!rutgers!njitgw.njit.edu!hertz.njit.edu!cdp2582 +From: cdp@njit.edu (Chris Peckham) +Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 1 of 2) +Message-ID: <cptd-faq-1-810621452@njit.edu> +Followup-To: comp.protocols.tcp-ip.domains +Originator: cdp2582@hertz.njit.edu +Keywords: BIND,DOMAIN,DNS +Sender: news@njit.edu +Supersedes: <cptd-faq-1-807632375@njit.edu> +Nntp-Posting-Host: hertz.njit.edu +X-Posting-Frequency: posted on the 1st of each month +Reply-To: domain-faq@njit.edu (comp.protocols.tcp-ip.domains FAQ comments) +Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA +Date: Sat, 9 Sep 1995 04:37:47 GMT +Approved: news-answers-request@MIT.EDU +Expires: Sat 14 Oct 95 00:37:32 EDT +Lines: 1319 +Xref: vixie comp.protocols.tcp-ip.domains:6018 comp.answers:13881 news.answers:49918 + +Posted-By: auto-faq 3.1.1.2 +Archive-name: internet/tcp-ip/domains-faq/part1 +Revision: 1.6 1995/05/12 18:49:48 + + +This FAQ is edited and maintained by Chris Peckham, <cdp@njit.edu>. +The latest version may always be found for anonymous ftp from + + ftp://rtfm.mit.edu/pub/usenet/news.answers/internet/tcp-ip/domains-faq + ftp://ftp.njit.edu/pub/dns/Comp.protocols.tcp-ip.domains.FAQ + +If you can contribute any answers for items in the TODO section, please do +so by sending e-mail to domain-faq@njit.edu ! If you know of any items that +are not included and you feel that they should be, send the relevant +information to domain-faq@njit.edu. + + +------------------------------ + +Date: Fri May 12 14:41:47 EDT 1995 +Subject: Table of Contents + +Table of Contents +================= +Part 1 +------ + 0. TO DO + 1. INTRODUCTION / MISCELLANEOUS + 1.1 What is this newsgroup ? + 1.2 More information + 1.3 What is BIND and where is the latest version of BIND ? + 1.4 How can I find the route between systems ? + 1.5 Finding the hostname if you have the tcp-ip address + 1.6 How to register a domain name + 1.7 Change of Domain name + 1.8 How memory and CPU does DNS use ? + 1.9 Other things to consider when planning your servers + 1.10 Proper way to get NS and reverse IP records into DNS + 1.11 How to get my address assign from NIC? + 1.12 Is there a block of private IP addresses I can use? + 1.13 Cache failed lookups + 1.14 What does an NS record really do ? + 1.15 DNS ports + 1.16 Obtaining the latest cache file + 2. UTILITIES + 2.1 Utilities to administer DNS zone files + 2.2 DIG - Domain Internet Groper + 2.3 DNS packet analyzer + 2.4 host + 2.5 Programming with DNS + 2.6 A source of information relating to DNS + 3. DEFINITIONS + 3.1 TCP/IP Host Naming Conventions + 3.2 Slaves and servers with forwarders + 3.3 When is a server authoritative? + 3.4 Underscore in host-/domain names + 3.5 Lame delegation + 3.6 What does opt-class field do? + 3.7 Top level domains + 3.8 Classes of networks + 3.9 What is CIDR ? + 3.10 What is the rule for glue ? + +Part 2 +------ + 4. CONFIGURATION + 4.1 Changing a Secondary server to a Primary + 4.2 How do I subnet a Class B Address ? + 4.3 Subnetted domain name service + 4.4 Recommended format/style of DNS files + 4.5 DNS on a system not connected to the Internet + 4.6 Multiple Domain configuration + 4.7 wildcard MX records + 4.8 How to identify a wildcard MX record + 4.9 Why are fully qualified domain names recommended ? + 4.10 Distributing load using named + 4.11 Order of returned records + 4.12 resolv.conf + 4.13 Delegating authority + 4.14 DNS instead of NIS on a Sun OS 4.1.x system + 5. PROBLEMS + 5.1 No address for root server + 5.2 Error - No Root Nameservers for Class XX + 5.3 Bind 4.9.x and MX querying? + 5.4 Some root nameservers don't know localhost + 5.5 MX records and CNAMES and separate A records for MX targets + 5.6 NS is a CNAME + 5.7 Nameserver forgets own A record + 5.8 General problems (core dumps !) + 5.9 malloc and DECstations + 6. ACKNOWLEDGEMENTS + +------------------------------ + +Date: Wed May 3 12:55:13 EDT 1995 +Subject: Q0 - TO DO list + + +* How to do an initial installation +* How to change service providers (what happens) +* Explain the difference between BIND (an implementation) and DNS (spec) +* Expand the slave/forward section of Q 3.2 +* Add a definition of a "private domain" in discussion (or cut it out) +* mention mail-to-news gateways for newsgroup, mailing lists, anonymous + ftp, etc in what is newsgroup section +* The evils of wildcard MX records + + + +------------------------------- + +Date: Thu Dec 1 11:08:28 EST 1994 +Subject: Q1.1 - What is this newsgroup ? + +comp.protocols.tcp-ip.domains is the usenet newsgroup for discussion +on issues relating to the Domain Name System (DNS). + +This newsgroup is not for issues directly relating to IP routing and +addressing. Issues of that nature should be directed towards +comp.protocols.tcp-ip. + + +------------------------------- + + +Date: Fri May 12 13:54:01 EDT 1995 +Subject: Q1.2 - More information + + You can find more information concerning DNS in the following places: + + * The BOG (BIND Operations Guide) - in the BIND distribution + * The FAQ included with bind4.9.3 doc/misc/FAQ + * DNS and BIND by Albitz and Liu (an O'Reilly & Associates Nutshell + handbook) + * A number of RFCs (920, 974, 1032, 1034, 1101, 1123, 1178, 1183, 1348, + 1535, 1536, 1537, 1591, 1706, 1712, 1713) + * The DNS Resource Directory (DNSRD) + http://www.dns.net/dnsrd + * If you are having troubles relating to sendmail and DNS, you may wish to + refer to the USEnet newsgroup comp.mail.sendmail and/or the FAQ for that + newsgroup + ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/sendmail-faq + * Information concerning some frequently asked questions relating to + the Internet (i.e., what is the InterNIC, what is an RFC, what is the + IETF, etc) may be found for anonymous ftp from + ftp://ds.internic.net/fyi/fyi4.txt + A version may also be obtained with the URL + gopher://ds.internic.net/00/fyi/fyi4.txt + + +------------------------------- + +Date: Fri Aug 4 10:18:58 EDT 1995 +Subject: Q1.3 - What is BIND and where is the latest version of BIND ? + +Q: What is BIND ? + +A: From the BOG Introduction - + + The Berkeley Internet Name Domain (BIND) implements + an Internet name server for the BSD operating system. + The BIND consists of a server (or ``daemon'') and a + resolver library. A name server is a network service + that enables clients to name resources or objects and + share this information with other objects in the network. + This in effect is a distributed data base system for + objects in a computer network. BIND is fully integrated + into BSD (4.3 and later releases) network programs for + use in storing and retrieving host names and address. + The system administrator can configure the system to use + BIND as a replacement to the older host table lookup of + information in the network hosts file /etc/hosts. The + default configuration for BSD uses BIND. + +Q: Where is the latest non-beta version of BIND ? + +A: The latest non-beta version of BIND is version 4.9.2. This can be + found for anonymous ftp from + + ftp://gatekeeper.dec.com/pub/misc/vixie/4.9.2-940221.tar.gz + +Q: Where is the latest version of 4.9.3 located ? + +A: You can reference this URL: + + http://www.isc.org/isc/ + + At this time, the latest version of 4.9.3 may be found for anonymous ftp + from + + ftp://ftp.vix.com/pub/bind/testing/bind-4.9.3-BETA24.tar.gz + + You will need GNU zip, Larry Wall's patch program (if there are any + patch files), and a C compiler to get BIND running from the above + mentioned source. + + GNU zip is available for anonymous ftp from + + ftp://prep.ai.mit.edu/pub/gnu/gzip-1.2.4.tar + + patch is available for anonymous ftp from + + ftp://prep.ai.mit.edu/pub/gnu/patch-2.1.tar.gz + +------------------------------ + +Date: Mon Jan 2 13:27:27 EST 1995 +Subject: Q1.4 - How can I find the route between systems + +Q: How can I find the path taken by packets between two systems/domains ? + +A: Get the source of the 'traceroute' command, compile it and install + it on your system. + + One version of this program with additional functionality may be found + for anonymous ftp from + + ftp://ftp.nikhef.nl/pub/network/traceroute.tar.Z + + This package is mirrored at + + ftp://ftp.njit.edu/pub/dns/nikhef/traceroute.tar.Z + + Another version may be found for anonymous ftp from + + ftp://ftp.psc.edu/pub/net_tools/traceroute.tar + + +------------------------------ + +Date: Thu Dec 1 09:55:24 EST 1994 +Subject: Q1.5 - Finding the hostname if you have the tcp-ip address + +Q: Can someone tell me how can I find the name of the domain if I know the + tcp-ip address of the domain? Is there some kind of service for this? + +A: For an address a.b.c.d you can always do: + +% nslookup +> set q=ptr +> d.c.b.a.in-addr.arpa. + + Most newer version of nslookup (since 4.8.3) will recognize an address, + so you can just say: + +% nslookup a.b.c.d + + DiG will work like this also: + +$ dig -x a.b.c.d + + Host from the contrib/host from the bind distribution may also be used. + +------------------------------- + +Date: Fri Apr 28 13:16:32 EDT 1995 +Subject: Q1.6 - How to register a domain name + +Q: I would like to register a domain. How do I do this ? Can a name be + reserved, or must we already have an IP address and be hooked up to the + Internet before obtaining a domain name? + +A: You can talk to your Internet Service Provider (ISP). They can submit + the registration for you. If you are not going to be directly + connected, they should be able to offer MX records for your domain + for mail delivery (so that mail sent to the new domain will be sent + to your "standard" account). In the case where the registration is + done by the organization itself, it still makes the whole process + much easier if the ISP is approached for secondary servers _before_ + the InterNIC is approached for registration. + + For information about making the registration yourself, look to the + InterNIC ! + + ftp://internic.net/templates/ + gopher://rs.internic.net/ + http://www.internic.net/infoguide.html + http://www.ripe.net + + You will need at least two domain name servers when you register your + domain. Many ISP's are willing to provide primary and/or secondary name + service for their customers. + + Many times, registration of a domain name can be initiated by sending + e-mail to the zone contact. You can obtain the contact in the + SOA record for the country, or in a whois server: + + $ nslookup -type=SOA fr. + origin = ns1.nic.fr + mail addr = nic.nic.fr + ... + + The mail address to contact in this case is 'nic@nic.fr' (you must + substitute an '@' for the first dot in the mail addr field). + + An alternate method to obtain the e-mail address of the national NIC + is the 'whois' server at InterNIC. + + You may be requested to make your request to another email address or + using a certain information template/application. + + +------------------------------- + +Date: Sun Nov 27 23:32:41 EST 1994 +Subject: Q1.7 - Change of Domain name + +Q: We are preparing for a change of our domain name: + abc.foobar.com -> foobar.net + + What are the tricks and caveats we should be aware of ? + +A: The forward zones are easy and there are a number of ways to do it. + One way is the following: + + Have a single db file for the 2 domains, and have a single machine + be the primary server for both abc.foobar.com and foobar.net. + + To resolve the host foo in both domains, use a single zone file which + merely uses this for the host: + +foo IN A 1.2.3.4 + + Use a "@" wherever the domain would be used ie for the SOA: + +@ IN SOA (... + + Then use this pair of lines in your named.boot: + +primary abc.foobar.com db.foobar +primary foobar.net db.foobar + + The reverse zones should either contain PTRs to both names, + or to whichever name you believe to be canonical currently. + +------------------------------- + +Date: Fri Apr 28 13:52:20 EDT 1995 +Subject: Q1.8 - How memory and CPU does DNS use ? + +Q: How much memory and CPU does DNS use ? + +A: It can use quite a bit ! The main thing that BIND needs is memory. + It uses very little CPU or network bandwidth. The main + considerations to keep in mind when planning are: + + 1) How many zones do you have and how large are they ? + 2) How many clients do you expect to serve and how active are they ? + + As an example, here is a snapshot of memory usage from CSIRO Division + of Mathematics and Statistics, Australia + + Named takes several days to stabalize its memory usage. + + Our main server stabalises at ~10Mb. It takes about 3 days to + reach this size from 6 M at startup. This is under Sun OS 4.1.3U1. + + As another example, here is the configuration of ns.uu.net (from late + 1994): + + ns.uu.net only does nameservice. It is running a version of BIND + 4.9.3 on a Sun Classic with 96 MB of RAM, 220 MB of swap (remember + that Sun OS will reserve swap for each fork, even if it is not needed) + running Sun OS 4.1.3_U1. + + Joseph Malcolm, of Alternet, states that named generally hovers at + 5-10% of the CPU, except after a reload, when it eats it all. He + also states that if you are interested in the network connectivity + around the system (ns.uu.net is located off of Falls-Church4), a + PostScript map is available for anonymous ftp from + + ftp://ftp.uu.net/uunet-info/alternet.map.ps + + +------------------------------- + +Date: Mon Jan 2 14:24:51 EST 1995 +Subject: Q1.9 - Other things to consider when planning your servers + + When making the plans to set up your servers, you may want to also + consider the following issues: + + A) Server O/S limitations/capacities (which tend to be widely + divergent from vendor to vendor) + B) Client resolver behavior (even more widely divergent) + C) Expected query response time + D) Redundancy + E) Desired speed of change propagation + F) Network bandwidth availability + G) Number of zones/subdomain-levels desired + H) Richness of data stored (redundant MX records? HINFO records?) + I) Ease of administration desired + J) Network topology (impacts reverse-zone volume) + + Assuming a best-possible case for the factors above, particularly (A), (B), + (C), (F), (G) & (H), it would be possible to run a 1000-node domain + using a single lowly 25 or 40 MHz 386 PC with a fairly modest amount of RAM + by today's standards, e.g. 4 or 8 Meg. However, this configuration would + be slow, unreliable, and would provide no functionality beyond your basic + address-to-name and name-to-address mappings. + + Beyond that baseline case, depending on what factors listed above, + you may want look at other strategies, such splitting up the DNS + traffic among several machines strategically located, possibly larger ones, + and/or subdividing your domain itself. There are many options, tradeoffs, + and DNS architectural paradigms from which to choose. + + +------------------------------ + +Date: Mon Jan 2 13:03:53 EST 1995 +Subject: Q1.10 - Proper way to get NS and reverse IP records into DNS + + +Q: Reverse domain registration is separate from forward domain registration. + How do I get it updated ? + +A: Blocks of network addresses have been delegated by the InterNIC. Check + if your network a.b.c.0 is in such a block by using nslookup: + + nslookup -type=soa c.b.a.in-addr.arpa. + nslookup -type=soa b.a.in-addr.arpa. + nslookup -type=soa a.in-addr.arpa. + + One of the above should give you the information you are looking for + (the others will return with an error something like `*** No start of + authority (SOA) records available for ...') + This will give you the email address of the person to whom you should + address your change request. + + If none of these works, your network probably has not been delegated + by the InterNIC and you need to contact them directly. + + CIDR has meant that the registration is delegated, but registration + of in-addr.arpa has always been separate from forward zones - and + for good reason - in that the forward and reverse zones may have + different policies, contents etc, may be served by a different set + of nameservers, and exist at different times (usually only at point + of creation). There isn't a one-to-one mapping between the two, so + merging the registration would probably cause more problems than + people forgetting/not-knowing that they had to register in-addr.arpa + zones separately. For example, there are organizations that have + hundreds of networks and two or more domains, with a sprinkling of + machines from each network in each of the domains. + + +------------------------------- + +Date: Mon Jan 2 13:08:38 EST 1995 +Subject: Q1.11 - How to get my address assign from NIC ? + + +Q: Can anyone tell me how can I get the address from NIC? How many subnets + will NIC give to me? + +A: You should probably ask your Internet provider to give you an address. + These days, addresses are being distributed through the providers, + so that they can assign adjacent blocks of addresses to sites that + go through the same provider, to permit more efficient routing on + the backbones. + + Unless you have thousands of hosts, you probably won't be able to get a + class B these days. Instead, you can get a series of class C networks. + Large requests will be queried, so be ready to provide a network plan if + you ask for more than 16 class C networks. + + If you can't do this through your Internet provider, you can look for a + subnet registration form on rs.internic.net. See the answer in this FAQ + to the question "How to register a domain name" for a URL to these + forms. + +------------------------------- + +Date: Mon Jan 2 13:12:01 EST 1995 +Subject: Q1.12 -Is there a block of private IP addresses I can use? + + +Q: Is there a block of private IP addresses I can use? + +A: This answer may be found in the FAQ for the newsgroup comp.dcom.sys.cisco + available for anonymous ftp from + + ftp://rtfm.mit.edu/pub/usenet/comp.dcom.sys.cisco + + There is a block of private IP addresses that you can use. However + whether you wish to do so is an issue of some debate. + + There are two RFCs which discuss this issue, and present opposing + views: + +1597 Address Allocation for Private Internets. Y. Rekhter, B. + Moskowitz, D. Karrenberg & G. de Groot. March 1994. (Format: + TXT=17430 bytes) + +1627 Network 10 Considered Harmful (Some Practices Shouldn't be + Codified). E. Lear, E. Fair, D. Crocker & T. Kessler. June 1994. + (Format: TXT=18823 bytes) + + Neither one of these RFCs is anything more than a set of informational + guidelines; they are *not* words to live by (remember that RFC stands + for Request For Comments). If you're seriously considering using + private IP addresses, please read them both. + + In any event, RFC 1597 documents the allocation of the following + addresses for use by ``private internets'': + + 10.0.0.0 - 10.255.255.255 + 172.16.0.0 - 172.31.255.255 + 192.168.0.0 - 192.168.255.255 + + Most importantly, it is vital that nothing using these addresses + should ever connect to the global Internet, or have plans to do so. + Please read the above RFCs before considering implementing such + a policy. + + +------------------------------- + +Date: Mon Jan 2 13:55:50 EST 1995 +Subject: Q1.13 - Cache failed lookups + +Q: Does BIND cache negative answers (failed DNS lookups) ? + +A: Yes, BIND 4.9.3 will cache negative answers. + + +------------------------------- + +Date: Fri Feb 10 15:35:07 EST 1995 +Subject: Q1.14 - What does an NS record really do ? + +Q: What does a NS record really do ? + +A: The NS records in your zone data file pointing to the zone's name + servers (as opposed to the servers of delegated subdomains) don't do + much. They're essentially unused, though they are returned in the + authority section of reply packets from your name servers. + +------------------------------- + +Date: Fri Feb 10 15:40:10 EST 1995 +Subject: Q1.15 - DNS ports + +Q: Does anyone out there have any information/experience on exactly which + TCP/UDP ports DNS uses to send and receive queries ? + +A: Use the following chart: + + Prot Src Dst Use + udp 53 53 Queries between servers (eg, recursive queries) + Replies to above + tcp 53 53 Queries with long replies between servers, zone + transfers Replies to above + udp >1023 53 Client queries (sendmail, nslookup, etc ...) + udp 53 >1023 Replies to above + tcp >1023 53 Client queries with long replies + tcp 53 >1023 Replies to above + + Note: >1023 is for non-priv ports on Un*x clients. On other client + types, the limit may be more or less. + + Another point to keep in mind when designing filters for DNS is that a + DNS server uses port 53 both as the source and destination for it's + queries. So, a client queries an initial server from an unreserved + port number to UDP port 53. If the server needs to query another + server to get the required info, it sends a UDP query to that server + with both source and destination ports set to 53. The response is then + sent with the same src=53 dest=53 to the first server which then + responds to the original client from port 53 to the original source + port number. + + The point of all this is that putting in filters to only allow UDP + between a high port and port 53 will not work correctly, you must also + allow the port 53 to port 53 UDP to get through. + + Also, ALL versions of BIND use TCP for queries in some cases. The + original query is tried using UDP. If the response is longer than + the allocated buffer, the resolver will retry the query using a TCP + connection. If you block access to TCP port 53 as suggested above, + you may find that some things don't work. + + Newer version of BIND allow you to configure a list of IP addresses + from which to allow zone transfers. This mechanism can be used to + prevent people from outside downloading your entire namespace. + + +------------------------------- + + +Date: Fri Apr 28 14:19:10 EDT 1995 +Subject: Q1.16 - Obtaining the latest cache file + +Q: What is the cache file and where can I obtain the latest version ? + +A: From the "Name Server Operations Guide" + + 6.3. Cache Initialization + + 6.3.1. root.cache + + The name server needs to know the servers that + are the authoritative name servers for the root + domain of the network. To do this we have to prime + the name server's cache with the addresses of these + higher authorities. The location of this file is + specified in the boot file. ... + + A copy of the comments in the file available from the InterNIC follow: + + ; This file holds the information on root name servers needed to + ; initialize cache of Internet domain name servers + ; (e.g. reference this file in the "cache . <file>" + ; configuration file of BIND domain name servers). + ; + ; This file is made available by InterNIC registration services + ; under anonymous FTP as + ; file /domain/named.root + ; on server FTP.RS.INTERNIC.NET + ; -OR- under Gopher at RS.INTERNIC.NET + ; under menu InterNIC Registration Services (NSI) + ; submenu InterNIC Registration Archives + ; file named.root + ; + ; last update: Oct 5, 1994 + ; related version of root zone: 1994100500 + ; + + If you have a version of dig running, you may obtain the information with + the command + + dig @ns.internic.net . ns + + +------------------------------- + + +Date: Mon Jan 2 13:13:49 EST 1995 +Subject: Q2.1 - Utilities to administer DNS zone files + +Q: I am wondering if there are utilities available to ease the + administration of the zone files in the DNS. + +A: There are a few. Two common ones are h2n and makezones. Both are perl + scripts. h2n is used to convert host tables into zone data files. It + is available for anonymous ftp from + + ftp://ftp.uu.net/published/oreilly/nutshell/dnsbind/dns.tar.Z. + + makezones works from a single file that looks like a forward zone file, + with some additional syntax for special cases. It is included in the + current BIND distribution. The newest version is always available for + anonymous ftp from + + ftp://ftp.cus.cam.ac.uk/pub/software/programs/DNS/makezones + + This package is mirrored at + + ftp://ftp.njit.edu/pub/dns/cus.cam.ac/makezones + + More information may be found using the DNS Resource Directory + + http://www.dns.net/dnsrd + + +------------------------------- + +Date: Thu Dec 1 11:09:11 EST 1994 +Subject: Q2.2 - DIG - Domain Internet Groper + +Q: Where can I find the latest version of DIG ? + +A: The latest and greatest, official, accept-no-substitutes version of DiG + is the one that comes with BIND. Get the latest kit. + +------------------------------- + +Date: Mon May 15 12:57:42 EDT 1995 +Subject: Q2.3 -DNS packet analyser + +Q: I'm looking for a Ethernet packet analyser of public domain or standard + (like tcpdump, snoop, packetman) that is able to determine DNS data + field protocol + +A: There is a free ethernet analyser called Ethload available for PC's + running DOS. The latest filename is ETHLD104.ZIP. It understands lots + of protocols including TCP/UDP. It'll look inside there and display + DNS/BOOTP/ICMP packets etc. (Ed. note: something nice for someone to + add to tcpdump ;^) ). Depending on the ethernet controller it's given + it'll perform slightly differently. It handles NDIS/Novell/Packet + drivers. It works best with Novell's promiscuous mode drivers. + A A SimTel mirror site should have the program available for anonymous + ftp. As an example, + + ftp://oak.oakland.edu/SimTel/msdos/lan/ethld104.zip + + +------------------------------- + +Date: Sun Dec 4 21:15:38 EST 1994 +Subject: Q2.4 - host + +A section from the host man page: + + host looks for information about Internet hosts and domain + names. It gets this information from a set of intercon- + nected servers that are spread across the world. The infor- + mation is stored in the form of "resource records" belonging + to hierarchically organized "zones". + + By default, the program simply converts between host names + and Internet addresses. However, with the -t, -a and -v + options, it can be used to find all of the information about + domain names that is maintained by the domain nameserver + system. The information printed consists of various fields + of the associated resource records that were retrieved. + + The arguments can be either host names (domain names) or + numeric Internet addresses. + +'host' is compatible with both BIND 4.9 and BIND 4.8 + +'host' may be found in contrib/host in the BIND distribution. The latest +version always available for anonymous ftp from + + ftp://ftp.nikhef.nl/pub/network/host.tar.Z + +It may also be found for anonymous ftp from + + ftp://ftp.uu.net/networking/ip/dns/host.tar.Z + +------------------------------- + +Date: Fri Feb 10 15:25:11 EST 1995 +Subject: Q2.5 - Programming with DNS + +Q: How can I use DNS information in my program? + +A: It depends on precisely what you want to do: + + a) Consider whether you need to write a program at all. It may well + be easier to write a shell program (e.g. using awk or perl) to parse + the output of dig, host or nslookup. + + b) If all you need is names and addresses, there will probably be + system routines 'gethostbyname' and 'gethostbyaddr' to provide this + information. + + c) If you need more details, then there are system routines (res_query + and res_search) to assist with making and sending DNS queries. + However, these do not include a routine to parse the resulting answer + (although routines to assist in this task are provided). There is a + separate library available that will take a DNS response and unpick + it into its constituent parts, returning a C structure that can be + used by the program. The source for this library is available for + anonymous ftp from + + ftp://hpux.csc.liv.ac.uk/hpux/Networking/Admin/resparse-* + + +------------------------------- + + +Date: Wed May 3 12:46:50 EDT 1995 +Subject: Q2.6 - A source of information relating to DNS + +Q: Where can I find utilities and tools to help me manage my zone files ? + +A: There are several tools available. Please refer to the "tools" section + of the DNS resources directory: + + http://www.dns.net/dnsrd/tools.html + + +------------------------------- + + +Date: Fri May 12 14:33:40 EDT 1995 +Subject: Q3.1 - TCP/IP Host Naming Conventions + +Q: Is a guide available relating to naming systems ? + +A: One guide/resource is RFC 1178, "Choosing a Name for Your Computer", + which is available via anonymous FTP from + + ftp://ftp.internic.netrfc/rfc1178.txt + + RFCs (Request For Comments) are specifications and guidelines for how + many aspects of TCP/IP and the Internet (should) work. Most RFCs are + fairly technical documents, and some have semantics that are hotly + contested in the newsgroups. But a few, like RFC 1178, are actually + good to read for someone who's just starting along a TCP/IP path. + + +------------------------------- + +Date: Thu Dec 1 10:32:43 EST 1994 +Subject: Q3.2 - What are slaves and forwarders ? + +Q: What are slaves and forwarders ? + +A: "forwarders" is a list of NS records that are _prepended_ to a list + of NS records to query if the data is not available locally. This + allows a rich cache of records to be built up at a centralized + location. This is good for sites that have sporadic or very slow + connections to the Internet. (demand dial-up, for example) It's + also just a good idea for very large distributed sites to increase + the chance that you don't have to go off to the Internet to get an + IP address. (sometimes for addresses across the street!) + + "slave" modifies this to say to replace the list of NS records + with the forwarders entry, instead of prepending to it. This is + for firewalled environments, where the nameserver can't directly + get out to the Internet at all. + + "slave" is meaningless (and invalid, in late-model BINDs) without + "forwarders". "forwarders" is an entry in named.boot, and therefore + applies only to the nameserver (not to resolvers). + +------------------------------- + +Date: Mon Jan 2 13:15:13 EST 1995 +Subject: Q3.3 - When is a server authoritative? + + +Q: What criteria does a server use to determine if it is authoritative + for a domain? + +A: In the case of BIND: + 1) The server contains current data in files for the zone in + question (Data must be current for secondaries, as defined + in the SOA) + 2) The server is told that it is authoritative for the zone, by + a 'primary' or 'secondary' keyword in /etc/named.boot. + 3) The server does an error-free load of the zone. + +Q: I have set up a DNS where there is an SOA record for + the domain, but the server still does not consider itself + authoritative. (I used nslookup and set server=the correct machine.) + It seems to me that something is not matching up somewhere. I suspect + that this is because the service provider has not given us control + over the IP numbers in our own domain, and so while the machine listed + has an A record for an address, there is no corresponding PTR record. + +A: That's possible too, but is unrelated to the first question. + You need to be delegated a zone before outside people will start + talking to your server. However, a server can still be authoritative + for a zone even though it hasn't been delegated authority (it's just + that only the people who use that as their server will see the data). + + A server may consider itself non-authoritative even though it's a + primary if there is a syntax error in the zone (see point 3 above). + +Q: I always believe that it was the NS record that defined authoritative + servers. + +A: Nope, delegation is a separate issue from authoritativeness. + You can still be authoritative, but not delegated. (you can also be + delegated, but not authoritative -- that's a "lame delegation") + +Q: We have had problems in the past from servers that were + authoritative (primary or secondary) but no NS, so other thought they + were not. Some resolvers get very confused when they get non- + authoritative data from the primary server. + +A: Yes, that's a lame delegation. That's not caused by what you said, + but rather by a server which is _not_ authoritative for a zone, yet + someone else (the parent) is saying that a server is authoritative + (via the NS records). + + The set of NS records in the parent zone must be a subset of the + authoritative servers to avoid lame delegations. + + +------------------------------- + +Date: Fri Apr 28 13:26:37 EDT 1995 +Subject: Q3.4 - underscore in host-/domainnames + + +Q: I had a quick look on whether underscores are allowed in host- or + domainnames. + + RFC 1033 allows them. + RFC 1035 doesn't. + RFC 1123 doesn't. + dnswalk complains about them. + + Which RFC is the final authority these days? + +A: Actually RFC 1035 deals with names of machines or names of + mail domains. i.e "_" is not permitted in a hostname or on the + RHS of the "@" in local@domain. + + Underscore is permitted where ever the domain is NOT one of + these types of addresses. + + In general the DNS mostly contains hostnames and mail domainnames. + This will change as new resource record types for authenticating DNS + queries start to appear. + + The latest version of 'host' checks for illegal characters in A/MX + record names and the NS/MX target names. + + After saying all of that, remember that RFC 1123 is a Required Internet + Standard (per RFC 1720), and RFC 1033 isn't. Even 1035 isn't a required + standard. Therefore, RFC 1123 wins, no contest. + + +------------------------------- + +Date: Fri Dec 2 15:03:56 EST 1994 +Subject: Q3.5 - Lame delegation + +Q: What is lame delegation ? + +A: Two things are required for a lame delegation: + 1) A nameserver X is delegated as authoritative for a zone. + 2) Nameserver X is not performing nameservice for that zone. + + Try to think of a lame delegation as a long-term condition, brought + about by a misconfiguration somewhere. Bryan Beecher's 1992 LISA + paper on lame delegations is good to read on this. The problem + really lies in misconfigured nameservers, not "lameness" brought + about by transient outages. The latter is common on the Internet + and hard to avoid, while the former is correctable. + + In order to be performing nameservice for a zone, it must have + (presumed correct) data for that zone, and it must be answering + authoritatively to resolver queries for that zone. (The AA bit is + set in the flags section) + + The "classic" lame delegation case is when nameserver X is delegated + as authoritative for domain Y, yet when you ask Y about X, it + returns non-authoritative data. + + Here's an example that shows what happens most often (using dig, + dnswalk, and doc to find). + + Let's say the domain bogus.com gets registered at the NIC and they + have listed 2 primary name servers, both from their *upstream* + provider: + + bogus.com IN NS ns.bogus.com + bogus.com IN NS upstream.com + bogus.com IN NS upstream1.com + + So the root servers have this info. But when the admins at + bogus.com actually set up their zone files they put something like: + + bogus.com IN NS upstream.com + bogus.com IN NS upstream1.com + + So your name server may have the nameserver info cached (which it + may have gotten from the root). The root says "go ask ns.bogus.com" + since they are authoritative + + This is usually from stuff being registered at the NIC (either + nic.ddn.mil or rs.internic.net), and then updated later, but the + folks who make the updates later never let the folks at the NIC know + about it. + +Q: How can I see if the server is "lame" ? + +A: Go to the authoritative servers one level up, and ask them who + they think is authoritative, and then go ask each one of those + delegees if they think that they themselves are authoritative. If any + responds "no", then you know who the lame delegation is, and who is + delegating lamely to them. You can then send off a message to the + administrators of the level above. + + The 'lamers' script from Byran Beecher really takes care of all this + for you. It parses the lame delegation notices from BIND's syslog + and summarizes them for you. It may be found in the contrib section + of the latest BIND distribution. The latest version is available + for anonymous ftp from + + ftp://terminator.cc.umich.edu/dns/lame-delegations/ + + If you want to actively check for lame delegations, you can use 'doc' + and 'dnswalk'. You can check things manually with 'dig'. + +------------------------------- + +Date: Thu Dec 1 11:10:39 EST 1994 +Subject: Q3.6 - What does opt-class field do? + +Q: Just something I was wondering about: What does the opt-class + field in an name database do (the one that always says IN)? + What would happen if I put something else there instead? + +A: This field is the address class. From the BOG - + + ...is the address class; currently, only one class + is supported: IN for internet addresses and other + internet information. Limited support is included for + the HS class, which is for MIT/Athena ``Hesiod'' + information. + +------------------------------- + +Date: Fri Feb 10 14:49:54 EST 1995 +Subject: Q3.7 - Top level domains + + +A section from RFC 1591: + + 2. The Top Level Structure of the Domain Names + + In the Domain Name System (DNS) naming of computers there is a + hierarchy of names. The root of system is unnamed. There are a set + of what are called "top-level domain names" (TLDs). These are the + generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two + letter country codes from ISO-3166. It is extremely unlikely that + any other TLDs will be created. + +[ Ed note: the ISO-3166 country codes may be found for anonymous ftp from: + + ftp://ftp.isi.edu/in-notes/iana/assignments/country-codes + ftp://ftp.ripe.net/iso3166-codes +] + + Under each TLD may be created a hierarchy of names. Generally, under + the generic TLDs the structure is very flat. That is, many + organizations are registered directly under the TLD, and any further + structure is up to the individual organizations. + + In the country TLDs, there is a wide variation in the structure, in + some countries the structure is very flat, in others there is + substantial structural organization. In some country domains the + second levels are generic categories (such as, AC, CO, GO, and RE), + in others they are based on political geography, and in still others, + organization names are listed directly under the country code. The + organization for the US country domain is described in RFC 1480. + + Each of the generic TLDs was created for a general category of + organizations. The country code domains (for example, FR, NL, KR, + US) are each organized by an administrator for that country. These + administrators may further delegate the management of portions of the + naming tree. These administrators are performing a public service on + behalf of the Internet community. Descriptions of the generic + domains and the US country domain follow. + + Of these generic domains, five are international in nature, and two + are restricted to use by entities in the United States. + + World Wide Generic Domains: + + COM - This domain is intended for commercial entities, that is + companies. This domain has grown very large and there is + concern about the administrative load and system performance if + the current growth pattern is continued. Consideration is + being taken to subdivide the COM domain and only allow future + commercial registrations in the subdomains. + + EDU - This domain was originally intended for all educational + institutions. Many Universities, colleges, schools, + educational service organizations, and educational consortia + have registered here. More recently a decision has been taken + to limit further registrations to 4 year colleges and + universities. Schools and 2-year colleges will be registered + in the country domains (see US Domain, especially K12 and CC, + below). + + NET - This domain is intended to hold only the computers of network + providers, that is the NIC and NOC computers, the + administrative computers, and the network node computers. The + customers of the network provider would have domain names of + their own (not in the NET TLD). + + ORG - This domain is intended as the miscellaneous TLD for + organizations that didn't fit anywhere else. Some non- + government organizations may fit here. + + INT - This domain is for organizations established by international + treaties, or international databases. + + United States Only Generic Domains: + + GOV - This domain was originally intended for any kind of government + office or agency. More recently a decision was taken to + register only agencies of the US Federal government in this + domain. State and local agencies are registered in the country + domains (see US Domain, below). + + MIL - This domain is used by the US military. + + Example country code Domain: + + US - As an example of a country domain, the US domain provides for + the registration of all kinds of entities in the United States + on the basis of political geography, that is, a hierarchy of + <entity-name>.<locality>.<state-code>.US. For example, + "IBM.Armonk.NY.US". In addition, branches of the US domain are + provided within each state for schools (K12), community + colleges (CC), technical schools (TEC), state government + agencies (STATE), councils of governments (COG),libraries + (LIB), museums (MUS), and several other generic types of + entities (see RFC 1480 for details). + + +A section from RFC 1480: + + 2. NAMING STRUCTURE + + The US Domain hierarchy is based on political geography. The + basic name space under US is the state name space, then the + "locality" name space, (like a city, or county) then + organization or computer name and so on. + + For example: + + BERKELEY.CA.US + PORTLAND.WA.US + + There is of course no problem with running out of names. + + The things that are named are individual computers. + + If you register now in one city and then move, the database can + be updated with a new name in your new city, and a pointer can + be set up from your old name to your new name. This type of + pointer is called a CNAME record. + + The use of unregistered names is not effective and causes problems + for other users. Inventing your own name and using it without + registering is not a good idea. + + In addition to strictly geographically names, some special names + are used, such as FED, STATE, AGENCY, DISTRICT, K12, LIB, CC, + CITY, and COUNTY. Several new name spaces have been created, + DNI, GEN, and TEC, and a minor change under the "locality" name + space was made to the existing CITY and COUNTY subdomains by + abbreviating them to CI and CO. A detailed description + follows. + + Below US, Parallel to States: + ----------------------------- + + "FED" - This branch may be used for agencies of the federal + government. For example: <org-name>.<city>.FED.US + + "DNI" - DISTRIBUTED NATIONAL INSTITUTES - The "DNI" branch was + created directly under the top-level US. This branch is to be used + for distributed national institutes; organizations that span state, + regional, and other organizational boundaries; that are national in + scope, and have distributed facilities. For example: + <org-name>.DNI.US. + + Name Space Within States: + ------------------------ + + "locality" - cities, counties, parishes, and townships. Subdomains + under the "locality" would be like CI.<city>.<state>.US, + CO.<county>.<state>.US, or businesses. For example: + Petville.Marvista.CA.US. + + "CI" - This branch is used for city government agencies and is a + subdomain under the "locality" name (like Los Angeles). For example: + Fire-Dept.CI.Los-Angeles.CA.US. + + "CO" - This branch is used for county government agencies and is a + subdomain under the "locality" name (like Los Angeles). For example: + Fire-Dept.CO.San-Diego.CA.US. + + "K12" - This branch may be used for public school districts. A + special name "PVT" can be used in the place of a school district name + for private schools. For example: <school-name>.K12.<state>.US and + <school-name>.PVT.K12.<state>.US. + + "CC" - COMMUNITY COLLEGES - This branch was established for all state + wide community colleges. For example: <school-name>.CC.<state>.US. + + "TEC" - TECHNICAL AND VOCATIONAL SCHOOLS - The branch "TEC" was + established for technical and vocational schools and colleges. For + example: <school-name>.TEC.<state>.US. + + "LIB" - LIBRARIES (STATE, REGIONAL, CITY, COUNTY) - This branch may + be used for libraries only. For example: <lib-name>.LIB.<state>.US. + + "STATE" - This branch may be used for state government agencies. For + example: <org-name>.STATE.<state>.US. + + "GEN" - GENERAL INDEPENDENT ENTITY - This branch is for the things + that don't fit easily into any other structure listed -- things that + might fit in to something like ORG at the top-level. It is best not + to use the same keywords (ORG, EDU, COM, etc.) that are used at the + top-level to avoid confusion. GEN would be used for such things as, + state-wide organizations, clubs, or domain parks. For example: + <org-name>.GEN.<state-code>.US. + + The application form for the US domain may be found for anonymous ftp + from: + + ftp://internic.net/templates/us-domain-template.txt + + The application form for the EDU, COM, NET, ORG, and GOV domains may be + found for anonymous ftp from: + + ftp://internic.net/templates/domain-template.txt + + +------------------------------- + +Date: Sun Nov 27 23:32:41 EST 1994 +Subject: Q3.8 - Classes of networks + +Q: I am just kind of curious to what exactly the differences in classes + of networks are (class A, B, C). + +A: An Internet Protocol (IP) address is 32 bit in length, divided into + two or three parts (the network address, the subnet address (if present), + and the host address. The subnet addresses are only present if the + network has been divided into subnetworks. The length of the network, + subnet, and host field are all variable. + + There are five different network classes. The leftmost bits indicate + the class of the network. + + # bits in # bits in + network host +Class field field Internet Protocol address in binary Ranges +============================================================================ + A 7 24 0NNNNNNN.HHHHHHHH.HHHHHHHH.HHHHHHHH 1-127.x.x.x + B 14 16 10NNNNNN.NNNNNNNN.HHHHHHHH.HHHHHHHH 128-191.x.x.x + C 22 8 110NNNNN.NNNNNNNN.NNNNNNNN.HHHHHHHH 192-223.x.x.x + D NOTE 1 1110xxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx 224-239.x.x.x + E NOTE 2 11110xxx.xxxxxxxx.xxxxxxxx.xxxxxxxx 240-247.x.x.x + + where N represents part of the network address and H represents part of + the host address. When the subnet address is defined, the needed bits + are assigned from the host address space. + + NOTE 1: Reserved for multicast groups - RFC 1112 + NOTE 2: Reserved for future use + + 127.0.0.1 is reserved for local loopback. + + Under the current arrangements, many class A IP numbers will not be + assigned whereas class C usage will be at a premium. + +------------------------------- + + +Date: Fri Apr 28 13:31:24 EDT 1995 +Subject: Q3.9 - What is CIDR ? + +Q: What is CIDR ? + +A: CIDR is "Classless Inter-Domain Routing (CIDR). From RFC1517: + + ...Classless Inter-Domain Routing (CIDR) attempts to deal with + these problems by defining a mechanism to slow the growth of + routing tables and reduce the need to allocate new IP network + numbers. + + Much more information may be obtained in RFCs 1467, 1517, 1518, 1520; + with primary reference 1519 + + +------------------------------- + + +Date: Fri Apr 28 13:31:24 EDT 1995 +Subject: Q3.10 - What is the rule for glue ? + +Q: What is the rule for glue ? + +A: A glue record is an A record for a name that appears on the right-hand + side of a NS record. So, if you have this: + + sub.foobar.com. IN NS dns.sub.foobar.com. + dns.sub.foobar.com. IN A 1.2.3.4 + + then the second record is a glue record (for the NS record above it). + + You need glue records when -- and only when -- you are delegating + authority to a nameserver that "lives" in the domain you are delegating + *and* you aren't a secondary server for that domain. + + In other words, in the example above, you need to add an A record + for dns.sub.foobar.com since it "lives" in the domain it serves. + This boot strapping information is necessary: How are you supposed + to find out the IP address of the nameserver for domain FOO if the + nameserver for FOO "lives" in FOO? + + If you have this NS record: + + sub.foobar.com. IN NS dns.xyz123.com. + + you do NOT need a glue record, and, in fact, adding one is a very + bad idea. If you add one, and then the folks at xyz123.com change + the address, then you will be passing out incorrect data. + + Also, unless you actually have a machine called something.IN-ADDR.ARPA, + you will never have any glue records present in any of your "reverse" + files. + + There is also a sort of implicit glue record that can be useful (or + confusing :^) ). If the parent server (abc.foobar.com domain in example + above) is a secondary server for the child, then the A record will be + fetched from the child server when the zone transfer is done. The glue + is still there but it's a little different, it's in the ip address in + the named.boot line instead of explicitly in the data. In this case + you can leave out the explicit glue A record and leave the manually + configured "glue" in just the one place in the named.boot file. + + RFC 1537 says it quite nicely: + + 2. Glue records + + Quite often, people put unnecessary glue (A) records in their + zone files. Even worse is that I've even seen *wrong* glue records + for an external host in a primary zone file! Glue records need only + be in a zone file if the server host is within the zone and there + is no A record for that host elsewhere in the zone file. + + Old BIND versions ("native" 4.8.3 and older versions) showed the + problem that wrong glue records could enter secondary servers in + a zone transfer. diff --git a/contrib/bind/doc/misc/FAQ.2of2 b/contrib/bind/doc/misc/FAQ.2of2 new file mode 100644 index 0000000..ae453c9 --- /dev/null +++ b/contrib/bind/doc/misc/FAQ.2of2 @@ -0,0 +1,1131 @@ +Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers +Path: vixie!news1.digital.com!uunet!in1.uu.net!usc!rutgers!njitgw.njit.edu!hertz.njit.edu!cdp2582 +From: cdp@njit.edu (Chris Peckham) +Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2) +Message-ID: <cptd-faq-2-810621452@njit.edu> +Followup-To: comp.protocols.tcp-ip.domains +Originator: cdp2582@hertz.njit.edu +Keywords: BIND,DOMAIN,DNS +Sender: news@njit.edu +Supersedes: <cptd-faq-2-807632375@njit.edu> +Nntp-Posting-Host: hertz.njit.edu +X-Posting-Frequency: posted on the 1st of each month +Reply-To: domain-faq@njit.edu (comp.protocols.tcp-ip.domains FAQ comments) +Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA +References: <cptd-faq-1-810621452@njit.edu> +Date: Sat, 9 Sep 1995 04:38:21 GMT +Approved: news-answers-request@MIT.EDU +Expires: Sat 14 Oct 95 00:37:32 EDT +Lines: 1110 +Xref: vixie comp.protocols.tcp-ip.domains:6019 comp.answers:13882 news.answers:49919 + +Posted-By: auto-faq 3.1.1.2 +Archive-name: internet/tcp-ip/domains-faq/part2 +Revision: 1.5 1995/05/12 18:50:41 + + +This FAQ is edited and maintained by Chris Peckham, <cdp@njit.edu>. +The latest version may always be found for anonymous ftp from + + ftp://rtfm.mit.edu/pub/usenet/news.answers/internet/tcp-ip/domains-faq + ftp://ftp.njit.edu/pub/dns/Comp.protocols.tcp-ip.domains.FAQ + +If you can contribute any answers for items in the TODO section, please do +so by sending e-mail to domain-faq@njit.edu ! If you know of any items that +are not included and you feel that they should be, send the relevant +information to domain-faq@njit.edu. + + +------------------------------ + +Date: Fri May 12 14:41:47 EDT 1995 +Subject: Table of Contents + +Table of Contents +================= +Part 1 +------ + 0. TO DO + 1. INTRODUCTION / MISCELLANEOUS + 1.1 What is this newsgroup ? + 1.2 More information + 1.3 What is BIND and where is the latest version of BIND ? + 1.4 How can I find the route between systems ? + 1.5 Finding the hostname if you have the tcp-ip address + 1.6 How to register a domain name + 1.7 Change of Domain name + 1.8 How memory and CPU does DNS use ? + 1.9 Other things to consider when planning your servers + 1.10 Proper way to get NS and reverse IP records into DNS + 1.11 How to get my address assign from NIC? + 1.12 Is there a block of private IP addresses I can use? + 1.13 Cache failed lookups + 1.14 What does an NS record really do ? + 1.15 DNS ports + 1.16 Obtaining the latest cache file + 2. UTILITIES + 2.1 Utilities to administer DNS zone files + 2.2 DIG - Domain Internet Groper + 2.3 DNS packet analyzer + 2.4 host + 2.5 Programming with DNS + 2.6 A source of information relating to DNS + 3. DEFINITIONS + 3.1 TCP/IP Host Naming Conventions + 3.2 Slaves and servers with forwarders + 3.3 When is a server authoritative? + 3.4 Underscore in host-/domain names + 3.5 Lame delegation + 3.6 What does opt-class field do? + 3.7 Top level domains + 3.8 Classes of networks + 3.9 What is CIDR ? + 3.10 What is the rule for glue ? + +Part 2 +------ + 4. CONFIGURATION + 4.1 Changing a Secondary server to a Primary + 4.2 How do I subnet a Class B Address ? + 4.3 Subnetted domain name service + 4.4 Recommended format/style of DNS files + 4.5 DNS on a system not connected to the Internet + 4.6 Multiple Domain configuration + 4.7 wildcard MX records + 4.8 How to identify a wildcard MX record + 4.9 Why are fully qualified domain names recommended ? + 4.10 Distributing load using named + 4.11 Order of returned records + 4.12 resolv.conf + 4.13 Delegating authority + 4.14 DNS instead of NIS on a Sun OS 4.1.x system + 5. PROBLEMS + 5.1 No address for root server + 5.2 Error - No Root Nameservers for Class XX + 5.3 Bind 4.9.x and MX querying? + 5.4 Some root nameservers don't know localhost + 5.5 MX records and CNAMES and separate A records for MX targets + 5.6 NS is a CNAME + 5.7 Nameserver forgets own A record + 5.8 General problems (core dumps !) + 5.9 malloc and DECstations + 6. ACKNOWLEDGEMENTS + +------------------------------ + +Date: Fri Dec 2 15:31:06 EST 1994 +Subject: Q4.1 - Changing a Secondary server to a Primary + +Q: Do I need to do anything special when I change a server from a secondary + to a primary ? + +A: For 4.8.3, it's prudent to kill and restart following any changes to + named.boot. + + In BIND 4.9.3, you only have to kill and restart named if you change + a primary zone to a secondary or v-v, or if you delete a zone and + remain authoritative for its parent. Every other case should be + taken care of by a HUP. (Ed. note: 4.9.3b9 may still require you to + kill and restart the server due to some bugs in the HUP code). + + You will also need to update the server information on the root servers. + You can do this by filing a new domain registration form to inform + InterNIC of the change. They will then update the root server's SOA + records. This process usually takes 10-12 business days after they + receive the request. + +------------------------------- + +Date: Fri Apr 28 13:34:52 EDT 1995 +Subject: Q4.2 - How do I subnet a Class B Address ? + +Q: I just received a Class B internet address and I am wondering where to + get an RFC or other information on how to properly to the TCP/IP + sub-netting. + +A: That you need to subnet at all is something of a misconception. You + can also think of a class B network as giving you 65,534 individual + hosts, and such a network will work. You can also configure your + class B as 16,384 networks of 2 hosts each. That's obviously not + very practical, but it needs to be made clear that you are not + constrained by the size of an octet (remember that many older + devices would not work in a network configured in this manner). + + So, the question is: why do you need to subnet? One reason is that + it is easier to manage a subnetted network, and in fact, you can + delegate the responsibility for address space management to local + administrators on the various subnets. Also, IP based problems will + end up localized rather than affecting your entire network. + + If your network is a large backbone with numerous segments + individually branching off the backbone, that too suggests + subnetting. + + Subnetting can also be used to improve routing conditions. + + You may wish to partition your network to disallow certain protocols + on certain segments of your net. You can, for example, restrict IP or + IPX to certain segments only by adding a router routing high level + protocols, and across the router you may have to subnet. + + Finally, as far as how many subnets you need depends on the answer to + the above question. As far as subnet masks are concerned, the mask + can be anything from 255.0.0.0 to 255.255.255.252. You'll probably be + looking at 9 or 10 bits for the subnet (last octet 128 or 192 + respectively). RFC1219 discusses the issue of subnetting very well + and leaves the network administrator with a large amount of flexibility + for future growth. + + +------------------------------ + +Date: Sun Nov 27 23:32:41 EST 1994 +Subject: Q4.3 -Subnetted domain name service + +Q: After doing some reading (DNS and BIND, Albitz&Liu), I don't really + find any examples of handling subnetted class C networks as separate + DNS domains. + +A: This is possible, just messy. You need to delegate down to the + fourth octet, so you will have one domain per IP address ! Here is + how you can subdelegate a in-addr.arpa address for non-byte aligned + subnet masks: + + Take as an example the net 192.1.1.x, and example subnet mask + 255.255.255.240. + + We first define the domain for the class C net, + +$origin 1.1.192.in-addr.arpa +@ SOA (usual stuff) +@ ns some.nameserver + ns some.other.nameserver +; delegate a subdomain +one ns one.nameserver + ns some.nameserver +; delegate another +two ns two.nameserver + ns some.nameserver +; CNAME pointers to subdomain one +0 CNAME 0.one +1 CNAME 1.one +; through +15 CNAME 15.one +; CNAME pointers to subdomain two +16 CNAME 16.two +17 CNAME 17.two +31 CNAME 31.two +; CNAME as many as required. + + + Now, in the delegated nameserver, one.nameserver + +$origin one.1.1.192.in-addr.arpa +@ SOA (usual stuff) + NS one.nameserver + NS some.nameserver ; secondary for us +0 PTR onenet.one.domain +1 PTR onehost.one.domain +; through +15 PTR lasthost.one.domain + + And similar for the two.1.1.192.in-addr.arpa delegated domain. + + +------------------------------ + +Date: Sun Nov 27 23:32:41 EST 1994 +Subject: Q4.4 - Recommended format/style of DNS files + +Q: Are there any suggestions for how to layout DNS configuration files + (both forward and reverse)? + +A: This answer is quoted from an article posted by Paul Vixie: + + I've gone back and forth on the question of whether the BOG should + include a section on this topic. I know what I myself prefer, but + I'm wary of ramming my own stylistic preferences down the throat of + every BOG reader. But since you ask :-)... + + Create /var/named. If your system is too old to have a /var, either + create one or use /usr/local/adm/named instead. Put your named.boot + in it, and make /etc/named.boot a symlink to it. If your system + doesn't have symlinks, you're S-O-L (but you knew that). In + named.boot, put a "directory" directive that specifies your actual + BIND working directory: + + directory /var/named + + All relative pathnames used in "primary", "secondary", and "cache" + directives will be evaluated relative to this directory. Create two + subdirectories, /var/named/pri and /var/named/sec. Whenever you add + a "primary" directive to your named.boot, use "pri/WHATEVER" as the + path name. And then put the primary zone file into "pri/WHATEVER". + Likewise when you add "secondary" directives, use "sec/WHATEVER" and + BIND (really named-xfer) will create the files in that + subdirectory. + + (Variations: (1) make a midlevel directory "zones" and put "pri" and + "sec" into it; (2) if you tend to pick up a lot of secondaries from + a few hosts, group them together in their own subdirectories -- + something like /var/named/zones/uucp if you're a UUCP Project name + server.) + + For your forward files, name them after the zone. dec.com becomes + "/var/named/zones/pri/dec.com". For your reverse files, name them + after the network number. 0.1.16.in-addr.arpa becomes + "/var/named/zones/pri/16.1.0". + + When creating or maintaining primary zone files, try to use the same + SOA values everywhere, except for the serial number which varies per + zone. Put a $ORIGIN directive at the top of the primary zone file, + not because its needed (it's not since the default origin is the + zone named in the "primary" directive) but because it make it easier + to remember what you're working on when you have a lot of primary + zones. Put some comments up there indicating contact information + for the real owner if you're proxying. Use RCS and put the "Id" + in a ";" comment near the top of the zone file. + + The SOA and other top level information should all be listed + together. But don't put IN on every line, it defaults nicely. For + example: + +============== +@ IN SOA gw.home.vix.com. postmaster.vix.com. ( + 1994082501 ; serial + 3600 ; refresh (1 hour) + 1800 ; retry (30 mins) + 604800 ; expire (7 days) + 3600 ) ; minimum (1 hour) + + NS gw.home.vix.com. + NS ns.uu.net. + NS uucp-gw-1.pa.dec.com. + NS uucp-gw-2.pa.dec.com. + + MX 10 gw.home.vix.com. + MX 20 uucp-gw-1.pa.dec.com. + MX 20 uucp-gw-1.pa.dec.com. +============== + + I don't necessarily recommend those SOA values. Not every zone is + as volatile as the example shown. I do recommend that serial number + format; it's in date format with a 2-digit per-day revision number. + This format will last us until 2147 A.D. at which point I expect a + better solution will have been found :-). (Note that it would last + until 4294 A.D. except that there are some old BINDs out there that + use a signed quantity for representing serial number interally; I + suppose that as long as none of these are still running after 2047 + A.D., that we can use the above serial number format until 4294 + A.D., at which point a better solution will HAVE to be found.) + + You'll note that I use a tab stop for "IN" even though I never again + specify it. This leaves room for names longer than 7 bytes without + messing up the columns. You might also note that I've put the MX + priority and destination in the same tab stop; this is because both + are part of the RRdata and both are very different from MX which is + an RRtype. Some folks seem to prefer to group "MX" and the priority + together in one tab stop. While this looks neat it's very confusing + to newcomers and for them it violates the law of least + astonishment. + + If you have a multi-level zone (one which contains names that have + dots in them), you can use additional $ORIGIN statements but I + recommend against it since there is no "back" operator. That is, + given the above example you can add: + +============= +$ORIGIN home +gw A 192.5.5.1 +============= + + The problem with this is that subsequent RR's had better be + somewhere under the "home.vix.com" name or else the $ORIGIN that + introduces them will have to use a fully qualified name. FQDN + $ORIGIN's aren't bad and I won't be mad if you use them. + Unqualified ones as shown above are real trouble. I usually stay + away from them and just put the whole name in: + +============= +gw.home A 192.5.5.1 +============= + + In your reverse zones, you're usually in some good luck because the + owner name is usually a single short token or sometimes two. + +============= +$ORIGIN 5.5.192.in-addr.arpa. +@ IN SOA ... + NS ... +1 PTR gw.home.vix.com. +========================================= +$ORIGIN 1.16.in-addr.arpa. +@ IN SOA ... + NS ... +2.0 PTR gatekeeper.dec.com. +============= + + It is usually pretty hard to keep your forward and reverse zones in + synch. You can avoid that whole problem by just using "h2n" (see + the ORA book, DNS and BIND, and its sample toolkit, included in the + BIND distribution or on ftp.uu.net (use the QUOTE SITE EXEC INDEX + command there to find this -- I never can remember where it's at). + "h2n" and many tools like it can just read your old /etc/hosts file + and churn it into DNS zone files. (May I recommend + contrib/decwrl/mkdb.pl from the BIND distribution?) However, if you + (like me) prefer to edit these things by hand, you need to follow + the simple convention of making all of your holes consistent. If + you use 192.5.5.1 and 192.5.5.3 but not (yet) 192.5.5.2, then in + your forward file you will have something like + +============= +... +gw.home A 192.5.5.1 +;avail A 192.5.5.2 +pc.home A 192.5.5.3 +============= + + and in your reverse file you will have something like + +============= +... +1 PTR gw.home.vix.com. +;2 PTR avail +3 PTR pc.home.vix.com. +============= + + This convention will allow you to keep your sanity and make fewer + errors. Any kind of automation (h2n, mkdb, or your own + perl/tcl/awk/python tools) will help you maintain a consistent + universe even if it's also a complex one. Editing by hand doesn't + have to be deadly but you MUST take care. + +------------------------------ + +Date: Sun Nov 27 23:32:41 EST 1994 +Subject: Q4.5 - DNS on a system not connected to the Internet + + +Q: How do I use DNS on a system that is not connected to the Internet or + set BIND up with an internal root server ? + +A: You need to create your own root domain name server until you connect + to the internet. Your roots need to delegate to mydomain.com and any + in-addr.arpa subdomains you might have, and that's about it. As + soon as you're connected, rip out the fake roots and use the real + ones. + + It does not actually have to be another server pretending to be the root. + You can set up the name server so that it is primary for each domain + above you and leave them empty (i.e. you are foo.bar.com - claim to be + primary for bar.com and com) + +Q: What if you connect intermittently and want DNS to work when you are + connected, and "fail" when you are not ? + +A: You can point the resolver at the name server at the remote site and + if the connection (SLIP/PPP) isn't up, the resolver doesn't have a + route to the remote server and since there's only one name server in + resolv.conf, the resolver quickly backs off the using /etc/hosts. + No problem. You could do the same with multiple name server and a + resolver that did configurable /etc/hosts fallback. + +------------------------------ + +Date: Fri Dec 2 15:40:49 EST 1994 +Subject: Q4.6 -Multiple Domain configuration + + +Q: I have seen sites that seem to have multiple domain names pointing to the + same destination. I would like to implement this and have found no + information explaining how to do it. What I would like to do is: + + ftp ftp.biff.com connects user to -> ftp.biff.com + ftp ftp.fred.com connects user to -> ftp.biff.com + ftp ftp.bowser.com connects user to -> ftp.biff.com + +A: This is done through CNAME records: + + ftp.bowser.com. IN CNAME ftp.biff.com. + + You can also do the same thing with multiple A records. + + +------------------------------ + +Date: Sun Nov 27 23:32:41 EST 1994 +Subject: Q4.7 - wildcard MX records + +Q: Does BIND not understand wildcard MX records such as the following? + + *.foo.com MX 0 mail.foo.com. + +A: Explicit RR's at one level of specificity will, by design, "block" a + wildcard at a lesser level of specificity. I suspect that you have + an RR (an A RR, perhaps?) for "bar.foo.com" which is blocking the + application of your "*.foo.com" wildcard. The initial MX query is + thus failing (NOERROR but an answer count of 0), and the backup + query finds the A RR for "bar.foo.com" and uses it to deliver the + mail directly (which is what you DIDN'T want it to do). Adding an + explicit MX RR for the host is therefore the right way to handle + this situation. + + See RFC 1034, Section 4.3.3 ("Wildcards") for more information on + this "blocking" behavior, along with an illustrative example. See + also RFC 974 for an explanation of standard mailer behavior in the + face of an "empty" response to one's MX query. + + Basically, what it boils down to is, there is no point in trying to + use a wildcard MX for a host which is otherwise listed in the DNS. + It just doesn't work. + +------------------------------ + +Date: Thu Dec 1 11:10:39 EST 1994 +Subject: Q4.8 - How to identify a wildcard MX record + + +Q: How do you identify a wildcard MX record ? + +A: You don't really need to "identify" a wildcard MX RR. The precedence + for u@dom is: + + exact match MX + exact match A + wildcard MX + + One way to implement this is to query for ("dom",IN,MX) and if the + answer name that comes back is "*." something, you know it's a + wildcard, therefore you know there is no exact match MX, and you + therefore query for ("dom",IN,A) and if you get something, use it. + if you don't, use the previous wildcard response. + + RFC 974 explains this pretty well. + +------------------------------ + +Date: Sun Nov 27 23:32:41 EST 1994 +Subject: Q4.9 - Why are fully qualified domain names recommended ? + + +Q: Why are fully qualified domain names recommended ? + +A: The documentation for BIND 4.9.2 says that the hostname should be set + to the full domain style name (i.e host.our.domain rather than + host). What advantages are there in this, and are there any adverse + consequences if we don't? + +A: Paul Vixie likes to do it :-) He lists a few reasons - + + * Sendmail can be configured to just use Dj$w rather than + Dj$w.mumble where "mumble" is something you have to edit in by + hand. Granted, most people use "mumble" elsewhere in their config + files ("tack on local domain", etc) but why should it be a + requirement ? + + * The real reason is that not doing it violates a very useful invariant: + + gethostbyname(gethostname) == gethostbyaddr(primary_interface_address) + + If you take an address and go "backwards" through the PTR's with + it, you'll get a FQDN, and if you push that back through the A + RR's, you get the same address. Or you should. Many multi-homed + hosts violate this uncaringly. + + If you take a non-FQDN hostname and push it "forwards" through the + A RR's, you get an address which, if you push it through the + PTR's, comes back as a FQDN which is not the same as the hostname + you started with. Consider the fact that, absent NIS/YP, there is + no "domainname" command analogous to the "hostname" command. + (NIS/YP's doesn't count, of course, since it's + sometimes-but-only-rarely the same as the Internet domain or + subdomain above a given host's name.) The "domain" keyword in + resolv.conf doesn't specify the parent domain of the current host; + it specifies the default domain of queries initiated on the + current host, which can be a very different thing. (As of RFC + 1535 and BIND 4.9.2's compliance with it, most people use "search" + in resolv.conf, which overrides "domain", anyway.) + + What this means is that there is NO authoritative way to + programmatically discover your host's FQDN unless it is set in the + hostname, or unless every application is willing to grovel the + "netstat -in" tables, find what it hopes is the primary address, + and do a PTR query on it. + + FQDN /bin/hostnames are, intuitively or not, the simplest way to go. + +------------------------------ + +Date: Wed Mar 1 11:04:43 EST 1995 +Subject: Q4.10 - Distributing load using named + +Q: If you attempt to distribute the load on a system using named, won't + the first response be cached, and then later queries use the cached + value? (This would be for requests that come through the same + server.) + +A: Yes. So it can be useful to use a lower TTL on records where this is + important. You can use values like 300 or 500 seconds. + + If your local caching server has ROUND_ROBIN, it does not matter + what the authoritative servers have -- every response from the cache + is rotated. + + But if it doesn't, and the authoritative server site is depending on + this feature (or the old "shuffle-A") to do load balancing, then if + one doesn't use small TTLs, one could conceivably end up with a + really nasty situation, e.g., hundreds of workstations at a branch + campus pounding on the same front end at the authoritative server's + site during class registration. + + Not nice. + +A: Paul Vixie has an example of the ROUND_ROBIN code in action. Here is + something that he wrote regarding his example: + + >I want users to be distributed evenly among those 3 hosts. + + Believe it or not :-), BIND offers an ugly way to do this. I offer + for your collective amusement the following snippet from the + ugly.vix.com zone file: + + hydra cname hydra1 + cname hydra2 + cname hydra3 + hydra1 a 10.1.0.1 + a 10.1.0.2 + a 10.1.0.3 + hydra2 a 10.2.0.1 + a 10.2.0.2 + a 10.2.0.3 + hydra3 a 10.3.0.1 + a 10.3.0.2 + a 10.3.0.3 + + Note that having multiple CNAME RR's at a given name is + meaningless according to the DNS RFCs but BIND doesn't mind (in + fact it doesn't even complain). If you call + gethostbyname("hydra.ugly.vix.com") (try it!) you will get + results like the following. Note that there are two round robin + rotations going on: one at ("hydra",CNAME) and one at each + ("hydra1",A) et al. I used a layer of CNAME's above the layer of + A's to keep the response size down. If you don't have nine + addresses you probably don't care and would just use a pile of + CNAME's pointing directly at real host names. + + {hydra.ugly.vix.com} + name: hydra2.ugly.vix.com + aliases: hydra.ugly.vix.com + addresses: 10.2.0.2 10.2.0.3 10.2.0.1 + + {hydra.ugly.vix.com} + name: hydra3.ugly.vix.com + aliases: hydra.ugly.vix.com + addresses: 10.3.0.2 10.3.0.3 10.3.0.1 + + {hydra.ugly.vix.com} + name: hydra1.ugly.vix.com + aliases: hydra.ugly.vix.com + addresses: 10.1.0.2 10.1.0.3 10.1.0.1 + + {hydra.ugly.vix.com} + name: hydra2.ugly.vix.com + aliases: hydra.ugly.vix.com + addresses: 10.2.0.3 10.2.0.1 10.2.0.2 + + {hydra.ugly.vix.com} + name: hydra3.ugly.vix.com + aliases: hydra.ugly.vix.com + addresses: 10.3.0.3 10.3.0.1 10.3.0.2 + + +------------------------------ + +Date: Sun Dec 4 22:12:32 EST 1994 +Subject: Q4.11 - Order of returned records + +Q: Is there any way to tell named to return records, specifically + address records, in the order in which they are listed in the + database? + + It would appear that named consistently applies a sorting algorithm + to address records which seems to be virtually guaranteed to be + pessimal for our routers, which have many A records. + +A: Sorting, is the *resolver's* responsibility. RFC 1123: + + 6.1.3.4 Multihomed Hosts + + When the host name-to-address function encounters a host + with multiple addresses, it SHOULD rank or sort the + addresses using knowledge of the immediately connected + network number(s) and any other applicable performance or + history information. + + DISCUSSION: + The different addresses of a multihomed host generally + imply different Internet paths, and some paths may be + preferable to others in performance, reliability, or + administrative restrictions. There is no general way + for the domain system to determine the best path. A + recommended approach is to base this decision on local + configuration information set by the system + administrator. + + In BIND 4.9.x's resolver code, the "sortlist" directive in resolv.conf + can be used to configure this. + +------------------------------ + +Date: Fri Feb 10 15:46:17 EST 1995 +Subject: Q4.12 - resolv.conf + + +Q: Why should I use "real" IP addresses in /etc/resolv.conf and not 0.0.0.0 + or 127.0.0.1. + +A: Paul Vixie writes on the issue of the contents of resolv.conf: + + It's historical. Some kernels can't unbind a UDP socket's source + address, and some resolver versions (notably not including BIND + 4.9.2 or 4.9.3's) try to do this. The result can be wide area + network traffic with 127.0.0.1 as the source address. Rather than + giving out a long and detailed map of version/vendor combinations of + kernels/BINDs that have/don't this problem, I just tell folks not to + use 127.0.0.1 at all. + + 0.0.0.0 is just an alias for the first interface address assigned + after a system boot, and if that interface is a up-and-down point to + point link (PPP, SLIP, whatever), there's no guarantee that you'll + be able to reach yourself via 0.0.0.0 during the entire lifetime of + any system instance. On most kernels you can finesse this by adding + static routes to 127.0.0.1 for each of your interface addresses, but + some kernels don't like that trick and rather than give a detailed + map of which ones work and which ones don't, I just globally + recommend against 0.0.0.0. + + If you know enough to know that 127.0.0.1 or 0.0.0.0 is safe on your + kernel and resolver, then feel free to use them. If you don't know + for sure that it is safe, don't use them. I never use them (except + on my laptop, whose hostname is "localhost" and whose 0.0.0.0 is + 127.0.0.1 since I ifconfig my lo0 before any other interface). The + operational advantage to using a real IP address rather than an + wormhole like 0.0.0.0 or 127.0.0.1, is that you can then "rdist" or + otherwise share identical copies of your resolv.conf on all the + systems on any given subnet, not all of which will be servers. + +A: The problem was with older versions of the resolver (4.8.X). If you + listed 127.0.0.1 as the first entry in resolv.conf, and for whatever + reason the local name server wasn't running and the resolver fell + back to the second name server listed, it would send queries to the + name server with the source IP address set to 127.0.0.1 (as it was + set when the resolver was trying to send to 127.0.0.1--you use the + loopback address to send to the loopback address). + +------------------------------ + +Date: Mon Jan 2 13:50:13 EST 1995 +Subject: Q4.13 - Delegating authority + +Q: How do I delegate authority for domains within my domain ? + +A: When you start having a very big domain that can be broken into logical + and separate entities that can look after their own DNS information, + you will probably want to do this. Maintain a central area for the + things that everyone needs to see and delegate the authority for the + other parts of the organization so that they can manage themselves. + + Another essential piece of information is that every domain that + exists must have it NS records associated with it. These NS records + denote the name servers that are queried for information about that + zone. For your zone to be recognized by the outside world, the + server responsible for the zone above you must have created a NS + record for your machine in your domain. For example, putting the + computer club onto the network and giving them control over their + own part of the domain space we have the following. + + The machine authorative for gu.uwa.edu.au is mackerel and the machine + authorative for ucc.gu.uwa.edu.au is marlin. + + in mackerel's data for gu.uwa.edu.au we have the following + + @ IN SOA ... + IN A 130.95.100.3 + IN MX mackerel.gu.uwa.edu.au. + IN MX uniwa.uwa.edu.au. + + marlin IN A 130.95.100.4 + + ucc IN NS marlin.gu.uwa.edu.au. + IN NS mackerel.gu.uwa.edu.au. + + Marlin is also given an IP in our domain as a convenience. If they + blow up their name serving there is less that can go wrong because + people can still see that machine which is a start. You could place + "marlin.ucc" in the first column and leave the machine totally + inside the ucc domain as well. + + The second NS line is because mackerel will be acting as secondary name + server for the ucc.gu domain. Do not include this line if you are not + authorative for the information included in the sub-domain. + + +------------------------------ + +Date: Wed Mar 1 11:45:00 EST 1995 +Subject: Q4.14 - DNS instead of NIS on a Sun OS 4.1.x system + +Q: I would appreciate any comments on whether running bind 4.9.x will + enable sendmail, ftp, telnet and other TCP/IP services to bypass + NIS and connect directly to named. + +A: How to do this is documented quite well in the comp.sys.sun.admin FAQ in + questions one and two. You can get them from: + + ftp://thor.ece.uc.edu/pub/sun-faq/FAQs/sun-faq.general + http://www.cis.ohio-state.edu/hypertext/faq/usenet/comp-sys-sun-faq + + as well as from rtfm.mit.edu in the usual place, etc. + + +------------------------------ + +Date: Mon Jan 2 13:49:43 EST 1995 +Subject: Q5.1 - No address for root server + + +Q: I've been getting the following messages lately from bind-4.9.2.. + ns_req: no address for root server + +We are behind a firewall and have the following for our named.cache file - + + ; list of servers + . 99999999 IN NS POBOX.FOOBAR.COM. + 99999999 IN NS FOOHOST.FOOBAR.COM. + foobar.com. 99999999 IN NS pobox.foobar.com. + +A: You can't do that. Your nameserver contacts POBOX.FOOBAR.COM, gets the + correct list of root servers from it, then tries again and fails + because of your firewall. + + You will need a 'forwarder' definition, to ensure that all requests + are forwarded to a host which can penetrate the firewall. And + it is unwise to put phony data into 'named.cache'. + +------------------------------ + +Date: Sun Nov 27 23:32:41 EST 1994 +Subject: Q5.2 - Error - No Root Nameservers for Class XX + +Q: I've received errors before about "No root nameservers for class XX" + but they've been because of network connectivity problems. + I believe that Class 1 is Internet Class data. + And I think I heard someone say that Class 4 is Hesiod?? + Does anyone know what the various Class numbers are? + +A: From RFC 1700: + + DOMAIN NAME SYSTEM PARAMETERS + The Internet Domain Naming System (DOMAIN) includes several + parameters. These are documented in [RFC1034] and [RFC1035]. The + CLASS parameter is listed here. The per CLASS parameters are + defined in separate RFCs as indicated. + + Domain System Parameters: + + Decimal Name References + -------- ---- ---------- + 0 Reserved [PM1] + 1 Internet (IN) [RFC1034,PM1] + 2 Unassigned [PM1] + 3 Chaos (CH) [PM1] + 4 Hesoid (HS) [PM1] + 5-65534 Unassigned [PM1] + 65535 Reserved [PM1] + +DNS information for RFC 1700 was taken from + + ftp://ftp.isi.edu/in-notes/iana/assignments/dns-parameters + + Hesiod is class 4, and there are no official root nameservers for class + 4, so you can safely declare yourself one if you like. You might want + to put up a packet filter so that no one outside your network is capable + of making Hesiod queries of your machines, if you define yourself to be + a root nameserver for class 4. + +------------------------------ + +Date: Sun Nov 27 23:32:41 EST 1994 +Subject: Q5.3 - Bind 4.9.x and MX querying? + + +Q: If I query a 4.9.x DNS server for MX records, a list of the MX records + as well as a list of the authorative nameservers is returned. Why ? + +A: Bind 4.9.2 returns the list of nameserver that are authorative + for a domain in the response packet, along with their IP + addresses in the additional section. + +------------------------------ + +Date: Sat Sep 9 00:36:01 EDT 1995 +Subject: Q5.4 - Some root nameservers don't know localhost + +Q: Do I need to define an A record for localhost ? + + Where is the A record for 127.0.0.1 defined? I see where + the PTR record is defined pointing to localhost, but can't find + where the A record is. And is the A record supposed to be + localhost.MY_DOMAIN or just localhost ? + +A: Somewhere deep in the BOG (BIND Operations Guide) that came with + 4.9.3 (section 5.4.3), it says that you define this yourself + (if need be) in the same zone files as your "real" IP addresses + for your domain. Quoting the BOG: + + ... As implied by this PTR + record, there should be a ``localhost.my.dom.ain'' + A record (with address 127.0.0.1) in every domain + that contains hosts. ``localhost.'' will lose its + trailing dot when 1.0.0.127.in-addr.arpa is queried + for;... + + The sample files in the BIND distribution show you what needs to be + done (see the BOG). + + Some HP boxen (especially those running HP OpenView) will also need + "loopback" defined with this IP address. You may set it as a CNAME + record pointing to the "localhost." record. + +------------------------------ + +Date: Sun Nov 27 23:32:41 EST 1994 +Subject: Q5.5 - MX records and CNAMES and separate A records for MX targets + +Q: The O'Reilly "DNS and Bind" book warns against using non-canonical + names in MX records, however, this warning is given in the context + of mail hubs that MX to each other for backup purposes. I don't see + how this applies to mail spokes. RFC 974 has a similar warning, but + I can not see where it specifically prohibits using an alias in an + MX record. + +A: Without the restrictions in the RFC, a MTA must request the A records + for every MX listed to determine if it is in the MX list then reduce + the list. This introduces many more lookups than would other wise be + required. If you are behind a 1200 bps link YOU DON'T WANT TO DO + THIS. The addresses associated with CNAMES are not passed as + additional data so you will force additional traffic to result even + if you are running a caching server locally. + + There is also the problem of how does the MTA find all of it's + IP addresses. This is not straight forward. You have to be able + to do this is you allow CNAMEs (or extra A's) as MX targets. + + The letter of the law is that an MX record should point to an A record. + + There is no "real" reason to use CNAMEs for MX targets or separate + As for nameservers any more. CNAMEs for services other than mail + should be used because there is no specified method for locating the + desired server yet. + + People don't care what the names of MX targets are. They're + invisible to the process anyway. If you have mail for "mary" + redirected to "sue" is totally irrelevant. Having CNAMEs as the + targets of MX's just needlessly complicates things, and is more work + for the resolver. + + Having separate A's for nameservers like "ns.your.domain" is + pointless too, since again nobody cares what the name of your + nameserver is, since that too is invisible to the process. If you + move your nameserver from "mary.your.domain" to "sue.your.domain" + nobody need care except you and your parent domain administrator + (and the InterNIC). Even less so for mail servers, since only you + are affected. + +Q: Given the example - + + hello in cname realname + mailx in mx 0 hello + + Now, while reading the operating manual of bind it clearly states + that this is *not* valid. These two statements clearly contradict + each other. Is there some later rfc than 974 that overrides what is + said in there with respect to MX and CNAMEs? Anyone have the + reference handy? + +A: This isn't what the BOG says at all. See below. You can have a CNAME + that points to some other RR type; in fact, all CNAMEs have to point + to other names (Canonical ones, hence the C in CNAME). What you + can't have is an MX that points to a CNAME. MX RR's that point to + names which have only CNAME RR's will not work in many cases, and + RFC 974 intimates that it's a bad idea: + + Note that the algorithm to delete irrelevant RRs breaks if LOCAL has + a alias and the alias is listed in the MX records for REMOTE. (E.g. + REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This + can be avoided if aliases are never used in the data section of MX + RRs. + + Here's the relevant BOG snippet: + + aliases {ttl} addr-class CNAME Canonical name + ucbmonet IN CNAME monet + + The Canonical Name resource record, CNAME, speci- + fies an alias or nickname for the official, or + canonical, host name. This record should be the + only one associated with the alias name. All other + resource records should be associated with the + canonical name, not with the nickname. Any + resource records that include a domain name as + their value (e.g., NS or MX) must list the canoni- + cal name, not the nickname. + +------------------------------ + +Date: Wed Mar 1 11:14:10 EST 1995 +Subject: Q5.6 - NS is a CNAME + +Q: Can I do this ? Is it legal ? + + @ SOA (.........) + NS ns.host.this.domain. + NS second.host.another.domain. + ns CNAME third + third IN A xxx.xxx.xxx.xxx + + +A: No. Only one RR type is allowed to refer, in its data field, to a + CNAME, and that's CNAME itself. So CNAMEs can refer to CNAMEs but + NSs and MXs cannot. + + BIND 4.9.3 (Beta11 and later) explicitly syslogs this case rather than + simply failing as pre-4.9 servers did. Here's a current example: + + Dec 7 00:52:18 gw named[17561]: \ + "foobar.com IN NS" points to a CNAME (foobar.foobar.com) + + Here is the reason why: + + Nameservers are not required to include CNAME records in the + Additional Info section returned after a query. It's partly an + implementation decision and partly a part of the spec. The + algorithm described in RFC 1034 (pp24,25; info also in RFC 1035, + section 3.3.11, p 18) says 'Put whatever addresses are available + into the additional section, using glue RRs [if necessary]'. + Since NS records are speced to contain only primary names of + hosts, not CNAMEs, then there's no reason for algorithm to + mention them. If, on the other hand, it's decided to allow CNAMEs + in NS records (and indeed in other records) then there's no + reason that CNAME records might not be included along with A + records. The Additional Info section is intended for any + information that might be useful but which isn't strictly the + answer to the DNS query processed. It's an implementation + decision in as much as some servers used to follow CNAMEs in + NS references. + + +------------------------------ + +Date: Fri Dec 2 16:17:31 EST 1994 +Subject: Q5.7 - Nameserver forgets own A record + + +Q: Lately, I've been having trouble with named 4.9.2 and 4.9.3. + Periodically, the nameserver will seem to "forget" its own A record, + although the other information stays intact. One theory I had was + that somehow a site that the nameserver was secondary for was + "corrupting" the A record somehow. + +A: This is invariably due to not removing ALL of the cached zones + when you moved to 4.9.X. Remove ALL cached zones and restart + your nameservers. + + You get "ignoreds" because the primaries for the relevant zones are + running old versions of BIND which pass out more glue than is + required. named-xfer trims off this extra glue. + +------------------------------ + +Date: Sun Dec 4 22:21:22 EST 1994 +Subject: Q5.8 - General problems (core dumps !) + +Q: I am running bind 4.9.3b9p1 on a DEC alpha OSF/1 V3.0 and have had it + core dump while in debug mode. The last lines printed to named.run + were [...] + +A: Paul Vixie says: + + I'm always interested in hearing about cases where BIND dumps core. + However, I need a stack trace. Compile with -g and not -O (unless + you are using gcc and know what you are doing) and then when it + dumps core, get into dbx or gdb using the executable and the core + file and use "bt" to get a stack trace. Send it to me + <paul@vix.com> along with specific circumstances leading to or + surrounding the crash (test data, tail of the debug log, tail of the + syslog... whatever matters) and ideally you should save your core + dump for a day or so in case I have questions you can answer via + gdb/dbx. + +------------------------------ + +Date: Mon Jan 2 14:19:22 EST 1995 +Subject: Q5.9 - malloc and DECstations + +We have replaced malloc on our DECstations with a malloc that is more +compact in memory usage, and this helped the operation of bind a lot. +The source is now available for anonymous ftp from + + ftp://ftp.cs.wisc.edu/pub/misc/malloc.tar.gz + + +------------------------------ + +Date: Fri Apr 28 13:56:32 EDT 1995 +Subject: Q6 - Acknowledgements + +Listed in e-mail address alphabetical order, the following people have +contributed to this FAQ: + +Benoit.Grange@inria.fr (Benoit.Grange) +D.T.Shield@csc.liv.ac.uk (Dave Shield) +adam@comptech.demon.co.uk (Adam Goodfellow) +andras@is.co.za (Andras Salamon) +barmar@nic.near.net (Barry Margolin) +barr@pop.psu.edu (David Barr) +bj@herbison.com (B.J. Herbison) +bje@cbr.fidonet.org (Ben Elliston) +brad@birch.ims.disa.mil (Brad Knowles) +ckd@kei.com (Christopher Davis) +cdp@hertz.njit.edu (Chris Peckham) +cricket@hp.com (Cricket Liu) +cudep@csv.warwick.ac.uk (Ian 'Vato' Dickinson [ID17]) +dparter@cs.wisc.edu (David Parter) +e07@nikhef.nl (Eric Wassenaar) +fwp@CC.MsState.Edu (Frank Peters) +gah@cco.caltech.edu (Glen A. Herrmannsfeldt) +glenn@popco.com (Glenn Fleishman) +harvey@indyvax.iupui.edu (James Harvey) +hubert@cac.washington.edu (Steve Hubert) +jmalcolm@uunet.uu.net (Joseph Malcolm) +jhawk@panix.com (John Hawkinson) +kevin@cfc.com (Kevin Darcy) +lamont@abstractsoft.com (Sean T. Lamont) +lavondes@tidtest.total.fr (Michel Lavondes) +mark@ucsalf.ac.uk (Mark Powell) +marka@syd.dms.CSIRO.AU (Mark Andrews) +mathias@unicorn.swi.com.sg (Mathias Koerber) +mjo@iao.ford.com (Mike O'Connor) +nick@flapjack.ieunet.ie (Nick Hilliard) +patrick@oes.amdahl.com (Patrick J. Horgan) +ph10@cus.cam.ac.uk (Philip Hazel) +rv@seins.Informatik.Uni-Dortmund.DE (Ruediger Volk) +shields@tembel.org (Michael Shields) +tanner@george.arc.nasa.gov (Rob Tanner) +vixie@vix.com (Paul A Vixie) +wag@swl.msd.ray.com (William Gianopoulos {84718}) +whg@inel.gov (Bill Gray) +wolf@pasteur.fr (Christophe Wolfhugel) + +Thank you ! + diff --git a/contrib/bind/doc/misc/IPv6 b/contrib/bind/doc/misc/IPv6 new file mode 100644 index 0000000..49fc3f5 --- /dev/null +++ b/contrib/bind/doc/misc/IPv6 @@ -0,0 +1,72 @@ +IPv6 notes for BIND 4.9.3 Patch 2 Candidate 5 (and later?) +Paul Vixie, May 20, 1996 +doc/misc/IPv6 + + *** Introduction *** + +The IPv6 support in this release is latent, in that its presence is not +documented. The support is not optional, since its presence ought not to +affect anyone who does not go looking for it. The support includes: + + inet_ntop() new function. + inet_pton() new function. + RES_USE_INET6 causes gethostby*() to return either real IPv6 + addresses (if available) or mapped (::FFFF:a.b.c.d) + addresses if only IPv4 address records are found. + gethostbyname() can search for T_AAAA in preference to T_A. + gethostbyaddr() can search in IP6.INT for PTR RR's. + named can load, transfer, cache, and dump T_AAAA RRs. + + *** Some notes on the new functions *** + +The inet_pton() and inet_ntop() functions differ from the current (as of +this writing) IPv6 BSD API draft. Discussions were held, primarily between +myself and Rich Stevens, on the ipng@sunroof.eng.sun.com mailing list, and +the BIND definitions of these functions are likely to go into the next draft. +(If not, and BIND has to change its definitions of these functions, then you +will know why I chose not to document them yet!) + +These functions can return error values, and as such the process of porting +code that used inet_aton() to use inet_pton() is not just syntactic. Not all +nonzero values indicate success; consider "-1". Likewise, inet_ntoa() is not +just smaller than inet_ntop() -- it's a whole new approach. Inet_ntop() does +not return a static pointer, the caller has to supply a sized buffer. Also, +inet_ntop() can return NULL, so you should only printf() the result if you +have verified that your arguments will be seen as error free. + +The inet_pton() function is much pickier about its input format than the old +inet_aton() function has been. You can't abbreviate 10.0.0.53 as 10.53 any +more. Hexadecimal isn't accepted. You have to supply four decimal numeric +strings, each of whose value is within the range from 0 to 255. No spaces +are allowed either before, after, or within an address. If you need the older +functionality with all the shortcuts and exceptions, continue using inet_aton() +for your IPv4 address parsing needs. + + *** Some notes on RES_USE_INET6 *** + +You can set this by modifying _res.options after calling res_init(), or you +can turn it on globally by setting "options inet6" in /etc/resolv.conf. This +latter option ought to be used carefully, since _all_ applications will then +receive IPv6 style h_addr_list's from their gethostby*() calls. Once you know +that every application on your system can cope with IPv6 addressing, it is safe +and reasonable to turn on the global option. Otherwise, don't do it. + + *** Some notes on mapped IPv4 addresses *** + +There are two IPv6 prefixes set aside for IPv4 address encapsulation. See +RFC 1884 for a detailed explaination. The ::a.b.c.d form is used for +tunnelling, which means wrapping an IPv4 header around IPv6 packets and using +the existing IPv4 routing infrastructure to reach what are actually IPv6 +endpoints. The ::FFFF:a.b.c.d form can be used on dual-stack (IPv4 and IPv6) +hosts to signal a predominantly IPv6 stack that it should use ``native'' IPv4 +to reach a given destination, even though the socket's address family is +AF_INET6. + +BIND supports both of these address forms, to the extent that inet_pton() will +parse them, inet_ntop() will generate them, gethostby*() will map IPv4 into +IPv6 if the RES_USE_INET6 option is set, and gethostbyaddr() will search the +IN-ADDR.ARPA domain rather than the IP6.INT domain when it needs a PTR RR. +This last bit of behaviour is still under discussion and it's not clear that +tunnelled addresses should be mapped using IN-ADDR.ARPA. In other words, this +bit of behaviour may change in a subsequent BIND release. So now you know +another reason why none of this stuff is ``officially'' documented. diff --git a/contrib/bind/doc/misc/dns-setup b/contrib/bind/doc/misc/dns-setup new file mode 100644 index 0000000..19f0197 --- /dev/null +++ b/contrib/bind/doc/misc/dns-setup @@ -0,0 +1,1081 @@ + Setting up a basic DNS server for a domain + Revision 1.1.1 + + Craig Richmond + craig@ecel.uwa.edu.au + 15th August 1993 + + +About this document + +I have written this file because it seems that the same questions seem to +pop up time and time again and when I had to install DNS from scratch the +first time, we found very little to help us. + +This document covers setting up a Domain Name Server with authority over +your domain and using a few of the more useful but less well known +(hopefully this document will take care of that) features of nslookup to +get information about the DNS and to work out why yours isn't working. + +If you are using a Sun Workstation and you want to make NIS interact with +the DNS, then this is not the FAQ for you (but it may well be when you try +to set up the DNS). Mark J. McIntosh <Mark.McIntosh@engr.UVic.CA> points +out that it is included in the comp.sys.sun.admin FAQ and for the benefit +of those of you who can't get that (it is posted in comp.sys.sun.admin, +comp.sys.sun.misc, comp.unix.solaris, comp.answers and news.answers) I have +included the relevant parts at the bottom in appendix C. + +Contents: + + Contents + An Overview of the DNS + Installing the DNS + *The Boot File + *The Cache File + *The Forward Mapping File + *The Reverse Mapping File + Delegating authority for domains within your domain + Troubleshooting your named + *Named doesn't work! What is wrong? + *I changed my named database and my local machine has noticed, + but nobody else has the new information? + *My local machine knows about all the name server information, + but no other sites know about me? + *My forward domain names work, but the backward names do not? + How to get useful information from nslookup + *Getting number to name mappings. + *Finding where mail goes when a machine has no IP number. + *Getting a list of machines in a domain from nslookup. + Appendicies + *Appendix A sample root.cache file + *Appendix B Excerpt from RFC 1340 - Assigned Numbers - July 1992 + *Appendix C Installing DNS on a Sun when running NIS + + +An Overview of the DNS: + +The Domain Name System is the software that lets you have name to number +mappings on your computers. The name decel.ecel.uwa.edu.au is the number +130.95.4.2 and vice versa. This is achieved through the DNS. The DNS is a +heirarchy. There are a small number of root domain name servers that are +responsible for tracking the top level domains and who is under them. The +root domain servers between them know about all the people who have name +servers that are authoritive for domains under the root. + +Being authoritive means that if a server is asked about something in that +domain, it can say with no ambiguity whether or not a given piece of +information is true. For example. We have domains x.z and y.z. There are +by definition authoritive name servers for both of these domains and we +shall assume that the name server in both of these cases is a machine +called nic.x.z and nic.y.z but that really makes no difference. + +If someone asks nic.x.z whether there is a machine called a.x.z, then +nic.x.z can authoritively say, yes or no because it is the authoritive name +server for that domain. If someone asks nic.x.z whether there is a machine +called a.y.z then nic.x.z asks nic.y.z whether such a machine exists (and +caches this for future requests). It asks nic.y.z because nic.y.z is the +authoritive name server for the domain y.z. The information about +authoritive name servers is stored in the DNS itself and as long as you +have a pointer to a name server who is more knowledgable than yourself then +you are set. + +When a change is made, it propogates slowly out through the internet to +eventually reach all machines. The following was supplied by Mark Andrews +Mark.Andrews@syd.dms.csiro.au. + + If both the primary and all secondaries are up and talking when + a zone update occurs and for the refresh period after the + update the old data will live for max(refresh + mininum) + average (refresh/2 +mininum) for the zone. New information will + be available from all servers after refresh. + +So with a refresh of 3 hours and a minimum of a day, you can expect +everything to be working a day after it is changed. If you have a longer +minimum, it may take a couple of days before things return to normal. + +There is also a difference between a zone and a domain. The domain is the +entire set of machines that are contained within an organisational domain +name. For example, the domain uwa.edu.au contains all the machines at the +University of Western Australia. A Zone is the area of the DNS for which a +server is responsible. The University of Western Australia is a large +organisation and trying to track all changes to machines at a central +location would be difficult. The authoritive name server for the zone +uwa.edu.au delegates the authority for the zone ecel.uwa.edu.au to +decel.ecel.uwa.edu.au. Machine foo.ecel.uwa.edu.au is in the zone that +decel is authoritive for. Machine bar.uwa.edu.au is in the zone that +uniwa.uwa.edu.au is authoritive for. + +Installing the DNS: + +First I'll assume you already have a copy of the Domain Name Server +software. It is probably called named or in.named depending on your +flavour of unix. I never had to get a copy, but if anyone thinks that +information should be here then by all means tell me and I'll put it in. +If you intend on using the package called Bind, then you should be sure +that you get version 4.9, which is the most recent version at this point in +time. + +The Boot File: + +First step is to create the file named.boot. This describes to named +(we'll dispense with the in.named. Take them to be the same) where the +information that it requires can be found. This file is normally found in +/etc/named.boot and I personally tend to leave it there because then I know +where to find it. If you don't want to leave it there but place it in a +directory with the rest of your named files, then there is usually an +option on named to specify the location of the boot file. + +Your typical boot file will look like this if you are an unimportant leaf +node and there are other name servers at your site. + +directory /etc/namedfiles + +cache . root.cache +primary ecel.uwa.edu.au ecel.uwa.domain +primary 0.0.127.in-addr.arpa 0.0.127.domain +primary 4.95.130.in-addr.arpa 4.95.130.domain +forwarders 130.95.128.1 + +Here is an alternative layout used by Christophe Wolfhugel +<Christophe.Wolfhugel@grasp.insa-lyon.fr> He finds this easier because of +the large number of domains he has. The structure is essentially the same, +but the file names use the domain name rather than the IP subnet to +describe the contents. + +directory /usr/local/etc/bind +cache . p/root +; +; Primary servers +; +primary fr.net p/fr.net +primary frmug.fr.net p/frmug.fr.net +primary 127.in-addr.arpa p/127 +; +; Secondary servers +; +secondary ensta.fr 147.250.1.1 s/ensta.fr +secondary gatelink.fr.net 134.214.100.1 s/gatelink.fr.net +secondary insa-lyon.fr 134.214.100.1 s/insa-lyon.fr +secondary loesje.org 145.18.226.21 s/loesje.org +secondary nl.loesje.org 145.18.226.21 s/nl.loesje.org +secondary pcl.ac.uk 161.74.160.5 s/pcl.ac.uk +secondary univ-lyon1.fr 134.214.100.1 s/univ-lyon1.fr +secondary wmin.ac.uk 161.74.160.5 s/wmin.ac.uk +secondary westminster.ac.uk 161.74.160.5 s/westminster.ac.uk +; +; +; Secondary for addresses +; +secondary 74.161.in-addr.arpa 161.74.160.5 s/161.74 +secondary 214.134.in-addr.arpa 134.214.100.1 s/134.214 +secondary 250.147.in-addr.arpa 147.250.1.1 s/147.250 +; +; Classes C +; +secondary 56.44.192.in-addr.arpa 147.250.1.1 s/192.44.56 +secondary 57.44.192.in-addr.arpa 147.250.1.1 s/192.44.57 + +The lines in the named.boot file have the following meanings. + +directory + +This is the path that named will place in front of all file names +referenced from here on. If no directory is specified, it looks for files +relative to /etc. + +cache + +This is the information that named uses to get started. Named must know +the IP number of some other name servers at least to get started. +Information in the cache is treated differently depending on your version +of named. Some versions of named use the information included in the cache +permenantly and others retain but ignore the cache information once up and +running. + +primary + +This is one of the domains for which this machine is authorative for. You +put the entire domain name in. You need forwards and reverse lookups. The +first value is the domain to append to every name included in that file. +(There are some exceptions, but they will be explained later) The name at +the end of the line is the name of the file (relative to /etc of the +directory if you specified one). The filename can have slashes in it to +refer to subdirectories so if you have a lot of domains you may want to +split it up. + +BE VERY CAREFUL TO PUT THE NUMBERS BACK TO FRONT FOR THE REVERSE LOOK UP +FILE. The example given above is for the subnet ecel.uwa.edu.au whose IP +address is 130.95.4.*. The reverse name must be 4.95.130.in-addr.arpa. +It must be backwards and it must end with .in-addr.arpa. If your reverse +name lookups don't work, check this. If they still don't work, check this +again. + +forwarders + +This is a list of IP numbers for forward requests for sites about which we +are unsure. A good choice here is the name server which is authoritive for +the zone above you. + +secondary (This line is not in the example, but is worth mentioning.) + +A secondary line indicates that you wish to be a secondary name server for +this domain. You do not need to do this usually. All it does is help make +the DNS more robust. You should have at least one secondary server for +your site, but you do not need to be a secondary server for anyone else. +You can by all means, but you don't need to be. If you want to be a +secondary server for another domain, then place the line + +secondary gu.uwa.edu.au 130.95.100.3 130.95.128.1 + +in your named.boot. This will make your named try the servers on both of +the machines specified to see if it can obtain the information about those +domains. You can specify a number of IP addresses for the machines to +query that probably depends on your machine. Your copy of named will upon +startup go and query all the information it can get about the domain in +question and remember it and act as though it were authoritive for that +domain. + +Next you will want to start creating the data files that contain the name +definitions. + +The cache file: + +You can get a copy of the cache file from FTP.RS.INTERNIC.NET. The current +copy can be found in Appendix A. + +The Forward Mapping file: +The file ecel.uwa.edu.au. will be used for the example with a couple of +machines left in for the purpose of the exercise. Here is a copy of what +the file looks like with explanations following. + +; Authoritative data for ecel.uwa.edu.au +; +@ IN SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. ( + 93071200 ; Serial (yymmddxx) + 10800 ; Refresh 3 hours + 3600 ; Retry 1 hour + 3600000 ; Expire 1000 hours + 86400 ) ; Minimum 24 hours + IN A 130.95.4.2 + IN MX 100 decel + IN MX 150 uniwa.uwa.edu.au. + IN MX 200 relay1.uu.net. + IN MX 200 relay2.uu.net. + +localhost IN A 127.0.0.1 + +decel IN A 130.95.4.2 + IN HINFO SUN4/110 UNIX + IN MX 100 decel + IN MX 150 uniwa.uwa.edu.au. + IN MX 200 relay1.uu.net + IN MX 200 relay2.uu.net + +gopher IN CNAME decel.ecel.uwa.edu.au. + +accfin IN A 130.95.4.3 + IN HINFO SUN4/110 UNIX + IN MX 100 decel + IN MX 150 uniwa.uwa.edu.au. + IN MX 200 relay1.uu.net + IN MX 200 relay2.uu.net + +chris-mac IN A 130.95.4.5 + IN HINFO MAC-II MACOS + +The comment character is ';' so the first two lines are just comments +indicating the contents of the file. + +All values from here on have IN in them. This indicates that the value is +an InterNet record. There are a couple of other types, but all you need +concern yourself with is internet ones. + +The SOA record is the Start Of Authority record. It contains the +information that other nameservers will learn about this domain and how to +treat the information they are given about it. The '@' as the first +character in the line indicates that you wish to define things about the +domain for which this file is responsible. The domain name is found in the +named.boot file in the corresponding line to this filename. All +information listed refers to the most recent machine/domain name so all +records from the '@' until 'localhost' refer to the '@'. The SOA record +has 5 magic numbers. First magic number is the serial number. If you +change the file, change the serial number. If you don't, no other name +servers will update their information. The old information will sit around +for a very long time. + +Refresh is the time between refreshing information about the SOA (correct +me if I am wrong). Retry is the frequency of retrying if an authorative +server cannot be contacted. Expire is how long a secondary name server +will keep information about a zone without successfully updating it or +confirming that the data is up to date. This is to help the information +withstand fairly lengthy downtimes of machines or connections in the +network without having to recollect all the information. Minimum is the +default time to live value handed out by a nameserver for all records in +a zone without an explicit TTL value. This is how long the data will live +after being handed out. The two pieces of information before the 5 magic +numbers are the machine that is considered the origin of all of this +information. Generally the machine that is running your named is a good +one for here. The second is an email address for someone who can fix any +problems that may occur with the DNS. Good ones here are postmaster, +hostmaster or root. NOTE: You use dots and not '@' for the email address. + +eg root.decel.ecel.uwa.edu.au is correct + and + root@decel.ecel.uwa.edu.au is incorrect. + +We now have an address to map ecel.uwa.edu.au to. The address is +130.95.4.2 which happens to be decel, our main machine. If you try to find +an IP number for the domain ecel.uwa.edu.au it will get you the machine +decel.ecel.uwa.edu.au's IP number. This is a nicety which means that +people who have non-MX record mailers can still mail fred@ecel.uwa.edu.au +and don't have to find the name of a machine name under the domain to mail. + +Now we have a couple of MX records for the domain itself. The MX records +specify where to send mail destined for the machine/domain that the MX +record is for. In this case we would prefer if all mail for +fred@ecel.uwa.edu.au is sent to decel.ecel.uwa.edu.au. If that does not +work, we would like it to go to uniwa.uwa.edu.au because there are a number +of machines that might have no idea how to get to us, but may be able to get +to uniwa. And failing that, try the site relay1.uu.net. A small number +indicates that this site should be tried first. The larget the number the +further down the list of sites to try the site is. NOTE: Not all machines +have mailers that pay attention to MX records. Some only pay attention to +IP numbers, which is really stupid. All machines are required to have +MX-capable Mail Transfer Agents (MTA) as there are many addresses that can +only be reached via this means. + +There is an entry for localhost now. Note that this is somewhat of a +kludge and should probably be handled far more elegantly. By placing +localhost here, a machine comes into existance called +localhost.ecel.uwa.edu.au. If you finger it, or telnet to it, you get your +own machine, because the name lookup returns 127.0.0.1 which is the special +case for your own machine. I have used a couple of different DNS packages. +The old BSD one let you put things into the cache which would always work, +but would not be exported to other nameservers. In the newer Sun one, they +are left in the cache and are mostly ignored once named is up and running. +This isn't a bad solution, its just not a good one. + +Decel is the main machine in our domain. It has the IP number 130.95.4.2 +and that is what this next line shows. It also has a HINFO entry. HINFO +is Host Info which is meant to be some sort of an indication of what the +machine is and what it runs. The values are two white space seperated +values. First being the hardware and second being the software. HINFO is +not compulsory, its just nice to have sometimes. We also have some MX +records so that mail destined for decel has some other avenues before it +bounces back to the sender if undeliverable. + +It is a good idea to give all machines capable of handling mail an MX +record because this can be cached on remote machines and will help to +reduce the load on the network. + +gopher.ecel.uwa.edu.au is the gopher server in our division. Now because +we are cheapskates and don't want to go and splurge on a seperate machine +just for handling gopher requests we have made it a CNAME to our main +machine. While it may seem pointless it does have one main advantage. +When we discover that our placing terrabytes of popular quicktime movies +on our gopher server (no we haven't and we don't intend to) causes an +unbearable load on our main machine, we can quickly move the CNAME to +point at a new machine by changing the name mentioned in the CNAME. Then +the slime of the world can continue to get their essential movies with a +minimal interuption to the network. Other good CNAMEs to maintain are +things like ftp, mailhost, netfind, archie, whois, and even dns (though the +most obvious use for this fails). It also makes it easier for people to +find these services in your domain. + +We should probably start using WKS records for things like gopher and whois +rather than making DNS names for them. The tools are not in wide +circulation for this to work though. (Plus all those comments in many DNS +implementation of "Not implemented" next to the WKS record) + +Finally we have a macintosh which belongs to my boss. All it needs is an +IP number, and we have included the HINFO so that you can see that it is in +fact a macII running a Mac System. To get the list of preferred values, +you should get a copy of RFC 1340. It lists lots of useful information +such as /etc/services values, ethernet manufacturer hardware addresses, +HINFO defualts and many others. I will include the list as it stands at +the moment, but if any RFC superceeds 1340, then it will have a more +complete list. See Appendix B for that list. + +NOTE: If Chris had a very high profile and wanted his mac to appear like a +fully connected unix machine as far as internet services were concerned, he +could simply place an MX record such as + + IN MX 100 decel + +after his machine and any mail sent to chris@chris-mac.ecel.uwa.edu.au +would be automatically rerouted to decel. + +The Reverse Mapping File + +The reverse name lookup is handled in a most bizarre fashion. Well it all +makes sense, but it is not immediately obvious. + +All of the reverse name lookups are done by finding the PTR record +associated with the name w.x.y.z.in-addr.arpa. So to find the name +associated with the IP number 1.2.3.4, we look for information stored in +the DNS under the name 4.3.2.1.in-addr.arpa. They are organised this way +so that when you are allocated a B class subnet for example, you get all of +the IP numbers in the domain 130.95. Now to turn that into a reverse name +lookup domain, you have to invert the numbers or your registered domains +will be spread all over the place. It is a mess and you need not understand +the finer points of it all. All you need to know is that you put the +reverse name lookup files back to front. + +Here is the sample reverse name lookup files to go with our example. + +0.0.127.in-addr.arpa +-- +; Reverse mapping of domain names 0.0.127.in-addr.arpa +; Nobody pays attention to this, it is only so 127.0.0.1 -> localhost. +@ IN SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. ( + 91061801 ; Serial (yymmddxx) + 10800 ; Refresh 3 hours + 3600 ; Retry 1 hour + 3600000 ; Expire 1000 hours + 86400 ) ; Minimum 24 hours +; +1 IN PTR localhost.ecel.uwa.edu.au. +-- + +4.95.130.in-addr.arpa +-- +; reverse mapping of domain names 4.95.130.in-addr.arpa +; +@ IN SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. ( + 92050300 ; Serial (yymmddxx format) + 10800 ; Refresh 3hHours + 3600 ; Retry 1 hour + 3600000 ; Expire 1000 hours + 86400 ) ; Minimum 24 hours +2 IN PTR decel.ecel.uwa.edu.au. +3 IN PTR accfin.ecel.uwa.edu.au. +5 IN PTR chris-mac.ecel.uwa.edu.au. +-- + +It is important to remember that you must have a second start of authority +record for the reverse name lookups. Each reverse name lookup file must +have its own SOA record. The reverse name lookup on the 127 domain is +debatable seeing as there is likely to be only one number in the file and +it is blatantly obvious what it is going to map to. + +The SOA details are the same as in the forward mapping. + +Each of the numbers listed down the left hand side indicates that the line +contains information for that number of the subnet. Each of the subnets +must be the more significant digits. eg the 130.95.4 of an IP number +130.95.4.2 is implicit for all numbers mentioned in the file. + +The PTR must point to a machine that can be found in the DNS. If the name +is not in the DNS, some versions of named just bomb out at this point. + +Reverse name lookups are not compulsory, but nice to have. It means that +when people log into machines, they get names indicating where they are +logged in from. It makes it easier for you to spot things that are wrong +and it is far less cryptic than having lots of numbers everywhere. Also if +you do not have a name for your machine, some brain dead protocols such as +talk will not allow you to connect. + +Since I had this I had one suggestion of an alternative way to do the +localhost entry. I think it is a matter of personal opinion so I'll +include it here in case anyone things that this is a more appropriate +method. + +The following is courtesy of jep@convex.nl (JEP de Bie) + + The way I did it was: + + 1) add in /etc/named.boot: + + primary . localhost + primary 127.in-addr.ARPA. IP127 + +(Craig: It has been suggested by Mark Andrews that this is a bad practice + particularly if you have upgraded to Bind 4.9. You also run the risk of + polluting the root name servers. This comes down to a battle of idealogy + and practicality. Think twice before declaring yourself authorative for + the root domain.) + + So I not only declare myself (falsely? - probably, but nobody is going to + listen anyway most likely [CPR]:-) athorative in the 127.in-addr.ARPA domain + but also in the . (root) domain. + + 2) the file localhost has: + + $ORIGIN . + localhost IN A 127.0.0.1 + + 3) and the file IP127: + + $ORIGIN 127.in-addr.ARPA. + 1.0.0 IN PTR localhost. + + 4) and I have in my own domain file (convex.nl) the line: + + $ORIGIN convex.nl. + localhost IN CNAME localhost. + + The advantage (elegancy?) is that a query (A) of localhost. gives the + reverse of the query of 1.0.0.127.in-addr.ARPA. And it also shows that + localhost.convex.nl is only a nickname to something more absolute. + (While the notion of localhost is of course relative :-)). + + And I also think there is a subtle difference between the lines + + primary 127.in-addr.ARPA. IP127 + and + primary 0.0.127.in-addr.ARPA. 4.95.130.domain + ============= + JEP de Bie + jep@convex.nl + ============= + + + +Delegating authority for domains within your domain: + +When you start having a very big domain that can be broken into logical and +seperate 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 +organisation 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 recognised by the outside world, the server responsible for the +zone above you must have created a NS record for your machine in your +domain. For example, putting the computer club onto the network and giving +them control over their own part of the domain space we have the following. + +The machine authorative for gu.uwa.edu.au is mackerel and the machine +authorative for ucc.gu.uwa.edu.au is marlin. + +in mackerel's data for gu.uwa.edu.au we have the following + +@ IN SOA ... + IN A 130.95.100.3 + IN MX mackerel.gu.uwa.edu.au. + IN MX uniwa.uwa.edu.au. + +marlin IN A 130.95.100.4 + +ucc IN NS marlin.gu.uwa.edu.au. + IN NS mackerel.gu.uwa.edu.au. + +Marlin is also given an IP in our domain as a convenience. If they blow up +their name serving there is less that can go wrong because people can still +see that machine which is a start. You could place "marlin.ucc" in the +first column and leave the machine totally inside the ucc domain as well. + +The second NS line is because mackerel will be acting as secondary name +server for the ucc.gu domain. Do not include this line if you are not +authorative for the information included in the sub-domain. + + +Troubleshooting your named: + +Named doesn't work! What is wrong? + +Step 1: Run nslookup and see what nameserver it tries to connect you to. +If nslookup connects you to the wrong nameserver, create a /etc/resolv.conf +file that points your machine at the correct nameserver. If there is no +resolv.conf file, the the resolver uses the nameserver on the local +machine. + +Step 2: Make sure that named is actually running. + +Step 3: Restart named and see if you get any error messages on the +console and in also check /usr/adm/messages. + +Step 4: If named is running, nslookup connects to the appropriate +nameserver and nslookup can answer simple questions, but other programs +such as 'ping' do not work with names, then you need to install resolv+ +most likely. + + +I changed my named database and my local machine has noticed, but nobody +else has the new information? + +Change the serial number in the SOA for any domains that you modified and +restart named. Wait an hour and check again. The information propogates +out. It won't change immediately. + + +My local machine knows about all the name server information, but no other +sites know about me? + +Find an upstream nameserver (one that has an SOA for something in your +domain) and ask them to be a secondary name server for you. eg if you are +ecel.uwa.edu.au, ask someone who has an SOA for the domain uwa.edu.au. +Get NS records (and glue) added to your parent zone for your zone. This is +called delegating. It should be done formally like this or you will get +inconsistant answers out of the DNS. ALL NAMSERVERS FOR YOUR ZONE SHOULD +BE LISTED IN THIS MANNER. + + +My forward domain names work, but the backward names do not? + +Make sure the numbers are back to front and have the in-addr.arpa on the +end. +Make sure you reverse zone is registered. For Class C nets this can be done +by mailing to hostmaster@internic.net. For class A & B nets make sure that +you are registeres with the primary for your net and that the net itself +is registered with hostmaster@internic.net. + + +How to get useful information from nslookup: + +Nslookup is a very useful program but I'm sure there are less than 20 +people worldwide who know how to use it to its full usefulness. I'm most +certainly not one of them. If you don't like using nslookup, there is at +least one other program called dig, that has most/all(?) of the +functionality of nslookup and is a hell of a lot easier to use. + +I won't go into dig much here except to say that it is a lot easier to get +this information out of. I won't bother because nslookup ships with almost +all machines that come with network software. + +To run nslookup, you usually just type nslookup. It will tell you the +server it connects to. You can specify a different server if you want. +This is useful when you want to tell if your named information is +consistent with other servers. + +Getting name to number mappings. + +Type the name of the machine. Typing 'decel' is enough if the machine is +local. + +(Once you have run nslookup successfully) +> decel +Server: ecel.uwa.edu.au +Address: 130.95.4.2 + +Name: decel.ecel.uwa.edu.au +Address: 130.95.4.2 + +> + +One curious quirk of some name resolvers is that if you type a +machine name, they will try a number of permutations. For example if my +machine is in the domain ecel.uwa.edu.au and I try to find a machine +called fred, the resolver will try the following. + + fred.ecel.uwa.edu.au. + fred.uwa.edu.au. + fred.edu.au. + fred.au. + fred. + +This can be useful, but more often than not, you would simply prefer a good +way to make aliases for machines that are commonly referenced. If you are +running resolv+, you should just be able to put common machines into the +host file. + +DIG: dig <machine name> + +Getting number to name mappings. + +Nslookup defaults to finding you the Address of the name specified. For +reverse lookups you already have the address and you want to find the +name that goes with it. If you read and understood the bit above where it +describes how to create the number to name mapping file, you would guess +that you need to find the PTR record instead of the A record. So you do +the following. + +> set type=ptr +> 2.4.95.130.in-addr.arpa +Server: decel.ecel.uwa.edu.au +Address: 130.95.4.2 + +2.4.95.130.in-addr.arpa host name = decel.ecel.uwa.edu.au +> + +nslookup tells you that the ptr for the machine name +2.4.95.130.in-addr.arpa points to the host decel.ecel.uwa.edu.au. + +DIG: dig -x <machine number> + +Finding where mail goes when a machine has no IP number. + +When a machine is not IP connected, it needs to specify to the world, where +to send the mail so that it can dial up and collect it every now and then. +This is accomplished by setting up an MX record for the site and not giving +it an IP number. To get the information out of nslookup as to where the +mail goes, do the following. + +> set type=mx +> dialix.oz.au +Server: decel.ecel.uwa.oz.au +Address: 130.95.4.2 + +Non-authoritative answer: +dialix.oz.au preference = 100, mail exchanger = uniwa.uwa.OZ.AU +dialix.oz.au preference = 200, mail exchanger = munnari.OZ.AU +Authoritative answers can be found from: +uniwa.uwa.OZ.AU inet address = 130.95.128.1 +munnari.OZ.AU inet address = 128.250.1.21 +munnari.OZ.AU inet address = 192.43.207.1 +mulga.cs.mu.OZ.AU inet address = 128.250.35.21 +mulga.cs.mu.OZ.AU inet address = 192.43.207.2 +dmssyd.syd.dms.CSIRO.AU inet address = 130.155.16.1 +ns.UU.NET inet address = 137.39.1.3 + +You tell nslookup that you want to search for mx records and then you give +it the name of the machine. It tells you the preference for the mail +(small means more preferable), and who the mail should be sent to. It also +includes sites that are authorative (have this name in their named database +files) for this MX record. There are multiple sites as a backup. As can +be seen, our local public internet access company dialix would like all of +their mail to be sent to uniwa, where they collect it from. If uniwa is +not up, send it to munnari and munnari will get it to uniwa eventually. + +NOTE: For historical reasons Australia used to be .oz which was changed to +.oz.au to move to the ISO standard extensions upon the advent of IP. We +are now moving to a more normal heirarchy which is where the .edu.au comes +from. Pity, I liked having oz. + +DIG: dig <zone> mx + +Getting a list of machines in a domain from nslookup. + +Find a server that is authorative for the domain or just generally all +knowing. To find a good server, find all the soa records for a given +domain. To do this, you set type=soa and enter the domain just like in the +two previous examples. + +Once you have a server type + +> ls gu.uwa.edu.au. +[uniwa.uwa.edu.au] +Host or domain name Internet address + gu server = mackerel.gu.uwa.edu.au + gu server = uniwa.uwa.edu.au + gu 130.95.100.3 + snuffle-upagus 130.95.100.131 + mullet 130.95.100.2 + mackerel 130.95.100.3 + marlin 130.95.100.4 + gugate 130.95.100.1 + gugate 130.95.100.129 + helpdesk 130.95.100.180 + lan 130.95.100.0 + big-bird 130.95.100.130 + +To get a list of all the machines in the domain. + +If you wanted to find a list of all of the MX records for the domain, you +can put a -m flag in the ls command. + +> ls -m gu.uwa.edu.au. +[uniwa.uwa.edu.au] +Host or domain name Metric Host + gu 100 mackerel.gu.uwa.edu.au + gu 200 uniwa.uwa.edu.au + +This only works for a limited selection of the different types. + +DIG: dig axfr <zone> @<server> + + + +Appendix A + + +; +; This file holds the information on root name servers needed to +; initialize cache of Internet domain name servers +; (e.g. reference this file in the "cache . <file>" +; configuration file of BIND domain name servers). +; +; This file is made available by InterNIC registration services +; under anonymous FTP as +; file /domain/named.root +; on server FTP.RS.INTERNIC.NET +; -OR- under Gopher at RS.INTERNIC.NET +; under menu InterNIC Registration Services (NSI) +; submenu InterNIC Registration Archives +; file named.root +; +; last update: April 21, 1993 +; related version of root zone: 930421 +; +. 99999999 IN NS NS.INTERNIC.NET. +NS.INTERNIC.NET. 99999999 A 198.41.0.4 +. 99999999 NS KAVA.NISC.SRI.COM. +KAVA.NISC.SRI.COM. 99999999 A 192.33.33.24 +. 99999999 NS C.NYSER.NET. +C.NYSER.NET. 99999999 A 192.33.4.12 +. 99999999 NS TERP.UMD.EDU. +TERP.UMD.EDU. 99999999 A 128.8.10.90 +. 99999999 NS NS.NASA.GOV. +NS.NASA.GOV. 99999999 A 128.102.16.10 + 99999999 A 192.52.195.10 +. 99999999 NS NS.NIC.DDN.MIL. +NS.NIC.DDN.MIL. 99999999 A 192.112.36.4 +. 99999999 NS AOS.ARL.ARMY.MIL. +AOS.ARL.ARMY.MIL. 99999999 A 128.63.4.82 + 99999999 A 192.5.25.82 +. 99999999 NS NIC.NORDU.NET. +NIC.NORDU.NET. 99999999 A 192.36.148.17 +; End of File + + +Appendix B + +An Excerpt from +RFC 1340 Assigned Numbers July 1992 + + + MACHINE NAMES + + These are the Official Machine Names as they appear in the Domain Name + System HINFO records and the NIC Host Table. Their use is described in + RFC-952 [53]. + + A machine name or CPU type may be up to 40 characters taken from the + set of uppercase letters, digits, and the two punctuation characters + hyphen and slash. It must start with a letter, and end with a letter + or digit. + + ALTO DEC-1080 + ALTOS-6800 DEC-1090 + AMDAHL-V7 DEC-1090B + APOLLO DEC-1090T + ATARI-104ST DEC-2020T + ATT-3B1 DEC-2040 + ATT-3B2 DEC-2040T + ATT-3B20 DEC-2050T + ATT-7300 DEC-2060 + BBN-C/60 DEC-2060T + BURROUGHS-B/29 DEC-2065 + BURROUGHS-B/4800 DEC-FALCON + BUTTERFLY DEC-KS10 + C/30 DEC-VAX-11730 + C/70 DORADO + CADLINC DPS8/70M + CADR ELXSI-6400 + CDC-170 EVEREX-386 + CDC-170/750 FOONLY-F2 + CDC-173 FOONLY-F3 + CELERITY-1200 FOONLY-F4 + CLUB-386 GOULD + COMPAQ-386/20 GOULD-6050 + COMTEN-3690 GOULD-6080 + CP8040 GOULD-9050 + CRAY-1 GOULD-9080 + CRAY-X/MP H-316 + CRAY-2 H-60/68 + CTIWS-117 H-68 + DANDELION H-68/80 + DEC-10 H-89 + DEC-1050 HONEYWELL-DPS-6 + DEC-1077 HONEYWELL-DPS-8/70 + HP3000 ONYX-Z8000 + HP3000/64 PDP-11 + IBM-158 PDP-11/3 + IBM-360/67 PDP-11/23 + IBM-370/3033 PDP-11/24 + IBM-3081 PDP-11/34 + IBM-3084QX PDP-11/40 + IBM-3101 PDP-11/44 + IBM-4331 PDP-11/45 + IBM-4341 PDP-11/50 + IBM-4361 PDP-11/70 + IBM-4381 PDP-11/73 + IBM-4956 PE-7/32 + IBM-6152 PE-3205 + IBM-PC PERQ + IBM-PC/AT PLEXUS-P/60 + IBM-PC/RT PLI + IBM-PC/XT PLURIBUS + IBM-SERIES/1 PRIME-2350 + IMAGEN PRIME-2450 + IMAGEN-8/300 PRIME-2755 + IMSAI PRIME-9655 + INTEGRATED-SOLUTIONS PRIME-9755 + INTEGRATED-SOLUTIONS-68K PRIME-9955II + INTEGRATED-SOLUTIONS-CREATOR PRIME-2250 + INTEGRATED-SOLUTIONS-CREATOR-8 PRIME-2655 + INTEL-386 PRIME-9955 + INTEL-IPSC PRIME-9950 + IS-1 PRIME-9650 + IS-68010 PRIME-9750 + LMI PRIME-2250 + LSI-11 PRIME-750 + LSI-11/2 PRIME-850 + LSI-11/23 PRIME-550II + LSI-11/73 PYRAMID-90 + M68000 PYRAMID-90MX + MAC-II PYRAMID-90X + MASSCOMP RIDGE + MC500 RIDGE-32 + MC68000 RIDGE-32C + MICROPORT ROLM-1666 + MICROVAX S1-MKIIA + MICROVAX-I SMI + MV/8000 SEQUENT-BALANCE-8000 + NAS3-5 SIEMENS + NCR-COMTEN-3690 SILICON-GRAPHICS + NEXT/N1000-316 SILICON-GRAPHICS-IRIS + NOW SGI-IRIS-2400 + SGI-IRIS-2500 SUN-3/50 + SGI-IRIS-3010 SUN-3/60 + SGI-IRIS-3020 SUN-3/75 + SGI-IRIS-3030 SUN-3/80 + SGI-IRIS-3110 SUN-3/110 + SGI-IRIS-3115 SUN-3/140 + SGI-IRIS-3120 SUN-3/150 + SGI-IRIS-3130 SUN-3/160 + SGI-IRIS-4D/20 SUN-3/180 + SGI-IRIS-4D/20G SUN-3/200 + SGI-IRIS-4D/25 SUN-3/260 + SGI-IRIS-4D/25G SUN-3/280 + SGI-IRIS-4D/25S SUN-3/470 + SGI-IRIS-4D/50 SUN-3/480 + SGI-IRIS-4D/50G SUN-4/60 + SGI-IRIS-4D/50GT SUN-4/110 + SGI-IRIS-4D/60 SUN-4/150 + SGI-IRIS-4D/60G SUN-4/200 + SGI-IRIS-4D/60T SUN-4/260 + SGI-IRIS-4D/60GT SUN-4/280 + SGI-IRIS-4D/70 SUN-4/330 + SGI-IRIS-4D/70G SUN-4/370 + SGI-IRIS-4D/70GT SUN-4/390 + SGI-IRIS-4D/80GT SUN-50 + SGI-IRIS-4D/80S SUN-100 + SGI-IRIS-4D/120GTX SUN-120 + SGI-IRIS-4D/120S SUN-130 + SGI-IRIS-4D/210GTX SUN-150 + SGI-IRIS-4D/210S SUN-170 + SGI-IRIS-4D/220GTX SUN-386i/250 + SGI-IRIS-4D/220S SUN-68000 + SGI-IRIS-4D/240GTX SYMBOLICS-3600 + SGI-IRIS-4D/240S SYMBOLICS-3670 + SGI-IRIS-4D/280GTX SYMMETRIC-375 + SGI-IRIS-4D/280S SYMULT + SGI-IRIS-CS/12 TANDEM-TXP + SGI-IRIS-4SERVER-8 TANDY-6000 + SPERRY-DCP/10 TEK-6130 + SUN TI-EXPLORER + SUN-2 TP-4000 + SUN-2/50 TRS-80 + SUN-2/100 UNIVAC-1100 + SUN-2/120 UNIVAC-1100/60 + SUN-2/130 UNIVAC-1100/62 + SUN-2/140 UNIVAC-1100/63 + SUN-2/150 UNIVAC-1100/64 + SUN-2/160 UNIVAC-1100/70 + SUN-2/170 UNIVAC-1160 + UNKNOWN + VAX-11/725 + VAX-11/730 + VAX-11/750 + VAX-11/780 + VAX-11/785 + VAX-11/790 + VAX-11/8600 + VAX-8600 + WANG-PC002 + WANG-VS100 + WANG-VS400 + WYSE-386 + XEROX-1108 + XEROX-8010 + ZENITH-148 + + SYSTEM NAMES + + These are the Official System Names as they appear in the Domain Name + System HINFO records and the NIC Host Table. Their use is described + in RFC-952 [53]. + + A system name may be up to 40 characters taken from the set of upper- + case letters, digits, and the three punctuation characters hyphen, + period, and slash. It must start with a letter, and end with a + letter or digit. + + AEGIS LISP SUN OS 3.5 + APOLLO LISPM SUN OS 4.0 + AIX/370 LOCUS SWIFT + AIX-PS/2 MACOS TAC + BS-2000 MINOS TANDEM + CEDAR MOS TENEX + CGW MPE5 TOPS10 + CHORUS MSDOS TOPS20 + CHRYSALIS MULTICS TOS + CMOS MUSIC TP3010 + CMS MUSIC/SP TRSDOS + COS MVS ULTRIX + CPIX MVS/SP UNIX + CTOS NEXUS UNIX-BSD + CTSS NMS UNIX-V1AT + DCN NONSTOP UNIX-V + DDNOS NOS-2 UNIX-V.1 + DOMAIN NTOS UNIX-V.2 + DOS OS/DDP UNIX-V.3 + EDX OS/2 UNIX-PC + ELF OS4 UNKNOWN + EMBOS OS86 UT2D + EMMOS OSX V + EPOS PCDOS VM + FOONEX PERQ/OS VM/370 + FUZZ PLI VM/CMS + GCOS PSDOS/MIT VM/SP + GPOS PRIMOS VMS + HDOS RMX/RDOS VMS/EUNICE + IMAGEN ROS VRTX + INTERCOM RSX11M WAITS + IMPRESS RTE-A WANG + INTERLISP SATOPS WIN32 + IOS SCO-XENIX/386 X11R3 + IRIX SCS XDE + ISI-68020 SIMP XENIX + ITS SUN + + + +Appendix C Installing DNS on a Sun when running NIS + +==================== + 2) How to get DNS to be used when running NIS ? + + First setup the appropriate /etc/resolv.conf file. + Something like this should do the "trick". + + ; + ; Data file for a client. + ; + domain local domain + nameserver address of primary domain nameserver + nameserver address of secondary domain nameserver + + where: "local domain" is the domain part of the hostnames. + For example, if your hostname is "thor.ece.uc.edu" + your "local domain" is "ece.uc.edu". + + You will need to put a copy of this resolv.conf on + all NIS(YP) servers including slaves. + + Under SunOS 4.1 and greater, change the "B=" at the top + of the /var/yp/Makefile to "B=-b" and setup NIS in the + usual fashion. + + You will need reboot or restart ypserv for these changes + to take affect. + + Under 4.0.x, edit the Makefile or apply the following "diff": + +*** Makefile.orig Wed Jan 10 13:22:11 1990 +--- Makefile Wed Jan 10 13:22:01 1990 +*************** +*** 63 **** +! | $(MAKEDBM) - $(YPDBDIR)/$(DOM)/hosts.byname; \ +--- 63 ---- +! | $(MAKEDBM) -b - $(YPDBDIR)/$(DOM)/hosts.byname; \ +*************** +*** 66 **** +! | $(MAKEDBM) - $(YPDBDIR)/$(DOM)/hosts.byaddr; \ +--- 66 ---- +! | $(MAKEDBM) -b - $(YPDBDIR)/$(DOM)/hosts.byaddr; \ +==================== + diff --git a/contrib/bind/doc/misc/style.txt b/contrib/bind/doc/misc/style.txt new file mode 100644 index 0000000..a966066 --- /dev/null +++ b/contrib/bind/doc/misc/style.txt @@ -0,0 +1,172 @@ +Path: vixie!vixie +From: vixie@vix.com (Paul A Vixie) +Newsgroups: comp.protocols.tcp-ip.domains +Subject: Re: Format of DNS files (style question) +Date: 28 Aug 94 03:17:08 +Organization: Vixie Enterprises +Lines: 159 +Distribution: inet +Message-ID: <VIXIE.94Aug28031708@office.home.vix.com> +References: <33onnr$i4u@zombie.ncsc.mil> +NNTP-Posting-Host: office.home.vix.com +In-reply-to: sjr@zombie.ncsc.mil's message of 27 Aug 1994 21:02:51 -0400 + +> (Style) Suggestions for how to layout DNS configuration files (both +> forward and reverse)? + +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 it's +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: style.txt,v 8.1 1995/12/22 21:59:52 vixie Exp $" 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. + +Anyone who wants to know how to maintain nonleaf zones, i.e., zones which +have few or no hosts in them but have hundreds or thousands of delegations, +should attend Usenix LISA in San Diego and be there for the SENDS talk. +Contact office@usenix.org for conference information. +-- +Paul Vixie +Redwood City, CA +decwrl!vixie!paul +<paul@vix.com> |
