comp.protocols.tcp-ip.domains FAQ - Section 4
DEFINITIONS

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:

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:

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:

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:

More information about particular country code TLDs may be found at: 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:

You may participate in one of the discussions on iTLD proposals at

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:

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

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".

Next: CONFIGURATION.
Back: UTILITIES .
Return to contents.

Chris Peckham - 16 June 1999

Extracted from comp.protocols.tcp-ip.domains Frequently Asked Questions, Copyright 1999.