ftp.pasteur.org/FAQ/

home *** CD-ROM | disk | FTP | other *** search

/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / internet / tcp-ip / domains-faq / part1 next >

Wrap

Internet Message Format | 1999-02-12 | 78.4 KB

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news-out.cwix.com!news1.cwix.com!newsfeed.cwix.com!204.59.152.222!news-peer.gip.net!news.gsl.net!gip.net!news.idt.net!newsin.iconnet.net!IConNet!not-for-mail From: cdp2582@hertz.njit.edu (Chris Peckham) Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers,comp.protocols.dns.bind Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 1 of 2) Supersedes: <cptd-faq-1-916718634@njit.edu> Followup-To: comp.protocols.tcp-ip.domains Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA Lines: 1919 Sender: cdp@chipmunk.iconnet.net Approved: news-answers-request@MIT.EDU Distribution: world Expires: Thursday, 18 Mar 99 15:18:37 EDT Message-ID: <cptd-faq-1-918764317@njit.edu> Reply-To: cdp@intac.com (comp.protocols.tcp-ip.domains FAQ comments) Keywords: BIND,DOMAIN,DNS X-Posting-Frequency: posted during the first week of each month Date: Thu, 11 Feb 1999 20:18:01 GMT NNTP-Posting-Host: chipmunk.iconnet.net NNTP-Posting-Date: Thu, 11 Feb 1999 15:18:01 EDT Xref: senator-bedfellow.mit.edu comp.protocols.tcp-ip.domains:22750 comp.answers:35016 news.answers:151035 comp.protocols.dns.bind:6289 Posted-By: auto-faq 3.3 beta (Perl 5.004) Archive-name: internet/tcp-ip/domains-faq/part1 Note that this posting has been split into two parts because of its size. $Id: cptd-faq.bfnn,v 1.26 1999/02/11 20:01:58 cdp Exp cdp $ 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@intac.com>. 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.intac.com/~cdp/cptd-faq/. If you can contribute any answers for items in the TODO section, please do so by sending e-mail to <cdp@intac.com> ! If you know of any items that are not included and you feel that they should be, send the relevant information to <cdp@intac.com>. =============================================================================== 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 Reverse domains (IN-ADDR.ARPA) and their delegation 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 Domain names and legal issues Q2.23 Iterative and Recursive lookups Q2.24 Dynamic DNS Q2.25 What version of bind is running on a server ? Q2.26 BIND and Y2K Section 3. UTILITIES Q3.1 Utilities to administer DNS zone files Q3.2 DIG - Domain Internet Groper Q3.3 DNS packet analyzer 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 How do I turn the "_" check off ? Q4.8 What is lame delegation ? Q4.9 How can I see if the server is "lame" ? Q4.10 What does opt-class field in a zone file do? Q4.11 Top level domains Q4.12 US Domain Q4.13 Classes of networks Q4.14 What is CIDR ? Q4.15 What is the rule for glue ? Q4.16 What is a stub record/directive ? Section 5. CONFIGURATION Q5.1 Upgrading from 4.9.x to 8.x Q5.2 Changing a Secondary server to a Primary server ? Q5.3 Moving a Primary server to another server Q5.4 How do I subnet a Class B Address ? Q5.5 Subnetted domain name service Q5.6 Recommended format/style of DNS files Q5.7 DNS on a system not connected to the Internet Q5.8 Multiple Domain configuration Q5.9 wildcard MX records Q5.10 How do you identify a wildcard MX record ? Q5.11 Why are fully qualified domain names recommended ? Q5.12 Distributing load using named Q5.13 Round robin IS NOT load balancing Q5.14 Order of returned records Q5.15 resolv.conf Q5.16 How do I delegate authority for sub-domains ? Q5.17 DNS instead of NIS on a Sun OS 4.1.x system Q5.18 Patches to add functionality to BIND Q5.19 How to serve multiple domains from one server Q5.20 hostname and domain name the same Q5.21 Restricting zone transfers Q5.22 DNS in firewalled and private networks Q5.23 Modifying the Behavior of DNS with ndots Q5.24 Different DNS answers for same RR Section 6. PROBLEMS Q6.1 No address for root server Q6.2 Error - No Root Nameservers for Class XX Q6.3 Bind 4.9.x and MX querying? Q6.4 Do I need to define an A record for localhost ? Q6.5 MX records, CNAMES and A records for MX targets Q6.6 Can an NS record point to a CNAME ? Q6.7 Nameserver forgets own A record Q6.8 General problems (core dumps !) Q6.9 malloc and DECstations Q6.10 Can't resolve names without a "." Q6.11 Why does swapping kill BIND ? Q6.12 Resource limits warning in system Q6.13 ERROR:ns_forw: query...learnt Q6.14 ERROR:zone has trailing dot Q6.15 ERROR:Zone declared more then once Q6.16 ERROR:response from unexpected source Q6.17 ERROR:record too short from [zone name] Q6.18 ERROR:sysquery: findns error (3) Q6.19 ERROR:Err/TO getting serial# for XXX Q6.20 ERROR:zonename IN NS points to a CNAME Q6.21 ERROR:Masters for secondary zone [XX] unreachable Q6.22 ERROR:secondary zone [XX] expired Q6.23 ERROR:bad response to SOA query from [address] Q6.24 ERROR:premature EOF, fetching [zone] Q6.25 ERROR:Zone [XX] SOA serial# rcvd from [Y] is < ours Q6.26 ERROR:connect(IP/address) for zone [XX] failed Q6.27 ERROR:sysquery: no addrs found for NS Q6.28 ERROR:zone [name] rejected due to errors 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: Mon Jan 18 22:57:01 EST 1999 * Additional information on the new TLDs * Expand on Q: How to serve multiple domains from one server * Q: DNS ports - need to expand/correct some issues ----------------------------------------------------------------------------- Question 1.2. UPDATES / Changes since last posting Date: Thu Feb 11 14:36:02 EST 1999 * DNS in firewalled and private networks - Updated with comment about hint file * host - Updated NT info * How do I register a domain ? - JP NIC * BIND and Y2K =============================================================================== 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 Reverse domains (IN-ADDR.ARPA) and their delegation 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 Domain names and legal issues Q2.23 Iterative and Recursive lookups Q2.24 Dynamic DNS Q2.25 What version of bind is running on a server ? Q2.26 BIND and Y2K ----------------------------------------------------------------------------- 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 ? Date: Mon Sep 14 22:46:00 EDT 1998 This information may be found at http://www.vix.com/isc/bind/. Presently, there are two 'production level' versions of BIND. They are versions 4 and 8. Version 4 is the last "traditional" BIND -- the one everybody on the Internet runs, except a few hundred sites running... Version 8 has been called "BIND-ng" (Next Generation). Many new features are found in version 8. BIND-8.1 has the following features: * DNS Dynamic Updates (RFC 2136) * DNS Change Notification (RFC 1996) * Completely new configuration syntax * Flexible, categorized logging system * IP-address-based access control for queries, zone transfers, and updates that may be specified on a zone-by-zone basis * More efficient zone transfers * Improved performance for servers with thousands of zones * The server no longer forks for outbound zone transfers * Many bug fixes. Bind version 8.1.2 may be found at the following location: * Source ftp.isc.org : /isc/bind/src/8.1.2/bind-8.1.2-src.tar.gz * Documentation ftp.isc.org : /isc/bind/src/8.1.2/bind-8.1.2-doc.tar.gz * Contributed packages ftp.isc.org : /isc/bind/src/8.1.2/bind-8.1.2-contrib.tar.gz At this time, BIND version 4.9.7 may be found for anonymous ftp from ftp.isc.org : /isc/bind/src/4.9.7/bind-4.9.7-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.isc.org : /isc/bind/contrib/ntbind/ntdns497relbin.zip and ftp.isc.org : /isc/bind/contrib/ntbind/ntbind497rel.zip If you contact access@drcoffsite.com, he will send you information regarding a Windows NT/WIN95 bind port of 4.9.6 release. A Freeware version of Bind for NT is available at http://www.software.com. ----------------------------------------------------------------------------- Question 2.6. How can I find the path taken between two systems/domains ? Date: Wed Jan 14 12:07:03 EST 1998 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 NT/Windows 95 users may use the command TRACERT.EXE, which is installed with the TCP/IP protocol support. There is a Winsock utility called WS_PING by John Junod that provides ping, traceroute, and nslookup functionality. There are several shareware TCP/IP utilities that provide ping, traceroute, and DNS lookup functionality for a Macintosh: Mac TCP Watcher and IP Net Monitor are two of them. ----------------------------------------------------------------------------- Question 2.7. How do you find the hostname given the TCP-IP address ? Mon Jun 15 21:32:57 EDT 1998 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 dig is included in the bind distribution. host from the bind distribution may also be used. On a Macintosh, some shareware utilities may be used. IP Net Monitor has a very nice NS Lookup feature, producing DiG-like output; Mac TCP Watcher just has a simple name-to-address and address-to-name translator. ----------------------------------------------------------------------------- Question 2.8. How do I register a domain ? Date: Thu Feb 11 14:51:50 EST 1999 Procedures for registering a domain name depend on the top level domain (TLD) to which the desired domain name will belong, i.e. the rightmost suffix of the desired domain name. See the answer to "Top level domains" question in the DEFINITIONS SECTION of this FAQ. Although domain registration may be performed by a direct contact with the appropriate domain registration authorities (domain name registrars), the easiest way to do it is to talk to your Internet Service Providers. They can submit a domain registration request on your behalf, as well as to set up secondary DNS for your domain (or both DNS servers, if you need a domain name for Web hosting and/or mail delivery purposes only). 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 (see RFC 2182) servers _before_ the InterNIC is approached for registration. In any case, 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. If you want to register a domain name ending with .COM, .NET, .ORG, you'll want to take a look to the InterNIC: * http://www.internic.net/ -> Registration Services * internic.net : /templates/domain-template.txt * gopher://rs.internic.net/ Please note that the InterNIC charges 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. Note that InterNIC doesn't allocate and assign IP numbers any more. Please refer to the answer to "How do I get my address assigned from the NIC?" in this section. Registration of domain names ending with country code suffixes (ISO 3166 - .FR, .CH, .SE etc.) is being done by the national domain name registrars (NICs). If you want to obtain such a domain, please refer to the following links: Additional domain/whois information may be found: * http://rs.internic.net/help/other-reg.html * http://www.iana.org/ * http://www.ripe.net/centr/tld.html * http://www.UNINETT.NO/navn/domreg.html * http://www.nic.fr/Guides/AutresNics/ * http://www.arin.net * whois.apnic.net * whois.nic.ad.jp (with /e at the end of query for English) * sipb.mit.edu : /pub/whois/whois-servers.list * http://www.geektools.com/whois.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. You may be requested to make your request to another email address or using a certain information template/application. Please remember that every TLD registrar has its own registration policies and procedures. ----------------------------------------------------------------------------- Question 2.9. How can I change the IP address of our server ? Date: Wed Jan 14 12:09:09 EST 1998 (From Mark Andrews) Before the move. * Ensure you are running a modern nameserver. BIND 4.9.6-P1 or 8.1.1 are good choices. * 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 refresh 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 relevant zones. If you're changing the address of a server registered with the InterNIC, you also need to submit a Modify Host form to the InterNIC, so they will update the glue records on the root servers. It can take the InterNIC a few days to process this form, and the old glue records have 2-day TTL's, so this transition may be problematic. * Inform all the administrators of zones you are secondarying 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 stabilize 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. Reverse domains (IN-ADDR.ARPA) and their delegation Date: Mon Jun 15 23:28:47 EDT 1998 (The following section was contributed by Berislav Todorovic.) Reverse domains (subdomains of the IN-ADDR.ARPA domain) are being used by the domain name service to perform reverse name mapping - from IP addresses to host names. Reverse domains are more closely related to IP address space usage than to the "forward" domain names used. For example, a host using IP address 10.91.8.6 will have its "reverse" name: 6.8.91.10.IN-ADDR.ARPA, which must be entered in the DNS, by a PTR record: 6.8.91.10.in-addr.arpa. IN PTR myserver.mydomain.com. In spite of the fact that IP address space is not longer divided into classes (A, B, C, D, E - see the answer to "What is CIDR?" in the DEFINITIONS section), the reverse host/domain names are organized on IP address byte boundaries. Thus, the reverse host name 6.8.91.10.IN-ADDR.ARPA may belong to one of the following reverse domains, depending on the address space allocated/assigned to you and your DNS configuration: (1) 8.91.10.in-addr.arpa -> assigned one or more "C class" networks (IP >= /24) (2) 91.10.in-addr.arpa -> assigned a whole "B class" 10.91/16 (IP = /16) (3) ISP dependent -> assigned < "C class" - e.g. 10.91.8/26 (IP < /24) No matter what is your case (1, 2 or 3) - the reverse domain name must be properly delegated - registered in the IN-ADDR.ARPA zone. Otherwise, translation IP -> host name will fail, which may cause troubles when using some Internet services and accessing some public sites. To register your reverse domain, talk to your Internet service provider, to ensure proper DNS configuration, according to your network topology and address space assigned. They will point you to a further instance, if necessary. Generally speaking, while forward domain name registration is a matter of domain name registrars (InterNIC, national NICs), reverse domain name delegation is being done by the authorities, assigning IP address space - Internet service providers and regional Internet registries (see the answer to "How do I get my address assigned from the NIC?" in this section). Important notes: (1) If you're assigned a block or one or more "Class C" networks, you'll have to maintain a separate reverse domain zone file for each "Class C" from the block. For example, if you're assigned 10.91.8/22, you'll have to configure a separate zone file for 4 domains: 8.91.10.in-addr.arpa 9.91.10.in-addr.arpa 10.91.10.in-addr.arpa 11.91.10.in-addr.arpa and to delegate them further in the DNS (according to the advice from your ISP). (2) If you're assigned a whole "B class" (say, 10.91/16), you're in charge for the whole 91.10.IN-ADDR.ARPA zone. See the answer to "How do I subnet a Class B Address?" in the CONFIGURATION section. (3) If you're assigned only a portion of a "C class" (say, 10.91.8.0/26) see the answer to "Subnetted domain name service" question in the CONFIGURATION section. For more information on reverse domain delegations see: * http://www.arin.net/templates/inaddrtemplate.txt * http://www.ripe.net/docs/ripe-159.html * ftp.apnic.net : /apnic/docs/in-addr-request ----------------------------------------------------------------------------- Question 2.14. How do I get my address assigned from the NIC ? Date: Mon Jun 15 22:48:24 EDT 1998 IP address space assignment to end users is no longer being performed by regional Internet registries (InterNIC, ARIN, RIPE NCC, APNIC). If you need IP address space, you should make a request to your Internet service provider. If you already have address space and need more IP numbers, make a request to your ISP again and you may be given more numbers (different ISPs have different allocation requirements and procedures). If you are a smaller ISP - talk to your upstream ISP to obtain necessary numbers for your customers. If you change the ISP in the future, you MAY have to renumber your network. See RFC 2050 and RFC 2071 for more information on this issue. Currently, address space is being distributed in a hierarchical manner: ISPs assign addresses to their end customers. The regional Internet registries allocate blocks of addresses (usually sized between /19 (32 "C class") and /16 (a "B class")) to the ISPs. Finally - IANA (Internet Assigned Number Authority) allocates necessary address space (/8 ("A class") sized blocks) to the regional registries, as the need for address space arises. This hierarchical process ensures more efficient routing on the backbones (less traffic caused by routing information updates, better memory utilization in backbone routers etc.) as well as more rational address usage. If you are an ISP, planning to connect yourself to more than one ISP (i.e. becoming multi-homed) and/or expecting to have a lot of customers, you'll have to obtain ISP independent address space from a regional Internet registry. Depending on your geographical locations, you can obtain such address blocks (/19 and larger blocks) from: * RIPE NCC (http://www.ripe.net/) -> Europe, North Africa and Middle East * ARIN (http://www.arin.net/) -> North and South America, Central Africa * APNIC (http://www.apnic.net/) -> Asian and Pacific region While the regional registries do not sell address space, they do charge for their services (allocation of address space, reverse domain delegations etc.) ----------------------------------------------------------------------------- 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 Jan 14 12:28:46 EST 1998 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. However, if the parent domain server is a secondary or stub server for the child domain, it will "hoist" the NS records from the child into the parent domain. This frequently happens with reverse domains, since the ISP operates primary reverse DNS for its CIDR block and also often runs secondary DNS for many customers' reverse domains. Caching servers will often replace the NS records learned from the parent server with the authoritative list that the child server sends in its authority section. If the authoritative list is missing the secondary servers, those caching servers won't be able to look up in this domain if the primary goes down. After all of this, it is important that your NS records be correct ! ----------------------------------------------------------------------------- Question 2.18. DNS ports Date: Wed Jan 14 12:31:39 EST 1998 The following table shows what TCP/UDP ports bind before 8.x 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. BIND 8.x no longer uses port 53 as the source port for recursive queries. By defalt it uses a random port >1023, although you can configure a specific port (53 if you want). 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 its 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.intac.com/~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 record keeping, 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. Domain names and legal issues Date: Mon Jun 15 22:15:32 EDT 1998 A domain name may be someone's trademark and the use of a trademark without its owner's permission may be a trademark violation. This may lead to a legal dispute. RFC 1591 allows registration authorities to play a neutral role in domain name disputes, stating that: In case of a dispute between domain name registrants as to the rights to a particular name, the registration authority shall have no role or responsibility other than to provide the contact information to both parties. The InterNIC's current domain dispute policy (effective February 25, 1998) is located at: http://www.internic.net/domain-info/internic-domain-6.html Other domain registrars have similar domain dispute policies. 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. ----------------------------------------------------------------------------- Question 2.23. Iterative and Recursive lookups Date: Wed Jul 9 22:05:32 EDT 1997 Q: What is the difference between iterative and recursive lookups ? How do you configure them and when would you specify one over the other ? A: (from an answer written by Barry Margolin) In an iterative lookup, the server tells the client "I don't know the answer, try asking <list of other servers>". In a recursive lookup, the server asks one of the other servers on your behalf, and then relays the answer back to you. Recursive servers are usually used by stub resolvers (the name lookup software on end systems). They're configured to ask a specific set of servers, and expect those servers to return an answer rather than a referral. By configuring the servers with recursion, they will cache answers so that if two clients try to look up the same thing it won't have to ask the remote server twice, thus speeding things up. Servers that aren't intended for use by stub resolvers (e.g. the root servers, authoritative servers for domains). Disabling recursion reduces the load on them. In BIND 4.x, you disable recursion with "options no-recursion" in the named.boot file. ----------------------------------------------------------------------------- Question 2.24. Dynamic DNS Mon Jan 18 20:31:58 EST 1999 Q: Bind 8 includes some support for Dynamic DNS as specified in RFC 2136. It does not currently include the authentication mechanism that is described in RFC 2137, meaning that any update requests received from allowed hosts will be honored. Could someone give me a working example of what syntax nsupdate expects ? Is it possible to write an update routine which directs it's update to a particular server, ignoring what the DNS servers are the serving NS's? A: You might check out Michael Fuhr's Net::DNS Perl module, which you can use to put together dynamic update requests. See http://www.fuhr.net/~mfuhr/perldns/Update.html for additional information. Michael posted a sample script to show how to use Net::DNS: #!/usr/local/bin/perl -w use Net::DNS; $res = new Net::DNS::Resolver; $res->nameservers("some-nameserver.foo.com"); $update = new Net::DNS::Update("foo.com"); $update->push("update", rr_del("old-host.foo.com")); $update->push("update", rr_add("new-host.foo.com A 10.1.2.3")); $ans = $res->send($update); print $ans ? $ans->header->rcode : $res->errorstring, "\n"; Additional information for Dynamic DNS updates may be found at http://simmons.starkville.ms.us/tips/081797/. ----------------------------------------------------------------------------- Question 2.25. What version of bind is running on a server ? Date: Mon Mar 9 22:15:11 EST 1998 On 4.9+ servers, you may obtain the version of bind running with the following command: dig @server.to.query txt chaos version.bind. and optionally pipe that into 'grep VERSION'. Please note that this will not work on an older nameserver. ----------------------------------------------------------------------------- Question 2.26. BIND and Y2K Date: Thu Feb 11 14:58:04 EST 1999 Is the "Y2K" problem an issue for bind ? You will find the Internet Software Consortium's comment on the "Y2K" issue at http://www.isc.org/y2k.html. =============================================================================== Section 3. UTILITIES Q3.1 Utilities to administer DNS zone files Q3.2 DIG - Domain Internet Groper Q3.3 DNS packet analyzer 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: Tue Jan 7 00:22:31 EST 1997 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 bpp is a m4 macro package for pre-processing the master files bind uses to define zones. Information on this package may be found at http://www.meme.com/soft. More information on various DNS related utilities 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 analyzer Date: Mon Jun 15 21:42:11 EDT 1998 There is a free ethernet analyzer called Ethload available for PC's running DOS. The latest filename is ETHLD200.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. The current home page for Ethload is http://www.ping.be/ethload. ----------------------------------------------------------------------------- Question 3.4. host Date: Thu Feb 11 14:43:39 EST 1999 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 Programs with some of the functionality of host for NT may be found at http://www.tucows.com under "Network Tools, DNS Lookup Utilities". ----------------------------------------------------------------------------- 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 Mon Jan 18 20:35:49 EST 1999 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 Two that come to mind are MIT's WebDNS and the University of Utah tools. There are also a number of commercial 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 * dnsboss, http://www.dnsboss.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 How do I turn the "_" check off ? Q4.8 What is lame delegation ? Q4.9 How can I see if the server is "lame" ? Q4.10 What does opt-class field in a zone file do? Q4.11 Top level domains Q4.12 US Domain Q4.13 Classes of networks Q4.14 What is CIDR ? Q4.15 What is the rule for glue ? Q4.16 What is a stub record/directive ? ----------------------------------------------------------------------------- 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: Mon Jan 18 22:14:30 EST 1999 Parts of this section were contributed by Albert E. Whale. "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!) If you have a "forwarders" line, you will only consult the root servers if you get no response from the forwarder. If you get a response, and it says there's no such host, you'll return that answer to the client -- you won't consult the root. The "forwarders" statement is found in the /etc/named.boot file which is read each time DNS is started. The command format is as follows: forwarders <IP Address #1> [<IP Address #2>, .... <IP Address #n>] The "forwarders" line specifies the IP Address(es) of DNS servers that accept queries from other servers. The "forwarders" command is used to cause a large site wide cache to be created on a master and reduce traffic over the network to other servers. It can also be used to allow DNS servers to answer Internet name queries which do not have direct access to the Internet. The forwarders command is used in conjunction with the traditional DNS configuration which requires that a NS entry be found in the cache file. The DNS server can support the forwarders command if the server is able to resolve entries that are not part of the local server's cache. "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). The "slave" command is usually found immediately following the forwarders command in the boot file. It is normally used on machines that are running DNS but do not have direct access to the Internet. By using the "forwarders" and "slave" commands the server can contact another DNS server which can answer DNS queries. The "slave" option may also be used behind a firewall where there may not be a network path available to directly contact nameservers listed in the cache. Additional information on slave servers may be found in the BOG (BIND Operations Guide http://www.isc.org/bind.html) section 6.1.8 (Slave Servers). ----------------------------------------------------------------------------- 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: Sat Aug 9 20:30:37 EDT 1997 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. An RFC Internet standards track protocol on the subject "Clarifications to the DNS Specification" may be found in RFC 2181. This updates RFC 1034, RFC 1035, and RFC 1123. ----------------------------------------------------------------------------- Question 4.7. How do I turn the "_" check off ? Date: Mon Nov 10 22:54:54 EST 1997 In the 4.9.5-REL and greater, you may turn this feature off with the option "check-names" in the named boot file. This option is documented in the named manual page. The syntax is: check-names primary warn ----------------------------------------------------------------------------- Question 4.8. What is lame delegation ? Date: Tue Mar 11 21:51:21 EST 1997 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 X about Y, 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.9. How can I see if the server is "lame" ? Date: Mon Sep 14 22:09:35 EDT 1998 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 included in the BIND distribution. 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 re-registration. Notification of the final deletion will be sent to the name server and domain name contacts listed in the NIC database. ----------------------------------------------------------------------------- Question 4.10. 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.11. Top level domains Date: Mon Jun 15 22:25:57 EDT 1998 RFC 1591 defines the term "Top Level Domain" (TLD) as: 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. The unnamed root-level domain (usually denoted as ".") is currently being maintained by the Internet Assigned Number Authority (IANA). Beside that, IANA is currently in charge for some other vital functions on the Internet today, including global distribution of address space, autonomous system numbers and all other similar numerical constants, necessary for proper TCP/IP protocol stack operation (e.g. port numbers, protocol identifiers and so on). According to the recent proposals of the US Government, better known as "Green Paper": http://www.ntia.doc.gov/ntiahome/domainname/domainname130.htm IANA will gradually transfer its current functions to a new non-profit international organization, which won't be influenced exclusively by the US Government. This transfer will occur upon the final version of the "Green Paper" has been issued. Currently, the root zone contains five categories of top level domains: (1) World wide gTLDs - maintained by the InterNIC: - COM - Intended for commercial entities - companies, corporations etc. - NET - Intended for Internet service providers and similar entities. - ORG - Intended for other organizations, which don't fit to the above. (2) Special status gTLDs - EDU - Restricted to 4 year colleges and universities only. - INT - Intended for international treaties and infrastructural databases. (3) US restricted gTLDs - GOV - Intended for US Government offices and agencies. - MIL - Intended for the US military. (4) ISO 3166 country code TLDs (ccTLDs) - FR, CH, SE etc. (5) Reverse TLD - IN-ADDR.ARPA. Generic TLDs COM, NET, ORG and EDU are currently being maintained by the InterNIC. IANA maintains INT and IN-ADDR.ARPA. The US Government and US Army maintain their TLDs independently. 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 The country code domains (ISO 3166 based - 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. 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 More information about particular country code TLDs may be found at: * http://www.iana.org/ * http://www.UNINETT.NO/navn/domreg.html * http://www.ripe.net/centr/tld.html * http://www.nic.fr/Guides/AutresNics/ * sipb.mit.edu : /pub/whois/whois-servers.list Contrary to the initial plans, stated in the RFC 1591, not to include more TLDs in the near future, some other forums don't share that opinion. The International Ad Hoc Committee (IAHC) ({http://www.iahc.org/) was was selected by the IAB, IANA, ITU, INTA, WIPO, and ISOC to study and recommend changes to the existing Domain Name System (DNS). The IAHC recommended the following regarding TLD's on February 4, 1997: In order to cope with the great and growing demand for Internet addresses in the generic top level domains, the generic Top Level Domain (gTLD) MoU calls for the establishment of seven new gTLDs in addition to the existing three. These will be .FIRM, .STORE, .WEB, .ARTS, .REC, .NOM and .INFO. In addition, the MoU provides for the setting up of an initial 28 new registrars around the world four from each of seven world regions. More registrars will be added as operational and administrative issues are worked out. Registrars will compete on a global basis, and users will be able shop around for the registrar which offers them the best arrangement and price. Users will also be able to change registrar at any time while retaining the same domain address, thus ensuring global portability. The full text of the recommendation may be found at: http://www.iahc.org/draft-iahc-recommend-00.html. Beside IAHC, several other forums have been created, by people willing to change the current addressing structure in the global network. Some of them may be found at: * http://www.alternic.net/ * http://www.eu.org/ * http://www.webtld.com/ 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 ----------------------------------------------------------------------------- Question 4.12. US Domain Date: Mon Jun 15 22:25:57 EDT 1998 Information on the US domain registration services may be found at http://www.isi.edu/in-notes/usdnr/. 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/ A WWW interface to a whois server for the US domain may be found at http://www.isi.edu/in-notes/usdnr/rwhois.html. This whois server may be used with the command % whois -h nii-server.isi.edu k12.ks.us OR % whois k12.ks.us@nii-server.isi.edu (depending on your version of whois). ----------------------------------------------------------------------------- Question 4.13. Classes of networks Date: Sun Feb 9 22:36:21 EST 1997 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 21 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.14. 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.15. What is the rule for glue ? Date: Mon Sep 14 22:04:42 EDT 1998 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. In response to a question on glue records, Mark Andrews stated the following: BIND's current position is somewhere between the overly restrictive position given above and the general allow all glue position that prevailed in 4.8.x. BIND's current break point is below the *parent* zone, i.e. it allows glue records from sibling zones of the zone being delegated. The following applies for glue Below child: always required Below parent: often required Elsewhere: seldom required The main reason for resticting glue is not that it in not required but that it is impossible to track down *bad* glue if you allow glue that falls into "elsewhere". Ask UUNET or any other large provider the problems that BIND 4.8.x general glue rules caused. If you want to examine a true data virus you need only look at the A records for ns.uu.net. The "below parent" and "below child" both allow you to find bad glue records. Below the parent has a bigger search space to that of below the child but is still managable. It is believed that the elsewhere cases are sufficiently rare that they can be ignored in practice and if detected can be worked around by creating be creating A records for the nameservers that fall into one of the other two cases. This requires resolvers to correctly lookup missing glue and requery when they have this glue. BIND does *not* do this correctly at present. ----------------------------------------------------------------------------- Question 4.16. What is a stub record/directive ? Date: Mon Nov 10 22:45:33 EST 1997 Q: What is the difference, or advantages, of using a stub record versus using an NS record and a glue record in the zone file? Cricket Liu responds, "Stub" is a directive, not a record (well, it's a directive in BIND 4; in BIND 8, it's an option to the "zone" statement). The stub directive configures your name server to do a zone transfer just as a secondary master name server would, but to use just the NS records. It's a convenient way for a parent name server to keep track of the servers for subzones. and Barry Margolin adds, Using stub records ensures that the NS records in the parent will be consistent with the NS records in the child. If you have to enter NS records manually, you run the possibility that the child will change his servers without telling you. Then you'll give out incorrect delegation information, possibly resulting in the infamous "lame delegation". The remainder of the FAQ is in the next part (Part 2 of 2).