diff options
Diffstat (limited to 'contrib/bind/doc/misc')
| -rw-r--r-- | contrib/bind/doc/misc/DynamicUpdate | 284 | ||||
| -rw-r--r-- | contrib/bind/doc/misc/FAQ.1of2 | 1602 | ||||
| -rw-r--r-- | contrib/bind/doc/misc/FAQ.2of2 | 1298 | ||||
| -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 |
6 files changed, 0 insertions, 4509 deletions
diff --git a/contrib/bind/doc/misc/DynamicUpdate b/contrib/bind/doc/misc/DynamicUpdate deleted file mode 100644 index fb4152c74f77..000000000000 --- a/contrib/bind/doc/misc/DynamicUpdate +++ /dev/null @@ -1,284 +0,0 @@ - - - Description of Dynamic Update and T_UNSPEC Code - - - - - Added by Mike Schwartz - University of Washington Computer Science Department - 11/86 - schwartz@cs.washington.edu - - - - -I have incorporated 2 new features into BIND: - 1. Code to allow (unauthenticated) dynamic updates: surrounded by - #ifdef ALLOW_UPDATES - 2. Code to allow data of unspecified type: surrounded by - #ifdef ALLOW_T_UNSPEC - -Note that you can have one or the other or both (or neither) of these -modifications running, by appropriately modifying the makefiles. Also, -the external interface isn't changed (other than being extended), i.e., -a BIND server that allows dynamic updates and/or T_UNSPEC data can -still talk to a 'vanilla' server using the 'vanilla' operations. - -The description that follows is broken into 3 parts: a functional -description of the dynamic update facility, a functional description of -the T_UNSPEC facility, and a discussion of the implementation of -dynamic updates. The implementation description is mostly intended for -those who want to make future enhancements (especially the addition of -a good authentication mechanism). If you make enhancements, I would be -interested in hearing about them. - - - - - - 1. Dynamic Update Facility - -I added this code in conjunction with my research into naming in large -heterogeneous systems. For the purposes of this research, I ignored -security issues. In other words, no authentication/authorization -mechanism exists to control updates. Authentication will hopefully be -addressed at some future point (although probably not by me). In the -mean time, BIND Internet name servers (as opposed to "private" name -server networks operating with their own port numbers, as I use in my -research) should be compiled *without* -DALLOW_UPDATES, so that the -integrity of the Internet name database won't be compromised by this -code. - - -There are 5 different dynamic update interfaces: - UPDATEA - add a resource record - UPDATED - delete a specific resource record - UPDATEDA - delete all named resource records - UPDATEM - modify a specific resource record - UPDATEMA - modify all named resource records - -These all work through the normal resolver interface, i.e., these -interfaces are opcodes, and the data in the buffers passed to -res_mkquery must conform to what is expected for the particular -operation (see the #ifdef ALLOW_UPDATES extensions to nstest.c for -example usage). - -UPDATEM is logically equivalent to an UPDATED followed by an UPDATEA, -except that the updates occur atomically at the primary server (as -usual with Domain servers, secondaries may become temporarily -inconsistent). The difference between UPDATED and UPDATEDA is that the -latter allows you to delete all RRs associated with a name; similarly -for UPDATEM and UPDATEMA. The reason for the UPDATE{D,M}A interfaces -is two-fold: - - 1. Sometimes you want to delete/modify some data, but you know you'll - only have a single RR for that data; in such a case, it's more - convenient to delete/modify the RR by just giving the name; - otherwise, you would have to first look it up, and then - delete/modify it. - - 2. It is sometimes useful to be able to delete/modify multiple RRs - this way, since one can then perform the operation atomically. - Otherwise, one would have to delete/modify the RRs one-by-one. - -One additional point to note about UPDATEMA is that it will return a -success status if there were *zero* or more RRs associated with the given -name (and the RR add succeeds), whereas UPDATEM, UPDATED, and UPDATEDA -will return a success status if there were *one* or more RRs associated -with the given name. The reason for the difference is to handle the -(probably common) case where what you want to do is set a particular -name to contain a single RR, irrespective of whether or not it was -already set. - - - - - 2. T_UNSPEC Facility - -Type T_UNSPEC allows you to store data whose layout BIND doesn't -understand. Data of this type is not marshalled (i.e., converted -between host and network representation, as is done, for example, with -Internet addresses) by BIND, so it is up to the client to make sure -things work out ok w.r.t. heterogeneous data representations. The way -I use this type is to have the client marshal data, store it, retrieve -it, and demarshal it. This way I can store arbitrary data in BIND -without having to add new code for each specific type. - -T_UNSPEC data is dumped in an ASCII-encoded, checksummed format so -that, although it's not human-readable, it at least doesn't fill the -dump file with unprintable characters. - -Type T_UNSPEC is important for my research environment, where -potentially lots of people want to store data in the name service, and -each person's data looks different. Instead of having BIND understand -the format of each of their data types, the clients define marshaling -routines and pass buffers of marshalled data to BIND; BIND never tries -to demarshal the data...it just holds on to it, and gives it back to -the client when the client requests it, and the client must then -demarshal it. - -The Xerox Network System's name service (the Clearinghouse) works this -way. The reason 'vanilla' BIND understands the format of all the data -it holds is probably that BIND is tailored for a very specific -application, and wants to make sure the data it holds makes sense (and, -for some types, BIND needs to take additional action depending on the -data's semantics). For more general purpose name services (like the -Clearinghouse and my usage of BIND), this approach is less tractable. - -See the #ifdef ALLOW_T_UNSPEC extensions to nstest.c for example usage of -this type. - - - - - - - 3. Dynamic Update Implementation Description - -This section is divided into 3 subsections: General Discussion, -Miscellaneous Points, and Known Defects. - - - - - 3.1 General Discussion - -The basic scheme is this: When an update message arrives, a call is -made to InitDynUpdate, which first looks up the SOA record for the zone -the update affects. If this is the primary server for that zone, we do -the update and then update the zone serial number (so that secondaries -will refresh later). If this is a secondary server, we forward the -update to the primary, and if that's successful, we update our copy -afterwards. If it's neither, we refuse the update. (One might think -to try to propagate the update to an authoritative server; I figured -that updates will probably be most likely within an administrative -domain anyway; this could be changed if someone has strong feelings -about it). - -Note that this mechanism disallows updates when the primary is -down, preserving the Domain scheme's consistency requirements, -but making the primary a critical point for updates. This seemed -reasonable to me because - 1. Alternative schemes must deal with potentially complex - situations involving merging of inconsistent secondary - updates - 2. Updates are presumed to be rare relative to read accesses, - so this increased restrictiveness for updates over reads is - probably not critical - -I have placed comments through out the code, so it shouldn't be -too hard to see what I did. The majority of the processing is in -doupdate() and InitDynUpdate(). Also, I added a field to the zone -struct, to keep track of when zones get updated, so that only changed -zones get checkpointed. - - - - - - 3.2 Miscellaneous Points - -I use ns_maint to call zonedump() if the database changes, to -provide a checkpointing mechanism. I use the zone refresh times to -set up ns_maint interrupts if there are either secondaries or -primaries. Hence, if there is a secondary, this interrupt can cause -zoneref (as before), and if there is a primary, this interrupt can -cause doadump. I also checkpoint if needed before shutting down. - -You can force a server to checkpoint any changed zones by sending the -maint signal (SIGALRM) to the process. Otherwise it just checkpoints -during maint. interrupts, or when being shutdown (with SIGTERM). -Sending it the dump signal causes the database to be dumped into the -(single) dump file, but doesn't checkpoint (i.e., update the boot -files). Note that the boot files will be overwritten with checkpoint -files, so if you want to preserve the comments, you should keep copies -of the original boot files separate from the versions that are actually -used. - -I disallow T_SOA updates, for several reasons: - - T_SOA deletes at the primary wont be discovered by the secondaries - until they try to request them at maint time, which will cause - a failure - - the corresponding NS record would have to be deleted at the same - time (atomically) to avoid various problems - - T_SOA updates would have to be done in the right order, or else - the primary and secondaries will be out-of-sync for that zone. -My feeling is that changing the zone topology is a weighty enough thing -to do that it should involve changing the load file and reloading all -affected servers. - -There are alot of places where bind exits due to catastrophic failures -(mainly malloc failures). I don't try to dump the database in these -places because it's probably inconsistent anyway. It's probably better -to depend on the most recent dump. - - - - - - 3.2 Known Defects - -1. I put the following comment in nlookup (db_lookup.c): - - Note: at this point, if np->n_data is NULL, we could be in one - of two situations: Either we have come across a name for which - all the RRs have been (dynamically) deleted, or else we have - come across a name which has no RRs associated with it because - it is just a place holder (e.g., EDU). In the former case, we - would like to delete the namebuf, since it is no longer of use, - but in the latter case we need to hold on to it, so future - lookups that depend on it don't fail. The only way I can see - of doing this is to always leave the namebufs around (although - then the memory usage continues to grow whenever names are - added, and can never shrink back down completely when all their - associated RRs are deleted). - - Thus, there is a problem that the memory usage will keep growing for - the situation described. You might just choose to ignore this - problem (since I don't see any good way out), since things probably - wont grow fast anyway (how many names are created and then deleted - during a single server incarnation, after all?) - - The problem is that one can't delete old namebufs because one would - want to do it from db_update, but db_update calls nlookup to do the - actual work, and can't do it there, since we need to maintain place - holders. One could make db_update not call nlookup, so we know it's - ok to delete the namebuf (since we know the call is part of a delete - call); but then there is code with alot of overlapping functionality - in the 2 routines. - - This also causes another problem: If you create a name and then do - UPDATEDA, all it's RRs get deleted, but the name remains; then, if you - do a lookup on that name later, the name is found in the hash table, - but no RRs are found for it. It then forwards the query to itself (for - some reason), and then somehow decides there is no such domain, and then - returns (with the correct answer, but after going through extra work). - But the name remains, and each time it is looked up, we go through - these same steps. This should be fixed, but I don't have time right - now (and the right answer seems to come back anyway, so it's good - enough for now). - -2. There are 2 problems that crop up when you store data (other than - T_SOA and T_NS records) in the root: - a. Can't get primary to doaxfr RRs other than SOA and NS to - secondary. - b. Upon checkpoint (zonedump), this data sometimes comes out after other - data in the root, so that (since the SOA and NS records have null - names), they will get interpreted as being records under the - other names upon the next boot up. For example, if you have a - T_A record called ABC, the checkpoint may look like: - $ORIGIN . - ABC IN A 128.95.1.3 - 99999999 IN NS UW-BORNEO. - IN SOA UW-BORNEO. SCHWARTZ.CS.WASHINGTON.EDU. - ( 50 3600 300 3600000 3600 ) - Then when booting up the next time, the SOA and NS records get - interpreted as being called "ABC" rather than the null root - name. - -3. The secondary server caches the T_A RR for the primary, and hence when - it tries to ns_forw an update, it won't find the address of the primary - using nslookup unless that T_A RR is *also* stored in the main hashtable - (by putting it in a named.db file as well as the named.ca file). - diff --git a/contrib/bind/doc/misc/FAQ.1of2 b/contrib/bind/doc/misc/FAQ.1of2 deleted file mode 100644 index 99619eb37a25..000000000000 --- a/contrib/bind/doc/misc/FAQ.1of2 +++ /dev/null @@ -1,1602 +0,0 @@ -Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers -Path: vixie!news1.digital.com!su-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.mathworks.com!news.kei.com!uhog.mit.edu!rutgers!njitgw.njit.edu!hertz.njit.edu!cdp2582 -From: cdp2582@hertz.njit.edu (Chris Peckham) -Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 1 of 2) -Message-ID: <cptd-faq-1-849940949@njit.edu> -Followup-To: comp.protocols.tcp-ip.domains -Originator: cdp2582@hertz.njit.edu -Keywords: BIND,DOMAIN,DNS -Sender: news@njit.edu -Supersedes: <cptd-faq-1-847336183@njit.edu> -Nntp-Posting-Host: hertz.njit.edu -X-Posting-Frequency: posted during the first week of each month -Reply-To: domain-faq@njit.edu (comp.protocols.tcp-ip.domains FAQ comments) -Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA -Date: Sat, 7 Dec 1996 06:42:36 GMT -Approved: news-answers-request@MIT.EDU -Expires: Sat 11 Jan 97 02:42:29 EDT -Lines: 1582 -Xref: vixie comp.protocols.tcp-ip.domains:12904 comp.answers:22440 news.answers:85682 - -Posted-By: auto-faq 3.1.1.2 -Archive-name: internet/tcp-ip/domains-faq/part1 -Revision: 1.14 1996/12/07 06:42:05 - - -Note that this posting has been split into two parts because of its size. - -$Id: FAQ.1of2,v 8.4 1996/12/18 04:22:33 vixie Exp $ - -A new version of this document appears monthly. If this copy is more -than a month old it may be out of date. - -This FAQ is edited and maintained by Chris Peckham, <cdp@pfmc.net>. The -most recently posted version may be found for anonymous ftp from - -rtfm.mit.edu : /pub/usenet/news.answers/internet/tcp-ip/domains-faq - -It is also available in HTML from -http://www.users.pfmc.net/~cdp/cptd-faq/. - -If you can contribute any answers for items in the TODO section, please do -so by sending e-mail to <domain-faq@pfmc.net> ! If you know of any items -that are not included and you feel that they should be, send the -relevant information to <domain-faq@pfmc.net>. - -=============================================================================== - -Index - - Section 1. TO DO / UPDATES - Q1.1 Contributions needed - Q1.2 UPDATES / Changes since last posting - - Section 2. INTRODUCTION / MISCELLANEOUS - Q2.1 What is this newsgroup ? - Q2.2 More information - Q2.3 What is BIND ? - Q2.4 What is the difference between BIND and DNS ? - Q2.5 Where is the latest version of BIND located ? - Q2.6 How can I find the path taken between two systems/domains ? - Q2.7 How do you find the hostname given the TCP-IP address ? - Q2.8 How do I register a domain ? - Q2.9 How can I change the IP address of our server ? - Q2.10 Issues when changing your domain name - Q2.11 How memory and CPU does DNS use ? - Q2.12 Other things to consider when planning your servers - Q2.13 Proper way to get NS and reverse IP records into DNS - Q2.14 How do I get my address assigned from the NIC ? - Q2.15 Is there a block of private IP addresses I can use? - Q2.16 Does BIND cache negative answers (failed DNS lookups) ? - Q2.17 What does an NS record really do ? - Q2.18 DNS ports - Q2.19 What is the cache file - Q2.20 Obtaining the latest cache file - Q2.21 Selecting a nameserver/root cache - Q2.22 InterNIC and domain names - - Section 3. UTILITIES - Q3.1 Utilities to administer DNS zone files - Q3.2 DIG - Domain Internet Groper - Q3.3 DNS packet analyser - Q3.4 host - Q3.5 How can I use DNS information in my program? - Q3.6 A source of information relating to DNS - - Section 4. DEFINITIONS - Q4.1 TCP/IP Host Naming Conventions - Q4.2 What are slaves and forwarders ? - Q4.3 When is a server authoritative? - Q4.4 My server does not consider itself authoritative ! - Q4.5 NS records don't configure servers as authoritative ? - Q4.6 underscore in host-/domainnames - Q4.7 What is lame delegation ? - Q4.8 How can I see if the server is "lame" ? - Q4.9 What does opt-class field in a zone file do? - Q4.10 Top level domains - Q4.11 Classes of networks - Q4.12 What is CIDR ? - Q4.13 What is the rule for glue ? - - Section 5. CONFIGURATION - Q5.1 Changing a Secondary server to a Primary server ? - Q5.2 Moving a Primary server to another server - Q5.3 How do I subnet a Class B Address ? - Q5.4 Subnetted domain name service - Q5.5 Recommended format/style of DNS files - Q5.6 DNS on a system not connected to the Internet - Q5.7 Multiple Domain configuration - Q5.8 wildcard MX records - Q5.9 How do you identify a wildcard MX record ? - Q5.10 Why are fully qualified domain names recommended ? - Q5.11 Distributing load using named - Q5.12 Order of returned records - Q5.13 resolv.conf - Q5.14 How do I delegate authority for sub-domains ? - Q5.15 DNS instead of NIS on a Sun OS 4.1.x system - Q5.16 Patches to add functionality to BIND - Q5.17 How to serve multiple domains from one server - - Section 6. PROBLEMS - Q6.1 No address for root server - Q6.2 Error - No Root Nameservers for Class XX - Q6.3 Bind 4.9.x and MX querying? - Q6.4 Do I need to define an A record for localhost ? - Q6.5 MX records, CNAMES and A records for MX targets - Q6.6 Can an NS record point to a CNAME ? - Q6.7 Nameserver forgets own A record - Q6.8 General problems (core dumps !) - Q6.9 malloc and DECstations - Q6.10 Can't resolve names without a "." - Q6.11 Err/TO errors being reported - Q6.12 Why does swapping kill BIND ? - - Section 7. ACKNOWLEDGEMENTS - Q7.1 How is this FAQ generated ? - Q7.2 What formats are available ? - Q7.3 Contributors - -=============================================================================== - -Section 1. TO DO / UPDATES - - Q1.1 Contributions needed - Q1.2 UPDATES / Changes since last posting - ------------------------------------------------------------------------------ - -Question 1.1. Contributions needed - -Date: Fri Dec 6 00:40:00 EST 1996 - -* Expand the slave/forward section - ------------------------------------------------------------------------------ - -Question 1.2. UPDATES / Changes since last posting - -Date: Fri Dec 6 00:40:00 EST 1996 - -* The FAQ is now maintained in BFNN (Bizzare format with No Name). This - allows me to create ASCII, HTML, and GNU info (postscript coming soon) - from one source file. -* References to 4.9.4 changed to 4.9.5. -* memory/CPU usage question - removed uunet map reference. Not there... -* Minor edits of information and questions for new format. -* How do I delegate authority for sub-domains ? - edited answer - -=============================================================================== - -Section 2. INTRODUCTION / MISCELLANEOUS - - Q2.1 What is this newsgroup ? - Q2.2 More information - Q2.3 What is BIND ? - Q2.4 What is the difference between BIND and DNS ? - Q2.5 Where is the latest version of BIND located ? - Q2.6 How can I find the path taken between two systems/domains ? - Q2.7 How do you find the hostname given the TCP-IP address ? - Q2.8 How do I register a domain ? - Q2.9 How can I change the IP address of our server ? - Q2.10 Issues when changing your domain name - Q2.11 How memory and CPU does DNS use ? - Q2.12 Other things to consider when planning your servers - Q2.13 Proper way to get NS and reverse IP records into DNS - Q2.14 How do I get my address assigned from the NIC ? - Q2.15 Is there a block of private IP addresses I can use? - Q2.16 Does BIND cache negative answers (failed DNS lookups) ? - Q2.17 What does an NS record really do ? - Q2.18 DNS ports - Q2.19 What is the cache file - Q2.20 Obtaining the latest cache file - Q2.21 Selecting a nameserver/root cache - Q2.22 InterNIC and domain names - ------------------------------------------------------------------------------ - -Question 2.1. What is this newsgroup ? - -Date: Thu Dec 1 11:08:28 EST 1994 - -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. - ------------------------------------------------------------------------------ - -Question 2.2. More information - -Date: Fri Dec 6 00:41:03 EST 1996 - -You can find more information concerning DNS in the following places: - -* The BOG (BIND Operations Guide) - in the BIND distribution -* The FAQ included with BIND 4.9.5 in 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, 1912, 1918) -* The DNS Resources 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 which may be found for anonymous ftp at 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 ds.internic.net : /fyi/fyi4.txt - A version may also be obtained with the URL - gopher://ds.internic.net/00/fyi/fyi4.txt. -* Information on performing an initial installation of BIND may be found - using the DNS Resources Directory at - http://www.dns.net/dnsrd/docs/basic.txt -* Three other USEnet newsgroups: - - * comp.protocols.dns.bind - * comp.protocols.dns.ops - * comp.protocols.dns.std - ------------------------------------------------------------------------------ - -Question 2.3. What is BIND ? - -Date: Tue Sep 10 23:15:58 EDT 1996 - -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. - ------------------------------------------------------------------------------ - -Question 2.4. What is the difference between BIND and DNS ? - -Date: Tue Sep 10 23:15:58 EDT 1996 - -(text provided by Andras Salamon) DNS is the Domain Name System, a set of -protocols for a distributed database that was originally designed to -replace /etc/hosts files. DNS is most commonly used by applications to -translate domain names of hosts to IP addresses. A client of the DNS is -called a resolver; resolvers are typically located in the application -layer of the networking software of each TCP/IP capable machine. Users -typically do not interact directly with the resolver. Resolvers query the -DNS by directing queries at name servers that contain parts of the -distributed database that is accessed by using the DNS protocols. In -common usage, `the DNS' usually refers just to the data in the database. - -BIND (Berkeley Internet Name Domain) is an implementation of DNS, both -server and client. Development of BIND is funded by the Internet Software -Consortium and is coordinated by Paul Vixie. BIND has been ported to -Windows NT and VMS, but is most often found on Unix. BIND source code is -freely available and very complex; most of the development on the DNS -protocols is based on this code; and most Unix vendors ship BIND-derived -DNS implementations. As a result, the BIND name server is the most widely -used name server on the Internet. In common usage, `BIND' usually refers -to the name server that is part of the BIND distribution, and sometimes to -name servers in general (whether BIND-derived or not). - ------------------------------------------------------------------------------ - -Question 2.5. Where is the latest version of BIND located ? - -Fri Dec 6 00:23:19 EST 1996 - -This information may be found at http://www.vix.com/isc/bind.html - -At this time, BIND version of 4.9.5 may be found for anonymous ftp from - -ftp.vix.com : /pub/bind/release/4.9.5/bind-4.9.5-REL.tar.gz - -Other sites that officially mirror the BIND distribution are - -* bind.fit.qut.edu.au : /pub/bind -* ftp.funet.fi : /pub/unix/tcpip/dns/bind -* ftp.univ-lyon1.fr : /pub/mirrors/unix/bind -* ftp.oleane.net : /pub/mirrors/unix/bind -* ftp.ucr.ac.cr : /pub/Unix/dns/bind -* ftp.luth.se : /pub/unix/dns/bind/beta - -You may 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 - -prep.ai.mit.edu : /pub/gnu/gzip-1.2.4.tar - -patch is available for anonymous ftp from - -prep.ai.mit.edu : /pub/gnu/patch-2.1.tar.gz - -A version of BIND for Windows NT is available for anonymous ftp from - -ftp.vix.com : /pub/bind/release/4.9.5/contrib/ntdns495relbin.zip - -and - -ftp.vix.com : /pub/bind/release/4.9.5/contrib/ntbind495rel.zip - ------------------------------------------------------------------------------ - -Question 2.6. How can I find the path taken between two systems/domains ? - -Date: Fri Dec 6 00:10:31 EST 1996 - -On a Unix system, use traceroute. If it is not available to you, you may -obtain the source source for 'traceroute', compile it and install it on -your system. - -One version of this program with additional functionality may be found for -anonymous ftp from - -ftp.nikhef.nl : /pub/network/traceroute.tar.Z - -Another version may be found for anonymous ftp from - -ftp.psc.edu : /pub/net_tools/traceroute.tar - ------------------------------------------------------------------------------ - -Question 2.7. How do you find the hostname given the TCP-IP address ? - -Date: Thu Dec 1 09:55:24 EST 1994 - -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. - ------------------------------------------------------------------------------ - -Question 2.8. How do I register a domain ? - -Date: Wed Sep 4 23:59:42 EDT 1996 - -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 (or other similar organization). - -* anonymout ftp from internic.net : /templates -* gopher://rs.internic.net/ -* http://rs.internic.net/reg/reg-forms.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. - -Please note that the InterNIC is now charging a fee for domain names in -the "COM", "ORG", and "NET". More information may be found from the -Internic at - -http://rs.internic.net/domain-info/fee-policy.html - -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. - ------------------------------------------------------------------------------ - -Question 2.9. How can I change the IP address of our server ? - -Date: Sun May 5 22:46:28 EDT 1996 - -(From Mark Andrews) Before the move. - -* Ensure you are running a modern nameserver. BIND 4.9.3-REL + Patch1 is a - good choice. -* Inform all your secondaries that you are going to change. Have them - install both the current and new addresses in their named.boot's. -* Drop the ttl of the A's associated with the nameserver to something - small (5 min is usually good). -* Drop the refesh and retry times of the zone containing the forward - records for the server. -* Configure the new reverse zone before the move and make sure it is - operational. -* On the day of the move add the new A record(s) for the server. Don't - forget to have these added to parent domains. You will look like you are - multihomed with one interface dead. - -Move the machine after gracefully terminating any other services it is -offering. Then, - -* Fixup the A's, ttl, refresh and retry counters. (If you are running an - all server EDIT out all references to the old addresses in the cache - files). -* Inform all the secondaries the move is complete. -* Inform the parents of all zones you are primary of the new NS/A pairs - for the relevent zones. -* Inform all the administators of zones you are secondaring that the - machine has moved. -* For good measure update the serial no for all zones you are primary for. - This will flush out old A's. - ------------------------------------------------------------------------------ - -Question 2.10. Issues when changing your domain name - -Date: Sun Nov 27 23:32:41 EST 1994 - -If you are changing your domain name from abc.foobar.com to foobar.net, -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. - ------------------------------------------------------------------------------ - -Question 2.11. How memory and CPU does DNS use ? - -Date: Fri Dec 6 01:07:56 EST 1996 - -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: - -* How many zones do you have and how large are they ? -* 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. - ------------------------------------------------------------------------------ - -Question 2.12. Other things to consider when planning your servers - -Date: Mon Jan 2 14:24:51 EST 1995 - -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. ------------------------------------------------------------------------------ - -Question 2.13. Proper way to get NS and reverse IP records into DNS - -Date: Mon Jan 2 13:03:53 EST 1995 - -Reverse domain registration is separate from forward domain registration. -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. - ------------------------------------------------------------------------------ - -Question 2.14. How do I get my address assigned from the NIC ? - -Date: Fri Dec 6 01:11:34 EST 1996 - -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 do I register a domain" for a URL to these forms. - ------------------------------------------------------------------------------ - -Question 2.15. Is there a block of private IP addresses I can use? - -Date: Sun May 5 23:02:49 EDT 1996 - -Yes there is. Please refer to RFC 1918: - - 1918 Address Allocation for Private Internets. Y. Rekhter, B. - Moskowitz, D. Karrenberg, G. de Groot, & E. Lear. February 1996. - (Format: TXT=22270 bytes) - -RFC 1918 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 - ------------------------------------------------------------------------------ - -Question 2.16. Does BIND cache negative answers (failed DNS lookups) ? - -Date: Mon Jan 2 13:55:50 EST 1995 - -Yes, BIND 4.9.3 and more recent versions will cache negative answers. - ------------------------------------------------------------------------------ - -Question 2.17. What does an NS record really do ? - -Date: Wed Sep 4 22:52:18 EDT 1996 - -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. - -However, the NS records in the zone file of the parent domain are used to -find the right servers to query for the zone in question. These records -are more important than the records in the zone itself. - ------------------------------------------------------------------------------ - -Question 2.18. DNS ports - -Date: Fri Feb 10 15:40:10 EST 1995 - -The following table shows what TCP/UDP ports DNS uses to send and receive -queries: - - 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. - ------------------------------------------------------------------------------ - -Question 2.19. What is the cache file - -Date: Fri Dec 6 01:15:22 EST 1996 - -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. ... - ------------------------------------------------------------------------------ - -Question 2.20. Obtaining the latest cache file - -Date: Fri Dec 6 01:15:22 EST 1996 - -If you have a version of dig running, you may obtain the information with -the command - - dig @a.root-servers.net. . ns - -A perl script to handle some possible problems when using this method -from behind a firewall and that can also be used to periodically obtain -the latest cache file was posted to comp.protocols.tcp-ip.domains during -early October, 1996. It was posted with the subject "Keeping db.cache -current". It is available at -http://www.users.pfmc.net/~cdp/cptd-faq/current_db_cache.txt. - -The latest cache file may also be obtained from the InterNIC via ftp or -gopher: - - ; 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 - ------------------------------------------------------------------------------ - -Question 2.21. Selecting a nameserver/root cache - -Date: Mon Aug 5 22:54:11 EDT 1996 - -Exactly how is the a root server selected from the root cache? Does the -resolver attempt to pick the closest host or is it random or is it via -sortlist-type workings? If the root server selected is not available (for -whatever reason), will the the query fail instead of attempting another -root server in the list ? - -Every recursive BIND name server (that is, one which is willing to go out -and find something for you if you ask it something it doesn't know) will -remember the measured round trip time to each server it sends queries to. -If it has a choice of several servers for some domain (like "." for -example) it will use the one whose measured RTT is lowest. - -Since the measured RTT of all NS RRs starts at zero (0), every one gets -tried one time. Once all have responded, all RTT's will be nonzero, and -the "fastest server" will get all queries henceforth, until it slows down -for some reason. - -To promote dispersion and good recordkeeping, BIND will penalize the RTT -by a little bit each time a server is reused, and it will penalize the RTT -a _lot_ if it ever has to retransmit a query. For a server to stay "#1", -it has to keep on answering quickly and consistently. - -Note that this is something BIND does that the DNS Specification does not -mention at all. So other servers, those not based on BIND, might behave -very differently. - ------------------------------------------------------------------------------ - -Question 2.22. InterNIC and domain names - -Date: Sun Jun 2 11:23:49 EDT 1996 - -The current InterNIC policy on what to do if someone wants to use a domain -name that is already in use may be found at - -rs.internic.net : /policy/internic/internic-domain-4.txt - -or - -http://rs.internic.net/domain-info/internic-domain-4.html. - -The following information was submitted by Carl Oppedahl -<oppedahl@patents.com> : - -If the jealous party happens to have a trademark registration, it is quite -likely that the domain name owner will lose the domain name, even if they -aren't infringing the trademark. This presents a substantial risk of loss -of a domain name on only 30 days' notice. Anyone who is the manager of an -Internet-connected site should be aware of this risk and should plan for -it. - -See "How do I protect myself from loss of my domain name?" at -http://www.patents.com/weblaw.sht#domloss. - -For an example of an ISP's battle to keep its domain name, see -http://www.patents.com/nsi.sht. - -A compendium of information on the subject may be found at -http://www.law.georgetown.edu/lc/internic/domain1.html. - -=============================================================================== - -Section 3. UTILITIES - - Q3.1 Utilities to administer DNS zone files - Q3.2 DIG - Domain Internet Groper - Q3.3 DNS packet analyser - Q3.4 host - Q3.5 How can I use DNS information in my program? - Q3.6 A source of information relating to DNS - ------------------------------------------------------------------------------ - -Question 3.1. Utilities to administer DNS zone files - -Date: Wed Sep 4 22:53:53 EDT 1996 - -There are a few utilities available to ease the administration of zone -files in the DNS. - -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.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.cus.cam.ac.uk : /pub/software/programs/DNS/makezones - -More information may be found using the DNS Resources Directory - -http://www.dns.net/dnsrd/. - ------------------------------------------------------------------------------ - -Question 3.2. DIG - Domain Internet Groper - -Date: Thu Dec 1 11:09:11 EST 1994 - -The latest and greatest, official, accept-no-substitutes version of the -Domain Internet Groper (DiG) is the one that comes with BIND. Get the -latest kit. - ------------------------------------------------------------------------------ - -Question 3.3. DNS packet analyser - -Date: Wed Sep 4 23:43:57 EDT 1996 - -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 SimTel mirror site -should have the program available for anonymous ftp. One is - -ftp.coast.net : /SimTel/msdos/lan/ethld104.zip - ------------------------------------------------------------------------------ - -Question 3.4. host - -Date: Sun Dec 4 21:15:38 EST 1994 - -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.nikhef.nl : /pub/network/host.tar.Z - -It may also be found for anonymous ftp from - -ftp.uu.net : /networking/ip/dns/host.tar.Z - ------------------------------------------------------------------------------ - -Question 3.5. How can I use DNS information in my program? - -Date: Fri Feb 10 15:25:11 EST 1995 - -It depends on precisely what you want to do: - -* 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. -* If all you need is names and addresses, there will probably be system - routines 'gethostbyname' and 'gethostbyaddr' to provide this - information. -* 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 at - - hpux.csc.liv.ac.uk : /hpux/Networking/Admin/resparse-1.2 - ------------------------------------------------------------------------------ - -Question 3.6. A source of information relating to DNS - -Date: Tue Nov 5 23:42:21 EST 1996 - -You may find utilities and tools to help you manage your zone files -(including WWW front-ends) in the "tools" section of the DNS resources -directory: - -http://www.dns.net/dnsrd/tools.html - -There are also a number of IP management tools available. Data -Communications had an article on the subject in Sept/Oct of 1996. The -tools mentioned in the article and a few others may be found at the -following sites: - -* IP Address management, http://www.accugraph.com -* IP-Track, http://www.on.com -* NetID, http://www.isotro.com -* QIP, http://www.quadritek.com -* UName-It, http://www.esm.com - -=============================================================================== - -Section 4. DEFINITIONS - - Q4.1 TCP/IP Host Naming Conventions - Q4.2 What are slaves and forwarders ? - Q4.3 When is a server authoritative? - Q4.4 My server does not consider itself authoritative ! - Q4.5 NS records don't configure servers as authoritative ? - Q4.6 underscore in host-/domainnames - Q4.7 What is lame delegation ? - Q4.8 How can I see if the server is "lame" ? - Q4.9 What does opt-class field in a zone file do? - Q4.10 Top level domains - Q4.11 Classes of networks - Q4.12 What is CIDR ? - Q4.13 What is the rule for glue ? - ------------------------------------------------------------------------------ - -Question 4.1. TCP/IP Host Naming Conventions - -Date: Mon Aug 5 22:49:46 EDT 1996 - -One guide that may be used when naming hosts is RFC 1178, "Choosing a Name -for Your Computer", which is available via anonymous FTP from - -ftp.internic.net : /rfc/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. - ------------------------------------------------------------------------------ - -Question 4.2. What are slaves and forwarders ? - -Date: Thu Dec 1 10:32:43 EST 1994 - -"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). - ------------------------------------------------------------------------------ - -Question 4.3. When is a server authoritative? - -Date: Mon Jan 2 13:15:13 EST 1995 - -In the case of BIND: - -* The server contains current data in files for the zone in question (Data - must be current for secondaries, as defined in the SOA) -* The server is told that it is authoritative for the zone, by a 'primary' - or 'secondary' keyword in /etc/named.boot. -* The server does an error-free load of the zone. - ------------------------------------------------------------------------------ - -Question 4.4. My server does not consider itself authoritative ! - -Date: Mon Jan 2 13:15:13 EST 1995 - -The question was: - - What if I have set up a DNS where there is an SOA record for - the domain, but the server still does not consider itself - authoritative. (when using nslookup and set server=the correct machine.) - It seems 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. -With the answer: - - 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 the list in the - previous question). ------------------------------------------------------------------------------ - -Question 4.5. NS records don't configure servers as authoritative ? - -Date: Fri Dec 6 16:13:34 EST 1996 - -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") - ------------------------------------------------------------------------------ - -Question 4.6. underscore in host-/domainnames - -Date: Mon Aug 5 22:39:02 EDT 1996 - -The question is "Are 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? - -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 RFC 1035 isn't a -required standard. Therefore, RFC 1123 wins, no contest. - -From RFC 1123, Section 2.1 - - 2.1 Host Names and Numbers - - The syntax of a legal Internet host name was specified in RFC-952 - [DNS:4]. One aspect of host name syntax is hereby changed: the - restriction on the first character is relaxed to allow either a - letter or a digit. Host software MUST support this more liberal - syntax. - - And described by Dave Barr in RFC1912: - - Allowable characters in a label for a host name are only ASCII - letters, digits, and the `-' character. Labels may not be all - numbers, but may have a leading digit (e.g., 3com.com). Labels must - end and begin only with a letter or digit. See [RFC 1035] and [RFC - 1123]. (Labels were initially restricted in [RFC 1035] to start with - a letter, and some older hosts still reportedly have problems with - the relaxation in [RFC 1123].) Note there are some Internet - hostnames which violate this rule (411.org, 1776.com). - -Finally, one more piece of information (From Paul Vixie): - - RFC 1034 says only that domain names have characters in them, though it - says so with enough fancy and indirection that it's hard to tell exactly. - - Generally, for second level domains (i.e., something you would get from - InterNIC or from the US Domain Registrar and probably other ISO 3166 - country code TLDs), RFC 952 is thought to apply. RFC 952 was about host - names rather than domain names, but the rules seemed good enough. - - <domainname> ::= <hname> - - <hname> ::= <name>*["."<name>] - <name> ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>] - -There has been a recent update on this subject which may be found in - -ftp.internic.net : /internet-drafts/draft-andrews-dns-hostnames-03.txt. - ------------------------------------------------------------------------------ - -Question 4.7. What is lame delegation ? - -Date: Mon Aug 5 22:45:02 EDT 1996 - -Two things are required for a lame delegation: - -* A nameserver X is delegated as authoritative for a zone. -* 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. - ------------------------------------------------------------------------------ - -Question 4.8. How can I see if the server is "lame" ? - -Date: Mon Aug 5 22:45:02 EDT 1996 - -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 - -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'. - -The InterNIC recently announced a new lame delegation that will be in -effect on 01 October, 1996. Here is a summary: - -* After receipt/processing of a name registration template, and at random - intervals thereafter, the InterNIC will perform a DNS query via UDP - Port 53 on domain names for an SOA response for the name being - registered. -* If the query of the domain name returns a non-authoritative response - from all the listed name servers, the query will be repeated four times - over the next 30 days at random intervals approximately 7 days apart, - with notification to all listed whois and nameserver contacts of the - possible pending deletion. If at least one server answers correctly, - but one or more are lame, FYI notifications will be sent to all contacts - and checking will be discontinued. Additionally, e-mail notices will be - provided to the contact for the name servers holding the delegation to - alert them to the "lame" condition. Notifications will state explicitly - the consequences of not correcting the "lame" condition and will be - assigned a descriptive subject as follows: - - Subject: Lame Delegation Notice: DOMAIN_NAME - - The notification will include a timestamp for when the query was - performed. -* If, following 30 days, the name servers still provide no SOA response, - the name will be placed in a "hold" status and the DNS information will - no longer be propagated. The administrative contact will be notified by - postal mail and all whois contacts will be notified by e-mail, with - instructions for taking corrective action. -* Following 60 days in a "hold" status, the name will be deleted and made - available for reregistration. Notification of the final deletion will - be sent to the name server and domain name contacts listed in the NIC - database. - ------------------------------------------------------------------------------ - -Question 4.9. What does opt-class field in a zone file do? - -Date: Thu Dec 1 11:10:39 EST 1994 - -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. ------------------------------------------------------------------------------ - -Question 4.10. Top level domains - -Date: Fri Dec 6 15:13:35 EST 1996 - -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.isi.edu : /in-notes/iana/assignments/country-codes -* ftp.ripe.net : /iso3166-codes - -] - -[ Ed note: Since the Internic started charging for registration services, -(and for other reasons) there are a number of groups that want to offer -an alternative to registering a domain under a "standard" TLD. More -information on some of these options may be found at: - -* http://www.alternic.net/ -* http://www.eu.org/ -* http://www.ml.org/mljoin.html - -You may participate in one of the discussions on iTLD proposals at - -* To sign up: http://www.newdom.com/lists -* Old postings: http://www.newdom.com/archive - -] - ------ - - ... - 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 internic.net : /templates/us-domain-template.txt -* http://www.isi.edu/us-domain/ - -The application form for the EDU, COM, NET, ORG, and GOV domains may be -found for anonymous ftp from: - -internic.net : /templates/domain-template.txt - ------------------------------------------------------------------------------ - -Question 4.11. Classes of networks - -Date: Wed Sep 4 22:59:27 EDT 1996 - -The usage of 'classes of networks' (class A, B, C) are historical and have -been replaced by CIDR blocks on the Internet. That being said... - -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. - - # of # of - 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. - ------------------------------------------------------------------------------ - -Question 4.12. What is CIDR ? - -Date: Tue Nov 5 23:47:29 EST 1996 - -CIDR is "Classless Inter-Domain Routing (CIDR). From RFC 1517: - - ...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. - -Also please see the CIDR FAQ at - -* http://www.ibm.net.il/~hank/cidr.html -* http://www.rain.net/faqs/cidr.faq.html -* http://www.lab.unisource.ch/services/internet/direct/cidr.html - ------------------------------------------------------------------------------ - -Question 4.13. What is the rule for glue ? - -Date: Fri Apr 28 13:31:24 EDT 1995 - -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. - - -The remainder of the FAQ is in the next part (Part 2 of 2). - diff --git a/contrib/bind/doc/misc/FAQ.2of2 b/contrib/bind/doc/misc/FAQ.2of2 deleted file mode 100644 index 40e16494b5bf..000000000000 --- a/contrib/bind/doc/misc/FAQ.2of2 +++ /dev/null @@ -1,1298 +0,0 @@ -Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers -Path: vixie!news1.digital.com!su-news-hub1.bbnplanet.com!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.mathworks.com!news.kei.com!uhog.mit.edu!rutgers!njitgw.njit.edu!hertz.njit.edu!cdp2582 -From: cdp2582@hertz.njit.edu (Chris Peckham) -Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2) -Message-ID: <cptd-faq-2-849940949@njit.edu> -Followup-To: comp.protocols.tcp-ip.domains -Originator: cdp2582@hertz.njit.edu -Keywords: BIND,DOMAIN,DNS -Sender: news@njit.edu -Supersedes: <cptd-faq-2-847336183@njit.edu> -Nntp-Posting-Host: hertz.njit.edu -X-Posting-Frequency: posted during the first week of each month -Reply-To: domain-faq@njit.edu (comp.protocols.tcp-ip.domains FAQ comments) -Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA -References: <cptd-faq-1-849940949@njit.edu> -Date: Sat, 7 Dec 1996 06:42:49 GMT -Approved: news-answers-request@MIT.EDU -Expires: Sat 11 Jan 97 02:42:29 EDT -Lines: 1277 -Xref: vixie comp.protocols.tcp-ip.domains:12905 comp.answers:22441 news.answers:85683 - -Posted-By: auto-faq 3.1.1.2 -Archive-name: internet/tcp-ip/domains-faq/part2 -Revision: 1.13 1996/12/07 06:42:15 - - -(Continued from Part 1, where you'll find the introduction and -table of contents.) - - -=============================================================================== - -Section 5. CONFIGURATION - - Q5.1 Changing a Secondary server to a Primary server ? - Q5.2 Moving a Primary server to another server - Q5.3 How do I subnet a Class B Address ? - Q5.4 Subnetted domain name service - Q5.5 Recommended format/style of DNS files - Q5.6 DNS on a system not connected to the Internet - Q5.7 Multiple Domain configuration - Q5.8 wildcard MX records - Q5.9 How do you identify a wildcard MX record ? - Q5.10 Why are fully qualified domain names recommended ? - Q5.11 Distributing load using named - Q5.12 Order of returned records - Q5.13 resolv.conf - Q5.14 How do I delegate authority for sub-domains ? - Q5.15 DNS instead of NIS on a Sun OS 4.1.x system - Q5.16 Patches to add functionality to BIND - Q5.17 How to serve multiple domains from one server - ------------------------------------------------------------------------------ - -Question 5.1. Changing a Secondary server to a Primary server ? - -Date: Fri Jul 5 23:54:35 EDT 1996 - -For 4.8.3, it's prudent to kill and restart following any changes to -named.boot. - -In BIND 4.9.3, you only have to kill and restart named if you change a -primary zone to a secondary or v-v, or if you delete a zone and remain -authoritative for its parent. Every other case should be taken care of by -a HUP. (Ed. note: 4.9.3b9 may still require you to kill and restart the -server due to some bugs in the HUP code). - -You will also need to update the server information on the root servers. -You can do this by filing a new domain registration form to inform -InterNIC of the change. They will then update the root server's SOA -records. This process usually takes 10-12 business days after they -receive the request. - ------------------------------------------------------------------------------ - -Question 5.2. Moving a Primary server to another server - -Date: Fri Jul 5 23:54:35 EDT 1996 - -The usual solution is to move the primary to ns.newserver.com, and have -ns.oldserver.com be configured as a secondary server until the change to -the root servers takes place after the request has been made to the -InterNIC. - -If you are moving to a different ISP which will change your IP's, the -recommened setting for the SOA that would minimize problems for your name -servers using the old settings can be done as follows: - -Gradually lower the TTL value in your SOA (that's the last one of the five -numbers) to always be equal to the time left until you change over. -(assuming that none of your resource records have individual TTL's set, if -so, do likewise witht them.) So, the day before, lower to 43200 seconds -(12 hours). Then lower every few hours to be the time remaining until -the change-over. So, an hour before the change, you may just want to -lower it all the way to 60 seconds or so. That way no one can cache -information past the change-over. - -After the change, start gradually incrementing the TTL value, because -you'll probably be making changes to work out problems. Once everything -stabilizes, move the TTL up to whatever your normal values are. - -To minimize name servers from using the "old settings", you can do the -same thing with the "refresh" interval in the SOA (the second number of -the SOA). That will tell the secondaries to refresh every X seconds. -Lower that value as you approach the changeover date. You probably don't -want to go much below an hour or you'll start the primary thrashing as all -the secondaries perpetually refresh. - -Also see the answer to the "How can I change the IP address of our server -?" in the INTRODUCTION section. - ------------------------------------------------------------------------------ - -Question 5.3. How do I subnet a Class B Address ? - -Date: Fri Apr 28 13:34:52 EDT 1995 - -That you need to subnet at all is something of a misconception. You can -also think of a class B network as giving you 65,534 individual hosts, and -such a network will work. You can also configure your class B as 16,384 -networks of 2 hosts each. That's obviously not very practical, but it -needs to be made clear that you are not constrained by the size of an -octet (remember that many older devices would not work in a network -configured in this manner). - -So, the question is: why do you need to subnet? One reason is that it is -easier to manage a subnetted network, and in fact, you can delegate the -responsibility for address space management to local administrators on the -various subnets. Also, IP based problems will end up localized rather -than affecting your entire network. - -If your network is a large backbone with numerous segments individually -branching off the backbone, that too suggests subnetting. - -Subnetting can also be used to improve routing conditions. - -You may wish to partition your network to disallow certain protocols on -certain segments of your net. You can, for example, restrict IP or IPX to -certain segments only by adding a router routing high level protocols, -and across the router you may have to subnet. - -Finally, as far as how many subnets you need depends on the answer to the -above question. As far as subnet masks are concerned, the mask can be -anything from 255.0.0.0 to 255.255.255.252. You'll probably be looking at -9 or 10 bits for the subnet (last octet 128 or 192 respectively). RFC -1219 discusses the issue of subnetting very well and leaves the network -administrator with a large amount of flexibility for future growth. - ------------------------------------------------------------------------------ - -Question 5.4. Subnetted domain name service - -Date: Mon Aug 5 23:00:16 EDT 1996 - -If you are looking for some examples of handling subnetted class C -networks as separate DNS domains, see the Internet Draft - -draft-ietf-cidrd-classless-inaddr-02.txt - -for more information. This file is available for anonymous ftp at - -ds.internic.net : -/internet-drafts/draft-ietf-cidrd-classless-inaddr-02.txt - -or other IETF mirror sites (ftp.is.ca.za [Africa], nic.nordu.net [Europe], -munnari.oz.au [Pacific Rim], ds.internic.net [US East Coast], or -ftp.isi.edu [US West Coast]). - -Details follow- You need to delegate down to the fourth octet, so you will -have one domain per IP address ! Here is how you can subdelegate a -in-addr.arpa address for non-byte aligned subnet masks: - -Take as an example the net 192.1.1.x, and example subnet mask -255.255.255.240. - -We first define the domain for the class C net, - - $origin 1.1.192.in-addr.arpa - @ SOA (usual stuff) - @ ns some.nameserver - ns some.other.nameserver - ; delegate a subdomain - one ns one.nameserver - ns some.nameserver - ; delegate another - two ns two.nameserver - ns some.nameserver - ; CNAME pointers to subdomain one - 0 CNAME 0.one - 1 CNAME 1.one - ; through - 15 CNAME 15.one - ; CNAME pointers to subdomain two - 16 CNAME 16.two - 17 CNAME 17.two - 31 CNAME 31.two - ; CNAME as many as required. - -Now, in the delegated nameserver, one.nameserver - - $origin one.1.1.192.in-addr.arpa - @ SOA (usual stuff) - NS one.nameserver - NS some.nameserver ; secondary for us - 0 PTR onenet.one.domain - 1 PTR onehost.one.domain - ; through - 15 PTR lasthost.one.domain - -And similar for the two.1.1.192.in-addr.arpa delegated domain. - -There is additional documentation and a perl script that may be used for -this purpose available for anonymous ftp from: - -ftp.vix.com : /pub/bind/contrib/gencidrzone - ------------------------------------------------------------------------------ - -Question 5.5. Recommended format/style of DNS files - -Date: Sun Nov 27 23:32:41 EST 1994 - -This answer is quoted from an article posted by Paul Vixie: - - I've gone back and forth on the question of whether the BOG should - include a section on this topic. I know what I myself prefer, but - I'm wary of ramming my own stylistic preferences down the throat of - every BOG reader. But since you ask :-)... - - Create /var/named. If your system is too old to have a /var, either - create one or use /usr/local/adm/named instead. Put your named.boot - in it, and make /etc/named.boot a symlink to it. If your system - doesn't have symlinks, you're S-O-L (but you knew that). In - named.boot, put a "directory" directive that specifies your actual - BIND working directory: - - directory /var/named - - All relative pathnames used in "primary", "secondary", and "cache" - directives will be evaluated relative to this directory. Create two - subdirectories, /var/named/pri and /var/named/sec. Whenever you add - a "primary" directive to your named.boot, use "pri/WHATEVER" as the - path name. And then put the primary zone file into "pri/WHATEVER". - Likewise when you add "secondary" directives, use "sec/WHATEVER" and - BIND (really named-xfer) will create the files in that - subdirectory. - - (Variations: (1) make a midlevel directory "zones" and put "pri" and - "sec" into it; (2) if you tend to pick up a lot of secondaries from - a few hosts, group them together in their own subdirectories -- - something like /var/named/zones/uucp if you're a UUCP Project name - server.) - - For your forward files, name them after the zone. dec.com becomes - "/var/named/zones/pri/dec.com". For your reverse files, name them - after the network number. 0.1.16.in-addr.arpa becomes - "/var/named/zones/pri/16.1.0". - - When creating or maintaining primary zone files, try to use the same - SOA values everywhere, except for the serial number which varies per - zone. Put a $ORIGIN directive at the top of the primary zone file, - not because its needed (it's not since the default origin is the - zone named in the "primary" directive) but because it make it easier - to remember what you're working on when you have a lot of primary - zones. Put some comments up there indicating contact information - for the real owner if you're proxying. Use RCS and put the "Id" - in a ";" comment near the top of the zone file. - - The SOA and other top level information should all be listed - together. But don't put IN on every line, it defaults nicely. For - example: - -============== -@ IN SOA gw.home.vix.com. postmaster.vix.com. ( - 1994082501 ; serial - 3600 ; refresh (1 hour) - 1800 ; retry (30 mins) - 604800 ; expire (7 days) - 3600 ) ; minimum (1 hour) - - NS gw.home.vix.com. - NS ns.uu.net. - NS uucp-gw-1.pa.dec.com. - NS uucp-gw-2.pa.dec.com. - - MX 10 gw.home.vix.com. - MX 20 uucp-gw-1.pa.dec.com. - MX 20 uucp-gw-1.pa.dec.com. -============== - - I don't necessarily recommend those SOA values. Not every zone is - as volatile as the example shown. I do recommend that serial number - format; it's in date format with a 2-digit per-day revision number. - This format will last us until 2147 A.D. at which point I expect a - better solution will have been found :-). (Note that it would last - until 4294 A.D. except that there are some old BINDs out there that - use a signed quantity for representing serial number interally; I - suppose that as long as none of these are still running after 2047 - A.D., that we can use the above serial number format until 4294 - A.D., at which point a better solution will HAVE to be found.) - - You'll note that I use a tab stop for "IN" even though I never again - specify it. This leaves room for names longer than 7 bytes without - messing up the columns. You might also note that I've put the MX - priority and destination in the same tab stop; this is because both - are part of the RRdata and both are very different from MX which is - an RRtype. Some folks seem to prefer to group "MX" and the priority - together in one tab stop. While this looks neat it's very confusing - to newcomers and for them it violates the law of least - astonishment. - - If you have a multi-level zone (one which contains names that have - dots in them), you can use additional $ORIGIN statements but I - recommend against it since there is no "back" operator. That is, - given the above example you can add: - -============= -$ORIGIN home -gw A 192.5.5.1 -============= - - The problem with this is that subsequent RR's had better be - somewhere under the "home.vix.com" name or else the $ORIGIN that - introduces them will have to use a fully qualified name. FQDN - $ORIGIN's aren't bad and I won't be mad if you use them. - Unqualified ones as shown above are real trouble. I usually stay - away from them and just put the whole name in: - -============= -gw.home A 192.5.5.1 -============= - - In your reverse zones, you're usually in some good luck because the - owner name is usually a single short token or sometimes two. - -============= -$ORIGIN 5.5.192.in-addr.arpa. -@ IN SOA ... - NS ... -1 PTR gw.home.vix.com. -========================================= -$ORIGIN 1.16.in-addr.arpa. -@ IN SOA ... - NS ... -2.0 PTR gatekeeper.dec.com. -============= - - It is usually pretty hard to keep your forward and reverse zones in - synch. You can avoid that whole problem by just using "h2n" (see - the ORA book, DNS and BIND, and its sample toolkit, included in the - BIND distribution or on ftp.uu.net (use the QUOTE SITE EXEC INDEX - command there to find this -- I never can remember where it's at). - "h2n" and many tools like it can just read your old /etc/hosts file - and churn it into DNS zone files. (May I recommend - contrib/decwrl/mkdb.pl from the BIND distribution?) However, if you - (like me) prefer to edit these things by hand, you need to follow - the simple convention of making all of your holes consistent. If - you use 192.5.5.1 and 192.5.5.3 but not (yet) 192.5.5.2, then in - your forward file you will have something like - -============= -... -gw.home A 192.5.5.1 -;avail A 192.5.5.2 -pc.home A 192.5.5.3 -============= - - and in your reverse file you will have something like - -============= -... -1 PTR gw.home.vix.com. -;2 PTR avail -3 PTR pc.home.vix.com. -============= - - This convention will allow you to keep your sanity and make fewer - errors. Any kind of automation (h2n, mkdb, or your own - perl/tcl/awk/python tools) will help you maintain a consistent - universe even if it's also a complex one. Editing by hand doesn't - have to be deadly but you MUST take care. - ------------------------------------------------------------------------------ - -Question 5.6. DNS on a system not connected to the Internet - -Date: Sun Nov 27 23:32:41 EST 1994 - -You need to create your own root domain name server until you connect to -the internet. Your roots need to delegate to mydomain.com and any -in-addr.arpa subdomains you might have, and that's about it. As soon as -you're connected, rip out the fake roots and use the real ones. - -It does not actually have to be another server pretending to be the root. -You can set up the name server so that it is primary for each domain above -you and leave them empty (i.e. you are foo.bar.com - claim to be primary -for bar.com and com) - -If you connect intermittently and want DNS to work when you are connected, -and "fail" when you are not, you can point the resolver at the name server -at the remote site and if the connection (SLIP/PPP) isn't up, the resolver -doesn't have a route to the remote server and since there's only one name -server in resolv.conf, the resolver quickly backs off the using -/etc/hosts. No problem. You could do the same with multiple name server -and a resolver that did configurable /etc/hosts fallback. - ------------------------------------------------------------------------------ - -Question 5.7. Multiple Domain configuration - -Date: Fri Dec 2 15:40:49 EST 1994 - -If you want to have multiple domain names pointing to the same -destination, such as: - - ftp ftp.biff.com connects user to -> ftp.biff.com - ftp ftp.fred.com connects user to -> ftp.biff.com - ftp ftp.bowser.com connects user to -> ftp.biff.com - -You may do this by using CNAMEs: - - ftp.bowser.com. IN CNAME ftp.biff.com. - -You can also do the same thing with multiple A records. - ------------------------------------------------------------------------------ - -Question 5.8. wildcard MX records - -Date: Sun Nov 27 23:32:41 EST 1994 - -Does BIND not understand wildcard MX records such as the following? - - *.foo.com MX 0 mail.foo.com. - -No. It just doesn't work. - -Explicit RR's at one level of specificity will, by design, "block" a -wildcard at a lesser level of specificity. I suspect that you have an RR -(an A RR, perhaps?) for "bar.foo.com" which is blocking the application of -your "*.foo.com" wildcard. The initial MX query is thus failing (NOERROR -but an answer count of 0), and the backup query finds the A RR for -"bar.foo.com" and uses it to deliver the mail directly (which is what you -DIDN'T want it to do). Adding an explicit MX RR for the host is therefore -the right way to handle this situation. - -See RFC 1034, Section 4.3.3 ("Wildcards") for more information on this -"blocking" behavior, along with an illustrative example. See also RFC 974 -for an explanation of standard mailer behavior in the face of an "empty" -response to one's MX query. - -Basically, what it boils down to is, there is no point in trying to use a -wildcard MX for a host which is otherwise listed in the DNS. - -It just doesn't work. - ------------------------------------------------------------------------------ - -Question 5.9. How do you identify a wildcard MX record ? - -Date: Thu Dec 1 11:10:39 EST 1994 - -You don't really need to "identify" a wildcard MX RR. The precedence for -u@dom is: - - exact match MX - exact match A - wildcard MX - -One way to implement this is to query for ("dom",IN,MX) and if the answer -name that comes back is "*." something, you know it's a wildcard, -therefore you know there is no exact match MX, and you therefore query for -("dom",IN,A) and if you get something, use it. if you don't, use the -previous wildcard response. - -RFC 974 explains this pretty well. - ------------------------------------------------------------------------------ - -Question 5.10. Why are fully qualified domain names recommended ? - -Date: Sun Nov 27 23:32:41 EST 1994 - -The documentation for BIND 4.9.2 says that the hostname should be set to -the full domain style name (i.e host.our.domain rather than host). What -advantages are there in this, and are there any adverse consequences if we -don't? - -Paul Vixie likes to do it :-) He lists a few reasons - - -* Sendmail can be configured to just use Dj$w rather than Dj$w.mumble - where "mumble" is something you have to edit in by hand. Granted, most - people use "mumble" elsewhere in their config files ("tack on local - domain", etc) but why should it be a requirement ? -* The real reason is that not doing it violates a very useful invariant: - gethostbyname(gethostname) == gethostbyaddr(primary_interface_address) - - If you take an address and go "backwards" through the PTR's with it, - you'll get a FQDN, and if you push that back through the A RR's, you get - the same address. Or you should. Many multi-homed hosts violate this - uncaringly. - - If you take a non-FQDN hostname and push it "forwards" through the A - RR's, you get an address which, if you push it through the PTR's, comes - back as a FQDN which is not the same as the hostname you started with. - Consider the fact that, absent NIS/YP, there is no "domainname" command - analogous to the "hostname" command. (NIS/YP's doesn't count, of - course, since it's sometimes-but-only-rarely the same as the Internet - domain or subdomain above a given host's name.) The "domain" keyword in - resolv.conf doesn't specify the parent domain of the current host; it - specifies the default domain of queries initiated on the current host, - which can be a very different thing. (As of RFC 1535 and BIND 4.9.2's - compliance with it, most people use "search" in resolv.conf, which - overrides "domain", anyway.) - - What this means is that there is NO authoritative way to - programmatically discover your host's FQDN unless it is set in the - hostname, or unless every application is willing to grovel the "netstat - -in" tables, find what it hopes is the primary address, and do a PTR - query on it. - - FQDN /bin/hostnames are, intuitively or not, the simplest way to go. - ------------------------------------------------------------------------------ - -Question 5.11. Distributing load using named - -Date: Wed Mar 1 11:04:43 EST 1995 - -When you attempt to distribute the load on a system using named, the first -response be cached, and then later queries use the cached value (This -would be for requests that come through the same server). Therefore, it -can be useful to use a lower TTL on records where this is important. You -can use values like 300 or 500 seconds. - -If your local caching server has ROUND_ROBIN, it does not matter what the -authoritative servers have -- every response from the cache is rotated. - -But if it doesn't, and the authoritative server site is depending on this -feature (or the old "shuffle-A") to do load balancing, then if one doesn't -use small TTLs, one could conceivably end up with a really nasty -situation, e.g., hundreds of workstations at a branch campus pounding on -the same front end at the authoritative server's site during class -registration. - -Not nice. - -Paul Vixie has an example of the ROUND_ROBIN code in action. Here is -something that he wrote regarding his example: - - >I want users to be distributed evenly among those 3 hosts. - - Believe it or not :-), BIND offers an ugly way to do this. I offer - for your collective amusement the following snippet from the - ugly.vix.com zone file: - - hydra cname hydra1 - cname hydra2 - cname hydra3 - hydra1 a 10.1.0.1 - a 10.1.0.2 - a 10.1.0.3 - hydra2 a 10.2.0.1 - a 10.2.0.2 - a 10.2.0.3 - hydra3 a 10.3.0.1 - a 10.3.0.2 - a 10.3.0.3 - - Note that having multiple CNAME RR's at a given name is - meaningless according to the DNS RFCs but BIND doesn't mind (in - fact it doesn't even complain). If you call - gethostbyname("hydra.ugly.vix.com") (try it!) you will get - results like the following. Note that there are two round robin - rotations going on: one at ("hydra",CNAME) and one at each - ("hydra1",A) et al. I used a layer of CNAME's above the layer of - A's to keep the response size down. If you don't have nine - addresses you probably don't care and would just use a pile of - CNAME's pointing directly at real host names. - - {hydra.ugly.vix.com - name: hydra2.ugly.vix.com - aliases: hydra.ugly.vix.com - addresses: 10.2.0.2 10.2.0.3 10.2.0.1 - - {hydra.ugly.vix.com - name: hydra3.ugly.vix.com - aliases: hydra.ugly.vix.com - addresses: 10.3.0.2 10.3.0.3 10.3.0.1 - - {hydra.ugly.vix.com - name: hydra1.ugly.vix.com - aliases: hydra.ugly.vix.com - addresses: 10.1.0.2 10.1.0.3 10.1.0.1 - - {hydra.ugly.vix.com - name: hydra2.ugly.vix.com - aliases: hydra.ugly.vix.com - addresses: 10.2.0.3 10.2.0.1 10.2.0.2 - - {hydra.ugly.vix.com - name: hydra3.ugly.vix.com - aliases: hydra.ugly.vix.com - addresses: 10.3.0.3 10.3.0.1 10.3.0.2 - ------------------------------------------------------------------------------ - -Question 5.12. Order of returned records - -Sorting, is the *resolver's* responsibility. RFC 1123: - - - 6.1.3.4 Multihomed Hosts - - When the host name-to-address function encounters a host - with multiple addresses, it SHOULD rank or sort the - addresses using knowledge of the immediately connected - network number(s) and any other applicable performance or - history information. - - DISCUSSION: - The different addresses of a multihomed host generally - imply different Internet paths, and some paths may be - preferable to others in performance, reliability, or - administrative restrictions. There is no general way - for the domain system to determine the best path. A - recommended approach is to base this decision on local - configuration information set by the system - administrator. - -In BIND 4.9.x's resolver code, the "sortlist" directive in resolv.conf -can be used to configure this. - ------------------------------------------------------------------------------ - -Question 5.13. resolv.conf - -Date: Fri Feb 10 15:46:17 EST 1995 - -The question was asked one time, "Why should I use 'real' IP addresses in -/etc/resolv.conf and not 0.0.0.0 or 127.0.0.1" ? - -Paul Vixie writes on the issue of the contents of resolv.conf: - - It's historical. Some kernels can't unbind a UDP socket's source - address, and some resolver versions (notably not including BIND - 4.9.2 or 4.9.3's) try to do this. The result can be wide area - network traffic with 127.0.0.1 as the source address. Rather than - giving out a long and detailed map of version/vendor combinations of - kernels/BINDs that have/don't this problem, I just tell folks not to - use 127.0.0.1 at all. - - 0.0.0.0 is just an alias for the first interface address assigned - after a system boot, and if that interface is a up-and-down point to - point link (PPP, SLIP, whatever), there's no guarantee that you'll - be able to reach yourself via 0.0.0.0 during the entire lifetime of - any system instance. On most kernels you can finesse this by adding - static routes to 127.0.0.1 for each of your interface addresses, but - some kernels don't like that trick and rather than give a detailed - map of which ones work and which ones don't, I just globally - recommend against 0.0.0.0. - - If you know enough to know that 127.0.0.1 or 0.0.0.0 is safe on your - kernel and resolver, then feel free to use them. If you don't know - for sure that it is safe, don't use them. I never use them (except - on my laptop, whose hostname is "localhost" and whose 0.0.0.0 is - 127.0.0.1 since I ifconfig my lo0 before any other interface). The - operational advantage to using a real IP address rather than an - wormhole like 0.0.0.0 or 127.0.0.1, is that you can then "rdist" or - otherwise share identical copies of your resolv.conf on all the - systems on any given subnet, not all of which will be servers. - -The problem was with older versions of the resolver (4.8.X). If you -listed 127.0.0.1 as the first entry in resolv.conf, and for whatever -reason the local name server wasn't running and the resolver fell back to -the second name server listed, it would send queries to the name server -with the source IP address set to 127.0.0.1 (as it was set when the -resolver was trying to send to 127.0.0.1--you use the loopback address to -send to the loopback address). - ------------------------------------------------------------------------------ - -Question 5.14. How do I delegate authority for sub-domains ? - -Date: Sat Dec 7 02:04:17 EST 1996 - -When you start having a very big domain that can be broken into logical -and separate entities that can look after their own DNS information, you -will probably want to do this. Maintain a central area for the things -that everyone needs to see and delegate the authority for the other parts -of the organization so that they can manage themselves. - -Another essential piece of information is that every domain that exists -must have it NS records associated with it. These NS records denote the -name servers that are queried for information about that zone. For your -zone to be recognized by the outside world, the server responsible for the -zone above you must have created a NS record for your your new servers -(NOTE that the new servers DO NOT have to be in the new domain). For -example, putting the computer club onto the network and giving them -control over their own part of the domain space we have the following. - -The machine authorative for gu.uwa.edu.au is mackerel and the machine -authorative for ucc.gu.uwa.edu.au is marlin. - -in mackerel's data for gu.uwa.edu.au we have the following - - @ IN SOA ... - IN A 130.95.100.3 - IN MX mackerel.gu.uwa.edu.au. - IN MX uniwa.uwa.edu.au. - - marlin IN A 130.95.100.4 - - ucc IN NS marlin.gu.uwa.edu.au. - IN NS mackerel.gu.uwa.edu.au. - -Marlin is also given an IP in our domain as a convenience. If they blow -up their name serving there is less that can go wrong because people can -still see that machine which is a start. You could place "marlin.ucc" in -the first column and leave the machine totally inside the ucc domain as -well. - -The second NS line is because mackerel will be acting as secondary name -server for the ucc.gu domain. Do not include this line if you are not -authorative for the information included in the sub-domain. - ------------------------------------------------------------------------------ - -Question 5.15. DNS instead of NIS on a Sun OS 4.1.x system - -Date: Sat Dec 7 01:14:17 EST 1996 - -Comments relating to running bind 4.9.x on a Sun OS 4.1.x system and the -effect on sendmail, ftp, telnet and other TCP/IP services bypassing NIS -and directly using named is documented quite well in the -comp.sys.sun.admin FAQ in questions one and two. You can get them from: - -* ftp.ece.uc.edu : /pub/sun-faq/FAQs/sun-faq.general -* http://www.cis.ohio-state.edu/hypertext/faq/usenet/comp-sys-sun-faq - -as well as from rtfm.mit.edu in the usual place, etc. - ------------------------------------------------------------------------------ - -Question 5.16. Patches to add functionality to BIND - -Date: Tue Nov 5 23:53:47 EST 1996 - -There are others, but these are listed here: - -* When using the round robin DNS and assigning 3 IPs to a host (for - example), a process to guarantee that all 3 IPs are reachable may be - found at - http://www-leland.stanford.edu/~schemers/docs/lbnamed/lbnamed.html - -* Patches for 4.9.3-REL that will support the IPv6 AAAA record format may - be found at ftp.inria.fr : /network/ipv6/ - -* A patch for 4.9.3-REL that will allow you to turn off forwarding of - information from my server may be found at ftp.vix.com : - /pub/bind/release/4.9.3/contrib/noforward.tar.gz - -* How do I tell a server to listen to a particular interface to listen and - respond to DNS queries on ? - - Mark Andrews has a patch that will tell a 4.9.4 server to listen to a - particular interface and respond to DNS queries. It may be found at an - unofficial location: http://www.ultra.net/~jzp/andrews.patch.txt - ------------------------------------------------------------------------------ - -Question 5.17. How to serve multiple domains from one server - -Date: Tue Nov 5 23:44:02 EST 1996 - -Most name server implementations allow information about multiple domains -to be kept on one server, and questions about those domains to be -answered by that one server. For instance, there are many large servers -on the Internet that each serve information about more than 1000 -different domains. - -To be completely accurate, a server contains information about zones, -which are parts of domains that are kept as a single unit. [Ed note: for -a definition of zones and domains, see Section 2: The Name Service in the -"Name Server Operations Guide" included with the BIND 4.9.5 distribution.] - -In the configuration of the name server, the additional zones need to be -specified. An important consideration is whether a particular server is -primary or secondary for any specific zone--a secondary server maintains -only a copy of the zone, periodically refreshing its copy from another, -specified, server. In BIND, to set up a server as a secondary server for -the x.y.z zone, to the configuration file /etc/named.boot add the line - - secondary x.y.z 10.0.0.1 db.x.y.z - -where 10.0.0.1 is the IP address of the server that the zone will be -copied from, and db.x.y.z is a local filename that will contain the copy -of the zone. - -If this is a question related to how to set up multiple IP numbers on one -system, which you do not need to do to act as a domain server for -multiple domains, see - -http://www.thesphere.com/%7Edlp/TwoServers/. - -=============================================================================== - -Section 6. PROBLEMS - - Q6.1 No address for root server - Q6.2 Error - No Root Nameservers for Class XX - Q6.3 Bind 4.9.x and MX querying? - Q6.4 Do I need to define an A record for localhost ? - Q6.5 MX records, CNAMES and A records for MX targets - Q6.6 Can an NS record point to a CNAME ? - Q6.7 Nameserver forgets own A record - Q6.8 General problems (core dumps !) - Q6.9 malloc and DECstations - Q6.10 Can't resolve names without a "." - Q6.11 Err/TO errors being reported - Q6.12 Why does swapping kill BIND ? - ------------------------------------------------------------------------------ - -Question 6.1. No address for root server - -Date: Mon Jan 2 13:49:43 EST 1995 - -Q: I've been getting the following messages lately from bind-4.9.2.. - ns_req: no address for root server - -We are behind a firewall and have the following for our named.cache file - - - ; list of servers - . 99999999 IN NS POBOX.FOOBAR.COM. - 99999999 IN NS FOOHOST.FOOBAR.COM. - foobar.com. 99999999 IN NS pobox.foobar.com. -You can't do that. Your nameserver contacts POBOX.FOOBAR.COM, gets the -correct list of root servers from it, then tries again and fails because -of your firewall. - -You will need a 'forwarder' definition, to ensure that all requests are -forwarded to a host which can penetrate the firewall. And it is unwise to -put phony data into 'named.cache'. - ------------------------------------------------------------------------------ - -Question 6.2. Error - No Root Nameservers for Class XX - -Date: Sun Nov 27 23:32:41 EST 1994 - -Q: I've received errors before about "No root nameservers for class XX" - but they've been because of network connectivity problems. - I believe that Class 1 is Internet Class data. - And I think I heard someone say that Class 4 is Hesiod?? - Does anyone know what the various Class numbers are? -From RFC 1700: - - DOMAIN NAME SYSTEM PARAMETERS - The Internet Domain Naming System (DOMAIN) includes several - parameters. These are documented in [RFC1034] and [RFC1035]. The - CLASS parameter is listed here. The per CLASS parameters are - defined in separate RFCs as indicated. - - Domain System Parameters: - - Decimal Name References - -------- ---- ---------- - 0 Reserved [PM1] - 1 Internet (IN) [RFC1034,PM1] - 2 Unassigned [PM1] - 3 Chaos (CH) [PM1] - 4 Hesoid (HS) [PM1] - 5-65534 Unassigned [PM1] - 65535 Reserved [PM1] - -DNS information for RFC 1700 was taken from -ftp.isi.edu : /in-notes/iana/assignments/dns-parameters - -Hesiod is class 4, and there are no official root nameservers for class 4, -so you can safely declare yourself one if you like. You might want to -put up a packet filter so that no one outside your network is capable of -making Hesiod queries of your machines, if you define yourself to be a -root nameserver for class 4. - ------------------------------------------------------------------------------ - -Question 6.3. Bind 4.9.x and MX querying? - -Date: Sun Nov 27 23:32:41 EST 1994 - -If you query a 4.9.x DNS server for MX records, a list of the MX records -as well as a list of the authorative nameservers is returned. This -happens because bind 4.9.2 returns the list of nameserver that are -authorative for a domain in the response packet, along with their IP -addresses in the additional section. - ------------------------------------------------------------------------------ - -Question 6.4. Do I need to define an A record for localhost ? - -Date: Sat Sep 9 00:36:01 EDT 1995 - -Somewhere deep in the BOG (BIND Operations Guide) that came with 4.9.3 -(section 5.4.3), it says that you define this yourself (if need be) in -the same zone files as your "real" IP addresses for your domain. Quoting -the BOG: - - - ... As implied by this PTR - record, there should be a ``localhost.my.dom.ain'' - A record (with address 127.0.0.1) in every domain - that contains hosts. ``localhost.'' will lose its - trailing dot when 1.0.0.127.in-addr.arpa is queried - for;... - -The sample files in the BIND distribution show you what needs to be done -(see the BOG). - -Some HP boxen (especially those running HP OpenView) will also need -"loopback" defined with this IP address. You may set it as a CNAME -record pointing to the "localhost." record. - ------------------------------------------------------------------------------ - -Question 6.5. MX records, CNAMES and A records for MX targets - -Date: Sun Nov 27 23:32:41 EST 1994 - -The O'Reilly "DNS and Bind" book warns against using non-canonical names -in MX records, however, this warning is given in the context of mail hubs -that MX to each other for backup purposes. How does this apply to mail -spokes. RFC 974 has a similar warning, but where is it specifically -prohibited to us an alias in an MX record ? - -Without the restrictions in the RFC, a MTA must request the A records for -every MX listed to determine if it is in the MX list then reduce the list. -This introduces many more lookups than would other wise be required. If -you are behind a 1200 bps link YOU DON'T WANT TO DO THIS. The addresses -associated with CNAMES are not passed as additional data so you will force -additional traffic to result even if you are running a caching server -locally. - -There is also the problem of how does the MTA find all of it's IP -addresses. This is not straight forward. You have to be able to do this is -you allow CNAMEs (or extra A's) as MX targets. - -The letter of the law is that an MX record should point to an A record. - -There is no "real" reason to use CNAMEs for MX targets or separate As for -nameservers any more. CNAMEs for services other than mail should be used -because there is no specified method for locating the desired server yet. - -People don't care what the names of MX targets are. They're invisible to -the process anyway. If you have mail for "mary" redirected to "sue" is -totally irrelevant. Having CNAMEs as the targets of MX's just needlessly -complicates things, and is more work for the resolver. - -Having separate A's for nameservers like "ns.your.domain" is pointless -too, since again nobody cares what the name of your nameserver is, since -that too is invisible to the process. If you move your nameserver from -"mary.your.domain" to "sue.your.domain" nobody need care except you and -your parent domain administrator (and the InterNIC). Even less so for -mail servers, since only you are affected. - -Q: Given the example - - - hello in cname realname - mailx in mx 0 hello - - Now, while reading the operating manual of bind it clearly states - that this is *not* valid. These two statements clearly contradict - each other. Is there some later rfc than 974 that overrides what is - said in there with respect to MX and CNAMEs? Anyone have the - reference handy? - -A: This isn't what the BOG says at all. See below. You can have a CNAME - that points to some other RR type; in fact, all CNAMEs have to point - to other names (Canonical ones, hence the C in CNAME). What you - can't have is an MX that points to a CNAME. MX RR's that point to - names which have only CNAME RR's will not work in many cases, and - RFC 974 intimates that it's a bad idea: - - Note that the algorithm to delete irrelevant RRs breaks if LOCAL has - a alias and the alias is listed in the MX records for REMOTE. (E.g. - REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This - can be avoided if aliases are never used in the data section of MX - RRs. - - Here's the relevant BOG snippet: - - aliases {ttl addr-class CNAME Canonical name - ucbmonet IN CNAME monet - - The Canonical Name resource record, CNAME, speci- - fies an alias or nickname for the official, or - canonical, host name. This record should be the - only one associated with the alias name. All other - resource records should be associated with the - canonical name, not with the nickname. Any - resource records that include a domain name as - their value (e.g., NS or MX) must list the canoni- - cal name, not the nickname. - ------------------------------------------------------------------------------ - -Question 6.6. Can an NS record point to a CNAME ? - -Date: Wed Mar 1 11:14:10 EST 1995 - -Can I do this ? Is it legal ? - - - @ SOA (.........) - NS ns.host.this.domain. - NS second.host.another.domain. - ns CNAME third - third IN A xxx.xxx.xxx.xxx - -No. Only one RR type is allowed to refer, in its data field, to a CNAME, -and that's CNAME itself. So CNAMEs can refer to CNAMEs but NSs and MXs -cannot. - -BIND 4.9.3 (Beta11 and later) explicitly syslogs this case rather than -simply failing as pre-4.9 servers did. Here's a current example: - - Dec 7 00:52:18 gw named[17561]: "foobar.com IN NS" \ - points to a CNAME (foobar.foobar.com) - -Here is the reason why: - -Nameservers are not required to include CNAME records in the Additional -Info section returned after a query. It's partly an implementation -decision and partly a part of the spec. The algorithm described in RFC -1034 (pp24,25; info also in RFC 1035, section 3.3.11, p 18) says 'Put -whatever addresses are available into the additional section, using glue -RRs [if necessary]'. Since NS records are speced to contain only primary -names of hosts, not CNAMEs, then there's no reason for algorithm to -mention them. If, on the other hand, it's decided to allow CNAMEs in NS -records (and indeed in other records) then there's no reason that CNAME -records might not be included along with A records. The Additional Info -section is intended for any information that might be useful but which -isn't strictly the answer to the DNS query processed. It's an -implementation decision in as much as some servers used to follow CNAMEs -in NS references. - ------------------------------------------------------------------------------ - -Question 6.7. Nameserver forgets own A record - -Date: Fri Dec 2 16:17:31 EST 1994 - -Q: Lately, I've been having trouble with named 4.9.2 and 4.9.3. - Periodically, the nameserver will seem to "forget" its own A record, - although the other information stays intact. One theory I had was - that somehow a site that the nameserver was secondary for was - "corrupting" the A record somehow. - -A: This is invariably due to not removing ALL of the cached zones - when you moved to 4.9.X. Remove ALL cached zones and restart - your nameservers. - - You get "ignoreds" because the primaries for the relevant zones are - running old versions of BIND which pass out more glue than is - required. named-xfer trims off this extra glue. - ------------------------------------------------------------------------------ - -Question 6.8. General problems (core dumps !) - -Date: Sun Dec 4 22:21:22 EST 1994 - -Paul Vixie says: - - I'm always interested in hearing about cases where BIND dumps core. - However, I need a stack trace. Compile with -g and not -O (unless - you are using gcc and know what you are doing) and then when it - dumps core, get into dbx or gdb using the executable and the core - file and use "bt" to get a stack trace. Send it to me - <paul@vix.com> along with specific circumstances leading to or - surrounding the crash (test data, tail of the debug log, tail of the - syslog... whatever matters) and ideally you should save your core - dump for a day or so in case I have questions you can answer via - gdb/dbx. - ------------------------------------------------------------------------------ - -Question 6.9. malloc and DECstations - -Date: Mon Jan 2 14:19:22 EST 1995 - -We have replaced malloc on our DECstations with a malloc that is more -compact in memory usage, and this helped the operation of bind a lot. The -source is now available for anonymous ftp from - -ftp.cs.wisc.edu : /pub/misc/malloc.tar.gz - ------------------------------------------------------------------------------ - -Question 6.10. Can't resolve names without a "." - -(Answer written by Mark Andrews) You are not using a RFC 1535 aware -resolver. Depending upon the age of your resolver you could try adding a -search directive to resolv.conf. - - e.g. - domain <domain> - search <domain> [<domain2> ...] - -If that doesn't work you can configure you server to serve the parent and -grandparent domains as this is the default search list. - -"domain langley.af.mil" has an implicit "search langley.af.mil af.mil mil" -in the old resolvers, and you are timing out trying to resolve the -address with one of these domains tacked on. - -When resolving internic.net the following will be tried in order. - internic.net.langley.af.mil - internic.net.af.mil - internic.net.mil - internic.net. - -RFC 1535 aware resolvers try qualified address first. - - internic.net. - internic.net.langley.af.mil - internic.net.af.mil - internic.net.mil -RFC 1535 documents the problems associated with the old search -algorithim, including security issues, and how to alleviate some of the -problems. - ------------------------------------------------------------------------------ - -Question 6.11. Err/TO errors being reported - -Date: Sun May 5 23:46:32 EDT 1996 - -Why are errors like - - Apr 2 20:41:58 nameserver named[25846]: Err/TO getting serial# for - "foobar.domain1.com" - Apr 2 20:41:59 nameserver named[25846]: Err/TO getting serial# for - "foobar.domain2.com" - -reported ? These generally indicate that there is one of the following -problems: - -* A network problem between you and the primary, -* A bad IP address in named.boot, -* The primary is Lame for the zone. - -An external check to see if you can retrieve the SOA is the best way to -work out which it is. - ------------------------------------------------------------------------------ - -Question 6.12. Why does swapping kill BIND ? - -Date: Thu Jul 4 23:20:20 EDT 1996 - -The question was: - - I've been diagnosing a problem with BIND 4.9.x (where x is usually 3BETA9 - or 3REL) for several months now. I finally tracked it down to swap space - utilization on the unix boxes. - - This happens under (at least) under Linux 1.2.9 & 1.2.13, SunOS 4.1.3U1, - 4.1.1, and Solaris 2.5. The symptom is that if these machines get into - swap at all bind quits resolving most, if not all queries. Mind you that - these machines are not "swapping hard", but rather we're talking about a - several hundred K TEMPORARY deficiency. I have noticed while digging - through various archives that there is some referral to "bind thrashing - itself to death". Is this what is happening ? - -And the answer is: - - Yes it is. Bind can't tolerate having even a few pages swapped out. - The time required to send responses climbs to several seconds/request, - and the request queue fills and overflows. - - It's possible to shrink memory consumption a lot by undefining STATS - and XSTATS, and recompiling. You could nuke DEBUG too, which will - cut the code size down some, but probably not the data size. If that - doesn't do the job then it sounds like you'll need to move DNS onto a - separate box. - - BIND tends to touch all of its resident pages all of the time with - normal activity... if you look at the RSS verses the total process - size, you will always see the RSS within, usually, 90% of the total - size of the process. This means that *any* paging of named-owned - pages will stall named. Thus, a machine running a heavily accessed - named process cannot afford to swap *at all*. - - (Paul Vixie continues on this subject): - I plan to try to get BIND to exhibit slightly better locality of - reference in some future release. Of course, I can only do this if - the query names also exhibit some kind of hot spots. If someone - queries all your names often, BIND will have to touch all of its VM - pool that often. (Right now, BIND touches everything pretty often - even if you're just hammering on some hot spots -- that's the part - I'd like to fix. Malloc isn't cooperating.) - -=============================================================================== - -Section 7. ACKNOWLEDGEMENTS - - Q7.1 How is this FAQ generated ? - Q7.2 What formats are available ? - Q7.3 Contributors - ------------------------------------------------------------------------------ - -Question 7.1. How is this FAQ generated ? - -Date: Fri Dec 6 16:51:31 EST 1996 - -This FAQ is maintained in BFNN (Bizzarre Format with No Name). This -allows me to create ASCII, HTML, and GNU info (postscript coming soon) -from one source file. - -The perl script "bfnnconv.pl" that is available with the linux FAQ is used -to generate the various output files from the BFNN source. - ------------------------------------------------------------------------------ - -Question 7.2. What formats are available ? - -Date: Fri Dec 6 16:51:31 EST 1996 - -You may obtain one of the following formats for this document: - -* ASCII: http://www.users.pfmc.net/~cdp/cptd-faq/cptd-faq.ascii -* BFNN: http://www.users.pfmc.net/~cdp/cptd-faq/cptd-faq.bfnn -* GNU info: http://www.users.pfmc.net/~cdp/cptd-faq/cptd-faq.info -* HTML: http://www.users.pfmc.net/~cdp/cptd-faq/index.html - ------------------------------------------------------------------------------ - -Question 7.3. Contributors - -Date: Sat Dec 7 01:29:29 EST 1996 - -Many people have helped put this list together. Listed in e-mail address -alphabetical order, the following people have contributed to this FAQ: - -* <Benoit.Grange@inria.fr> (Benoit.Grange) -* <D.T.Shield@csc.liv.ac.uk> (Dave Shield) -* <Todd.Aven@BankersTrust.Com> -* <adam@comptech.demon.co.uk> (Adam Goodfellow) -* <andras@is.co.za> (Andras Salamon) -* <barmar@nic.near.net> (Barry Margolin) -* <barr@pop.psu.edu> (David Barr) -* <bj@herbison.com> (B.J. Herbison) -* <bje@cbr.fidonet.org> (Ben Elliston) -* <brad@birch.ims.disa.mil> (Brad Knowles) -* <ckd@kei.com> (Christopher Davis) -* <cdp2582@hertz.njit.edu> (Chris Peckham) -* <cricket@hp.com> (Cricket Liu) -* <cudep@csv.warwick.ac.uk> (Ian 'Vato' Dickinson [ID17]) -* <dillon@best.com> (Matthew Dillon) -* <dparter@cs.wisc.edu> (David Parter) -* <e07@nikhef.nl> (Eric Wassenaar) -* <fitz@think.com> (Tom Fitzgerald) -* <fwp@CC.MsState.Edu> (Frank Peters) -* <gah@cco.caltech.edu> (Glen A. Herrmannsfeldt) -* <glenn@popco.com> (Glenn Fleishman) -* <harvey@indyvax.iupui.edu> (James Harvey) -* <hubert@cac.washington.edu> (Steve Hubert) -* <ivanl@pacific.net.sg> (Ivan Leong) -* <jhawk@panix.com> (John Hawkinson) -* <jmalcolm@uunet.uu.net> (Joseph Malcolm) -* <jprovo@augustus.ultra.net> (Joe Provo) -* <kevin@cfc.com> (Kevin Darcy) -* <lamont@abstractsoft.com> (Sean T. Lamont) -* <lavondes@tidtest.total.fr> (Michel Lavondes) -* <mark@ucsalf.ac.uk> (Mark Powell) -* <marka@syd.dms.CSIRO.AU> (Mark Andrews) -* <mathias@unicorn.swi.com.sg> (Mathias Koerber) -* <mjo@iao.ford.com> (Mike O'Connor) -* <nick@flapjack.ieunet.ie> (Nick Hilliard) -* <oppedahl@popserver.panix.com> (Carl Oppedahl) -* <patrick@oes.amdahl.com> (Patrick J. Horgan) -* <paul@software.com> (Paul Wren) -* <pb@fasterix.frmug.fr.net> (Pierre Beyssac) -* <ph10@cus.cam.ac.uk> (Philip Hazel) -* <phil@netpart.com> (Phil Trubey) -* <rocky@panix.com> (R. Bernstein) -* <rv@seins.Informatik.Uni-Dortmund.DE> (Ruediger Volk) -* <shields@tembel.org> (Michael Shields) -* <tanner@george.arc.nasa.gov> (Rob Tanner) -* <vixie@vix.com> (Paul A Vixie) -* <wag@swl.msd.ray.com> (William Gianopoulos {84718) -* <whg@inel.gov> (Bill Gray) -* <wolf@pasteur.fr> (Christophe Wolfhugel) - -Thank you ! - diff --git a/contrib/bind/doc/misc/IPv6 b/contrib/bind/doc/misc/IPv6 deleted file mode 100644 index 49fc3f5ec37c..000000000000 --- a/contrib/bind/doc/misc/IPv6 +++ /dev/null @@ -1,72 +0,0 @@ -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 deleted file mode 100644 index 19f0197f7e81..000000000000 --- a/contrib/bind/doc/misc/dns-setup +++ /dev/null @@ -1,1081 +0,0 @@ - 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 deleted file mode 100644 index a966066074dd..000000000000 --- a/contrib/bind/doc/misc/style.txt +++ /dev/null @@ -1,172 +0,0 @@ -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> |