comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 1 of 2)

From: cdp2582@hertz.njit.edu (Chris Peckham)
Newsgroups: comp.protocols.tcp-ip.domains, comp.protocols.dns.bind
Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 1 of 2)
Sender: cdp@chipmunk.iconnet.net
Message-ID: 
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

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, .  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  !  If you know of any items that
are not included and you feel that they should be,  send the relevant
information to .

===============================================================================

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 
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  [, .... ]
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.

         ::= 

         ::= *["."]
   ::= [*[]]

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

Part1 - Part2

comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2)

From: cdp2582@hertz.njit.edu (Chris Peckham)
Newsgroups: comp.protocols.tcp-ip.domains, comp.protocols.dns.bind
Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2)
Sender: cdp@chipmunk.iconnet.net
Message-ID: 
Reply-To: domain-faq@pfmc.net (comp.protocols.tcp-ip.domains FAQ comments)
Keywords: BIND,DOMAIN,DNS
X-Posting-Frequency: posted during the first week of each month
Date: Wed, 16 Dec 1998 16:47:32 GMT

Posted-By: auto-faq 3.3 beta (Perl 5.004)
Archive-name: internet/tcp-ip/domains-faq/part2

(Continued from Part 1, where you'll find the introduction and 
table of contents.)

===============================================================================

Section 5.  CONFIGURATION

 Q5.1        Upgrading from 4.9.x to 8.x 
 Q5.2        Changing a Secondary server to a Primary server ?
 Q5.3        Moving a Primary server to another server
 Q5.4        How do I subnet a Class B Address ?
 Q5.5        Subnetted domain name service
 Q5.6        Recommended format/style of DNS files
 Q5.7        DNS on a system not connected to the Internet
 Q5.8        Multiple Domain configuration
 Q5.9        wildcard MX records
 Q5.10       How do you identify a wildcard MX record ?
 Q5.11       Why are fully qualified domain names recommended ?
 Q5.12       Distributing load using named
 Q5.13       Round robin IS NOT load balancing
 Q5.14       Order of returned records
 Q5.15       resolv.conf
 Q5.16       How do I delegate authority for sub-domains ?
 Q5.17       DNS instead of NIS on a Sun OS 4.1.x system
 Q5.18       Patches to add functionality to BIND 
 Q5.19       How to serve multiple domains from one server
 Q5.20       hostname and domain name the same
 Q5.21       Restricting zone transfers
 Q5.22       DNS in firewalled and private networks
 Q5.23       Different DNS answers for same RR

-----------------------------------------------------------------------------

Question 5.1.  Upgrading from 4.9.x to 8.x

Date: Wed Jul  9 22:00:07 EDT 1997

Q: Help !  How do I use the Completely new configuration syntax in BIND 8
? I've attempted to upgrade bind from 4.9.5 to 8.1, but unfortunately it
didn't seem to like the same config/zone files.. is this normal or should
8.1 be able to read the same files as 4.9.5 did?

A: If you then look in doc/html/config.html, you will find directions on
how to convert a 4.9.x .boot file to 8.x .conf file, as well as directions
on how to utilize all of the new features of the 8.x .conf file format.

-----------------------------------------------------------------------------

Question 5.2.  Changing a Secondary server to a Primary server ?

Date: Fri Jul  5 23:54:35 EDT 1996

For 4.8.3,  it's prudent to kill and restart following any changes to
named.boot.

In BIND 4.9.3, you only have to kill and restart named if you change a
primary zone to a secondary or v-v, or if you delete a zone and remain
authoritative for its parent.  Every other case should be taken care of by
a HUP.  (Ed. note: 4.9.3b9 may still require you to kill and restart the
server due to some bugs in the HUP code).

You will also need to update the server information on the root servers.
You can do this by filing a new domain registration form to inform
InterNIC of the change.  They will then update the root server's SOA
records.  This process usually takes 10-12 business days after they
receive the request.

-----------------------------------------------------------------------------

Question 5.3.  Moving a Primary server to another server

Date: Fri Jul  5 23:54:35 EDT 1996

The usual solution is to move the primary to ns.newserver.com, and have
ns.oldserver.com be configured as a secondary server until the change  to
the root servers takes place after the request has been made to the
InterNIC.

If you are moving to a different ISP which will change your IP's, the
recommend setting for the SOA that would minimize problems for your name
servers using the old settings can be done as follows:

Gradually lower the TTL value in your SOA (that's the last one of the five
numbers) to always be equal to the time left until you change over.
(assuming that none of your resource records have individual TTL's set, if
so, do likewise with them.)  So, the day before, lower  to 43200 seconds
(12 hours).  Then lower every few hours to be the time  remaining until
the change-over.  So, an hour before the change, you may  just want to
lower it all the way to 60 seconds or so.  That way no one  can cache
information past the change-over.

After the change, start gradually incrementing the TTL value, because
you'll probably be making changes to work out problems.  Once everything
stabilizes, move the TTL up to whatever your normal values are.

To minimize name servers from using the "old settings", you can do the
same thing with the "refresh" interval in the SOA (the second number of
the SOA).  That will tell the secondaries to refresh every X seconds.
Lower that value as you approach the changeover date.  You probably don't
want to go much below an hour or you'll start the primary thrashing as all
the secondaries perpetually refresh.

Also see the answer to the "How can I change the IP address of our server
?" in the INTRODUCTION section.

-----------------------------------------------------------------------------

Question 5.4.  How do I subnet a Class B Address ?

Date: Mon Jun 15 23:21:39 EDT 1998

That you need to subnet at all is something of a misconception.  You can
also think of a class B network as giving you 65,534 individual hosts, and
such a network will work. You can also configure your class B as 16,384
networks of 2 hosts each.  That's obviously not very practical, but it
needs to be made clear that you are not constrained by the size of an
octet (remember that many older devices would not work in a network
configured in this manner).

So, the question is: why do you need to subnet?   One reason is that it is
easier to manage a subnetted network, and in fact, you can delegate the
responsibility for address space management to local administrators on the
various subnets.  Also, IP based problems will end up localized rather
than affecting your entire network.

If your network is a large backbone with numerous segments individually
branching off the backbone, that too suggests subnetting.

Subnetting can also be used to improve routing conditions.

You may wish to partition your network to disallow certain protocols  on
certain segments of your net.  You can, for example, restrict IP or IPX to
certain segments only by adding a router routing high level  protocols,
and across the router you may have to subnet.

Finally, as far as how many subnets you need depends on the answer to the
above question.  As far as subnet masks are concerned, the mask can be
anything from 255.0.0.0 to 255.255.255.252.  You'll probably be looking at
9 or 10 bits for the subnet (last octet 128 or 192 respectively).  RFC
1219 discusses the issue of subnetting very well  and leaves the network
administrator with a large amount of flexibility for future growth.

(The following section was contributed by Berislav Todorovic.)

A user or an ISP, having a whole /16 sized IP block (former "Class B")
network assigned/allocated, has the responsibility of maintaining the
reverse domain for the whole network. That policy is currently applied by
all regional Internet registries (RIPE NCC, ARIN, APNIC). In other words,
if you're assigned a whole "B class" (say, 10.91/16), you're in charge for
the whole 91.10.IN-ADDR.ARPA zone. This zone may be organized using two
methods, according to the network topology being in use.

The first, "brute force" method is to place all PTR records directly into
a single zone file. Example:

   $origin  91.10.in-addr.arpa
   @        IN   SOA   (usual stuff)
            IN   NS    ns1.mydomain.com.
            IN   NS    ns2.mydomain.com.

   1.1      IN   PTR   one-1.mydomain.com.       ; ---> 10.91.1.1
   2.1      IN   PTR   one-2.mydomain.com.       ; ---> 10.91.1.2
   ...
   254.1    IN   PTR   one-254.mydomain.com.     ; ---> 10.91.1.254
   1.2      IN   PTR   two-1.mydomain.com.       ; ---> 10.91.2.1

While this approach may look simple in the networks with a central
management authority (say, campus networks), maintaining such a zone file
becomes more and more difficult in the more complex environment.  Thus,
this becomes a bad method. Furthermore, if you're an ISP, it is more
likely that a /16 network will be subnetted and its subnets be assigned to
your customers.

Therefore, another "smarter" approach is to delegate portions of the
reverse domain 91.10.IN-ADDR.ARPA to the end users of the subnets of
10.91/16. There would only be NS records in the zone file, while PTR
record insertion would be the responsibility of the end users. For
example, if you assign:

   * 10.91.0.0/22  (10.91.0.0 - 10.91.3.255) to Customer-A.COM
   * 10.91.4.0/23  (10.91.4.0 - 10.91.5.255) to Customer-B.COM
   * 10.91.7.0/24  (10.91.7.0 - 10.91.7.255) to Customer-C.COM

then each customer will maintain zone files for the reverse domains of
their own networks (say, Customer C will maintain the zone
7.91.10.IN-ADDR.ARPA, customer B their 2 zones, Customer A their own 4
zones).  In this constellation, the zone file for reverse domain
91.10.IN-ADDR.ARPA will look like this:

   $origin  91.10.in-addr.arpa
   @        IN   SOA   (usual stuff)
            IN   NS    ns1.mydomain.com.
            IN   NS    ns2.mydomain.com.

   ; --- Customer-A.COM

   0        IN   NS    ns.customer-A.com.
            IN   NS    ns1.mydomain.com.
   1        IN   NS    ns.customer-A.com.
            IN   NS    ns1.mydomain.com.
   2        IN   NS    ns.customer-A.com.
            IN   NS    ns1.mydomain.com.
   3        IN   NS    ns.customer-A.com.
            IN   NS    ns1.mydomain.com.

   ; --- Customer-B.COM

   4        IN   NS    ns.customer-B.com.
            IN   NS    ns1.mydomain.com.
   5        IN   NS    ns.customer-B.com.
            IN   NS    ns1.mydomain.com.

   ; --- Customer-C.COM

   7        IN   NS    ns.customer-C.com.
            IN   NS    ns1.mydomain.com.

The zone file of the Customer C reverse domain would look like this:

   $origin  7.91.10.in-addr.arpa
   @        IN   SOA   (usual stuff)
            IN   NS    ns.customer-C.com.
            IN   NS    ns1.mydomain.com.

   1        IN   PTR   one.customer-C.com.
   2        IN   PTR   two.customer-C.com.
   3        IN   PTR   three.customer-C.com.
   ...

-----------------------------------------------------------------------------

Question 5.5.  Subnetted domain name service

Date: Thu Jul 16 10:50:41 EDT 1998

If you are looking for some examples of handling subnetted class C
networks as separate DNS domains, see RFC 2317 for more information.

Details follow- You need to delegate down to the fourth octet, so you will
have one domain per IP address !  Here is how you can subdelegate a
in-addr.arpa address for non-byte aligned subnet masks:

Take as an example the net 192.1.1.x, and example subnet mask
255.255.255.240.

We first define the domain for the class C net,

   $origin  1.1.192.in-addr.arpa
   @       SOA   (usual stuff)
   @       ns  some.nameserver
           ns  some.other.nameserver
   ; delegate a subdomain
   one     ns  one.nameserver
           ns  some.nameserver
   ; delegate another
   two     ns  two.nameserver
           ns  some.nameserver
   ; CNAME pointers to subdomain one
   0       CNAME 0.one
   1       CNAME 1.one
   ;    through
   15      CNAME 15.one
   ; CNAME pointers to subdomain two
   16      CNAME 16.two
   17      CNAME 17.two
   31      CNAME 31.two
   ; CNAME as many as required.

Now, in the delegated nameserver, one.nameserver

   $origin one.1.1.192.in-addr.arpa
   @       SOA (usual stuff)
           NS  one.nameserver
           NS  some.nameserver   ;  secondary for us
   0       PTR  onenet.one.domain
   1       PTR  onehost.one.domain
   ;   through
   15      PTR  lasthost.one.domain

And similar for the two.1.1.192.in-addr.arpa delegated domain.

There is additional documentation and a perl script that may be used for
this purpose available for anonymous ftp from:

ftp.is.co.za : /networking/ip/dns/gencidrzone/gencidrzone

-----------------------------------------------------------------------------

Question 5.6.  Recommended format/style of DNS files

Date: Sun Nov 27 23:32:41 EST 1994

This answer is quoted from an article posted by Paul Vixie:

   I've gone back and forth on the question of whether the BOG should
   include a section on this topic.  I know what I myself prefer, but
   I'm wary of ramming my own stylistic preferences down the throat of
   every BOG reader.  But since you ask :-)...

   Create /var/named.  If your system is too old to have a /var, either
   create one or use /usr/local/adm/named instead.  Put your named.boot
   in it, and make /etc/named.boot a symlink to it.  If your system
   doesn't have symlinks, you're S-O-L (but you knew that).  In
   named.boot, put a "directory" directive that specifies your actual
   BIND working directory:

        directory       /var/named

   All relative pathnames used in "primary", "secondary", and "cache"
   directives will be evaluated relative to this directory.  Create two
   subdirectories, /var/named/pri and /var/named/sec.  Whenever you add
   a "primary" directive to your named.boot, use "pri/WHATEVER" as the
   path name.  And then put the primary zone file into "pri/WHATEVER".
   Likewise when you add "secondary" directives, use "sec/WHATEVER" and
   BIND (really named-xfer) will create the files in that
   subdirectory.

   (Variations: (1) make a midlevel directory "zones" and put "pri" and
   "sec" into it; (2) if you tend to pick up a lot of secondaries from
   a few hosts, group them together in their own subdirectories --
   something like /var/named/zones/uucp if you're a UUCP Project name
   server.)

   For your forward files, name them after the zone.  dec.com becomes
   "/var/named/zones/pri/dec.com".  For your reverse files, name them
   after the network number.  0.1.16.in-addr.arpa becomes
   "/var/named/zones/pri/16.1.0".

   When creating or maintaining primary zone files, try to use the same
   SOA values everywhere, except for the serial number which varies per
   zone.  Put a $ORIGIN directive at the top of the primary zone file,
   not because its needed (it's not since the default origin is the
   zone named in the "primary" directive) but because it make it easier
   to remember what you're working on when you have a lot of primary
   zones.  Put some comments up there indicating contact information
   for the real owner if you're proxying.  Use RCS and put the "Id"
   in a ";" comment near the top of the zone file.

   The SOA and other top level information should all be listed
   together.  But don't put IN on every line, it defaults nicely.  For
   example:

==============
@       IN      SOA     gw.home.vix.com. postmaster.vix.com. (
                        1994082501      ; serial
                        3600    ; refresh (1 hour)
                        1800    ; retry (30 mins)
                        604800  ; expire (7 days)
                        3600 )  ; minimum (1 hour)

                NS      gw.home.vix.com.
                NS      ns.uu.net.
                NS      uucp-gw-1.pa.dec.com.
                NS      uucp-gw-2.pa.dec.com.

                MX      10 gw.home.vix.com.
                MX      20 uucp-gw-1.pa.dec.com.
                MX      20 uucp-gw-1.pa.dec.com.
==============

   I don't necessarily recommend those SOA values.  Not every zone is
   as volatile as the example shown.  I do recommend that serial number
   format; it's in date format with a 2-digit per-day revision number.
   This format will last us until 2147 A.D. at which point I expect a
   better solution will have been found :-).  (Note that it would last
   until 4294 A.D. except that there are some old BINDs out there that
   use a signed quantity for representing serial number internally; I
   suppose that as long as none of these are still running after 2047
   A.D., that we can use the above serial number format until 4294
   A.D., at which point a better solution will HAVE to be found.)

   You'll note that I use a tab stop for "IN" even though I never again
   specify it.  This leaves room for names longer than 7 bytes without
   messing up the columns.  You might also note that I've put the MX
   priority and destination in the same tab stop; this is because both
   are part of the RRdata and both are very different from MX which is
   an RRtype.  Some folks seem to prefer to group "MX" and the priority
   together in one tab stop.  While this looks neat it's very confusing
   to newcomers and for them it violates the law of least
   astonishment.

   If you have a multi-level zone (one which contains names that have
   dots in them), you can use additional $ORIGIN statements but I
   recommend against it since there is no "back" operator.  That is,
   given the above example you can add:

=============
$ORIGIN home
gw              A       192.5.5.1
=============

   The problem with this is that subsequent RR's had better be
   somewhere under the "home.vix.com" name or else the $ORIGIN that
   introduces them will have to use a fully qualified name.  FQDN
   $ORIGIN's aren't bad and I won't be mad if you use them.
   Unqualified ones as shown above are real trouble.  I usually stay
   away from them and just put the whole name in:

=============
gw.home         A       192.5.5.1
=============

   In your reverse zones, you're usually in some good luck because the
   owner name is usually a single short token or sometimes two.

=============
$ORIGIN 5.5.192.in-addr.arpa.
@       IN      SOA     ...
                NS      ...
1               PTR     gw.home.vix.com.
=========================================
$ORIGIN 1.16.in-addr.arpa.
@       IN      SOA     ...
                NS      ...
2.0             PTR     gatekeeper.dec.com.
=============

   It is usually pretty hard to keep your forward and reverse zones in
   sync.  You can avoid that whole problem by just using "h2n" (see
   the ORA book, DNS and BIND, and its sample toolkit, included in the
   BIND distribution or on ftp.uu.net (use the QUOTE SITE EXEC INDEX
   command there to find this -- I never can remember where it's at).
   "h2n" and many tools like it can just read your old /etc/hosts file
   and churn it into DNS zone files.  (May I recommend
   contrib/decwrl/mkdb.pl from the BIND distribution?)  However, if you
   (like me) prefer to edit these things by hand, you need to follow
   the simple convention of making all of your holes consistent.  If
   you use 192.5.5.1 and 192.5.5.3 but not (yet) 192.5.5.2, then in
   your forward file you will have something like

=============
...
gw.home         A       192.5.5.1
;avail          A       192.5.5.2
pc.home         A       192.5.5.3
=============

   and in your reverse file you will have something like

=============
...
1               PTR     gw.home.vix.com.
;2              PTR     avail
3               PTR     pc.home.vix.com.
=============

   This convention will allow you to keep your sanity and make fewer
   errors.  Any kind of automation (h2n, mkdb, or your own
   perl/tcl/awk/python tools) will help you maintain a consistent
   universe even if it's also a complex one.  Editing by hand doesn't
   have to be deadly but you MUST take care.

-----------------------------------------------------------------------------

Question 5.7.  DNS on a system not connected to the Internet

Date: Sun Nov 27 23:32:41 EST 1994

You need to create your own root domain name server until you connect  to
the internet.  Your roots need to delegate to mydomain.com and any
in-addr.arpa subdomains you might have, and that's about it.  As soon as
you're connected, rip out the fake roots and use the real ones.

It does not actually have to be another server pretending to be the root.
You can set up the name server so that it is primary for each domain above
you and leave them empty (i.e. you are foo.bar.com - claim to be primary
for bar.com and com)

If you connect intermittently and want DNS to work when you are connected,
and "fail" when you are not, you can point the resolver at the name server
at the remote site and if the connection (SLIP/PPP) isn't up, the resolver
doesn't have a route to the remote server and since there's only one name
server in resolv.conf, the resolver quickly backs off the using
/etc/hosts.  No problem.  You could do the same with multiple name server
and a resolver that did configurable /etc/hosts fallback.

-----------------------------------------------------------------------------

Question 5.8.  Multiple Domain configuration

Date: Fri Dec  2 15:40:49 EST 1994

If you want to have multiple domain names pointing to the same
destination, such as:

      ftp ftp.biff.com connects user to -> ftp.biff.com
      ftp ftp.fred.com connects user to -> ftp.biff.com
      ftp ftp.bowser.com connects user to -> ftp.biff.com

You may do this by using CNAMEs:

      ftp.bowser.com.         IN      CNAME ftp.biff.com.

You can also do the same thing with multiple A records.

-----------------------------------------------------------------------------

Question 5.9.  wildcard MX records

Date: Sun Nov 27 23:32:41 EST 1994

Does BIND not understand wildcard MX records such as the following?

     *.foo.com       MX      0       mail.foo.com.

No. It just doesn't work.

Explicit RR's at one level of specificity will, by design, "block" a
wildcard at a lesser level of specificity. I suspect that you have an RR
(an A RR, perhaps?) for "bar.foo.com" which is blocking the application of
your "*.foo.com" wildcard. The initial MX query is thus failing (NOERROR
but an answer count of 0), and the backup query finds the A RR for
"bar.foo.com" and uses it to deliver the mail directly (which is what you
DIDN'T want it to do).  Adding an explicit MX RR for the host is therefore
the right way to handle this situation.

See RFC 1034, Section 4.3.3 ("Wildcards") for more information on this
"blocking" behavior, along with an illustrative example. See also RFC 974
for an explanation of standard mailer behavior in the face of an "empty"
response to one's MX query.

Basically, what it boils down to is, there is no point in trying to use a
wildcard MX for a host which is otherwise listed in the DNS.

It just doesn't work.

-----------------------------------------------------------------------------

Question 5.10.  How do you identify a wildcard MX record ?

Date: Thu Dec  1 11:10:39 EST 1994

You don't really need to "identify" a wildcard MX RR.  The precedence  for
u@dom is:

        exact match MX
        exact match A
        wildcard MX

One way to implement this is to query for ("dom",IN,MX) and if the answer
name that comes back is "*." something, you know it's a wildcard,
therefore you know there is no exact match MX, and you therefore query for
("dom",IN,A) and if you get something, use it.  if you don't, use the
previous wildcard response.

RFC 974 explains this pretty well.

-----------------------------------------------------------------------------

Question 5.11.  Why are fully qualified domain names recommended ?

Date: Sun Nov 27 23:32:41 EST 1994

The documentation for BIND 4.9.2 says that the hostname should be set  to
the full domain style name (i.e host.our.domain rather than host).  What
advantages are there in this, and are there any adverse consequences if we
don't?

Paul Vixie likes to do it :-)  He lists a few reasons -

* Sendmail can be configured to just use Dj$w rather than Dj$w.mumble
  where "mumble" is something you have to edit in by hand.  Granted, most
  people use "mumble" elsewhere in their config files ("tack on local
  domain", etc) but why should it be a requirement ?
* The real reason is that not doing it violates a very useful invariant:
    gethostbyname(gethostname) == gethostbyaddr(primary_interface_address)

  If you take an address and go "backwards" through the PTR's with it,
  you'll get a FQDN, and if you push that back through the A RR's, you get
  the same address.  Or you should.  Many multi-homed hosts violate this
  uncaringly.

  If you take a non-FQDN hostname and push it "forwards" through the A
  RR's, you get an address which, if you push it through the PTR's, comes
  back as a FQDN which is not the same as the hostname you started with.
  Consider the fact that, absent NIS/YP, there is no "domainname" command
  analogous to the "hostname" command.  (NIS/YP's doesn't count, of
  course, since it's sometimes-but-only-rarely the same as the Internet
  domain or subdomain above a given host's name.)  The "domain" keyword in
  resolv.conf doesn't specify the parent domain of the current host; it
  specifies the default domain of queries initiated on the current host,
  which can be a very different thing.  (As of RFC 1535 and BIND 4.9.2's
  compliance with it, most people use "search" in resolv.conf, which
  overrides "domain", anyway.)

  What this means is that there is NO authoritative way to
  programmatically discover your host's FQDN unless it is set in the
  hostname, or unless every application is willing to grovel the "netstat
  -in" tables, find what it hopes is the primary address, and do a PTR
  query on it.

  FQDN /bin/hostnames are, intuitively or not, the simplest way to go.

-----------------------------------------------------------------------------

Question 5.12.  Distributing load using named

Date: Thu Jul 16 10:42:05 EDT 1998

When you attempt to distribute the load on a system using named, the first
response be cached, and then later queries use the cached value (This
would be for requests that come through the same server).  Therefore, it
can be useful to use a lower TTL on records where this is important.  You
can use values like 300 or 500 seconds.

If your local caching server has ROUND_ROBIN, it does not matter what the
authoritative servers have -- every response from the cache is rotated.

But if it doesn't, and the authoritative server site is depending on this
feature (or the old "shuffle-A") to do load balancing, then if one doesn't
use small TTLs, one could conceivably end up with a really nasty
situation, e.g., hundreds of workstations at a branch campus pounding on
the same front end at the authoritative server's site during class
registration.

Not nice.

Paul Vixie has an example of the ROUND_ROBIN code in action.  Here is
something that he wrote regarding his example:

     I want users to be distributed evenly among those 3 hosts.

     Believe it or not :-), BIND offers an ugly way to do this.  I offer
     for your collective amusement the following snippet from the
     ugly.vix.com zone file:

       hydra           cname        hydra1
                       cname        hydra2
                       cname        hydra3
       hydra1          a            10.1.0.1
                       a            10.1.0.2
                       a            10.1.0.3
       hydra2          a            10.2.0.1
                       a            10.2.0.2
                       a            10.2.0.3
       hydra3          a            10.3.0.1
                       a            10.3.0.2
                       a            10.3.0.3

      Note that having multiple CNAME RR's at a given name is
      meaningless according to the DNS RFCs but BIND doesn't mind (in
      fact it doesn't even complain).  If you call
      gethostbyname("hydra.ugly.vix.com") (try it!) you will get
      results like the following.  Note that there are two round robin
      rotations going on: one at ("hydra",CNAME) and one at each
      ("hydra1",A) et al.  I used a layer of CNAME's above the layer of
      A's to keep the response size down.  If you don't have nine
      addresses you probably don't care and would just use a pile of
      CNAME's pointing directly at real host names.

      {hydra.ugly.vix.com
      name: hydra2.ugly.vix.com
      aliases: hydra.ugly.vix.com
      addresses: 10.2.0.2 10.2.0.3 10.2.0.1

      {hydra.ugly.vix.com
      name: hydra3.ugly.vix.com
      aliases: hydra.ugly.vix.com
      addresses: 10.3.0.2 10.3.0.3 10.3.0.1

      {hydra.ugly.vix.com
      name: hydra1.ugly.vix.com
      aliases: hydra.ugly.vix.com
      addresses: 10.1.0.2 10.1.0.3 10.1.0.1

      {hydra.ugly.vix.com
      name: hydra2.ugly.vix.com
      aliases: hydra.ugly.vix.com
      addresses: 10.2.0.3 10.2.0.1 10.2.0.2

      {hydra.ugly.vix.com
      name: hydra3.ugly.vix.com
      aliases: hydra.ugly.vix.com
      addresses: 10.3.0.3 10.3.0.1 10.3.0.2

Please note that this is not a recommended practice and will not work with
modern BIND unless you have the entry "multiple-cnames yes" in your
named.conf file.

-----------------------------------------------------------------------------

Question 5.13.  Round robin IS NOT load balancing

Date: Mon Mar  9 22:10:51 EST 1998

Round robin != load balancing. It's a very crude attempt at load
balancing, and a method that is possible without breaking DNS protocols.
If a host  is down that is included in a round robin list, then
connections to that  particular host will fail.  In addition, true load
balancing should take  into consideration the actual LOAD on the system.

Information on one such technique, implemented by Roland J. Schemers III
at Stanford, may be found at
http://www-leland.stanford.edu/~schemers/docs/lbnamed/lbnamed.html.

Additional information may be found in RFC 1794.  MultiNet for OpenVMS
also includes this feature.

-----------------------------------------------------------------------------

Question 5.14.  Order of returned records

Date: Tue Apr  8 20:21:02 EDT 1997

Sorting, is the *resolver's* responsibility.  RFC 1123:

         6.1.3.4  Multihomed Hosts

            When the host name-to-address function encounters a host
            with multiple addresses, it SHOULD rank or sort the
            addresses using knowledge of the immediately connected
            network number(s) and any other applicable performance or
            history information.

            DISCUSSION:
                 The different addresses of a multihomed host generally
                 imply different Internet paths, and some paths may be
                 preferable to others in performance, reliability, or
                 administrative restrictions.  There is no general way
                 for the domain system to determine the best path.  A
                 recommended approach is to base this decision on local
                 configuration information set by the system
                 administrator.

In BIND 4.9.x's resolver code, the "sortlist" directive in resolv.conf
can be used to configure this.  The directive may also be used in the
named.boot as well.

-----------------------------------------------------------------------------

Question 5.15.  resolv.conf

Date: Fri Feb 10 15:46:17 EST 1995

The question was asked one time, "Why should I use 'real' IP addresses in
/etc/resolv.conf and not 0.0.0.0 or 127.0.0.1" ?

Paul Vixie writes on the issue of the contents of resolv.conf:

   It's historical.  Some kernels can't unbind a UDP socket's source
   address, and some resolver versions (notably not including BIND
   4.9.2 or 4.9.3's) try to do this.  The result can be wide area
   network traffic with 127.0.0.1 as the source address.  Rather than
   giving out a long and detailed map of version/vendor combinations of
   kernels/BINDs that have/don't this problem, I just tell folks not to
   use 127.0.0.1 at all.

   0.0.0.0 is just an alias for the first interface address assigned
   after a system boot, and if that interface is a up-and-down point to
   point link (PPP, SLIP, whatever), there's no guarantee that you'll
   be able to reach yourself via 0.0.0.0 during the entire lifetime of
   any system instance.  On most kernels you can finesse this by adding
   static routes to 127.0.0.1 for each of your interface addresses, but
   some kernels don't like that trick and rather than give a detailed
   map of which ones work and which ones don't, I just globally
   recommend against 0.0.0.0.

   If you know enough to know that 127.0.0.1 or 0.0.0.0 is safe on your
   kernel and resolver, then feel free to use them.  If you don't know
   for sure that it is safe, don't use them.  I never use them (except
   on my laptop, whose hostname is "localhost" and whose 0.0.0.0 is
   127.0.0.1 since I ifconfig my lo0 before any other interface).  The
   operational advantage to using a real IP address rather than an
   wormhole like 0.0.0.0 or 127.0.0.1, is that you can then "rdist" or
   otherwise share identical copies of your resolv.conf on all the
   systems on any given subnet, not all of which will be servers.

The problem was with older versions of the resolver (4.8.X).  If you
listed 127.0.0.1 as the first entry in resolv.conf, and for whatever
reason the local name server wasn't running and the resolver fell back to
the second name server listed, it would send queries to the name server
with the source IP address set to 127.0.0.1 (as it was set when the
resolver was trying to send to 127.0.0.1--you use the loopback address to
send to the loopback address).

-----------------------------------------------------------------------------

Question 5.16.  How do I delegate authority for sub-domains ?

Date: Mon Nov 10 22:57:54 EST 1997

When you start having a very big domain that can be broken into logical
and separate entities that can look after their own DNS information, you
will probably want to do this.  Maintain a central area for the things
that everyone needs to see and delegate the authority for the other parts
of the organization so that they can manage themselves.

Another essential piece of information is that every domain that exists
must have it NS records associated with it.  These NS records denote the
name servers that are queried for information about that zone.  For your
zone to be recognized by the outside world, the server responsible for the
zone above you must have created a NS record for your your new servers
(NOTE that the new servers DO NOT  have to be in the new domain).  For
example, putting the computer club onto the network and giving them
control over their own part  of the domain space we have the following.

The machine authorative for gu.uwa.edu.au is mackerel and the machine
authorative for ucc.gu.uwa.edu.au is marlin.

in mackerel's data for gu.uwa.edu.au we have the following

   @               IN      SOA ...
                   IN      A       130.95.100.3
                   IN      MX      mackerel.gu.uwa.edu.au.
                   IN      MX      uniwa.uwa.edu.au.

   marlin          IN      A       130.95.100.4

   ucc             IN      NS      marlin.gu.uwa.edu.au.
                   IN      NS      mackerel.gu.uwa.edu.au.

Marlin is also given an IP in our domain as a convenience.  If they blow
up their name serving there is less that can go wrong because people can
still see that machine which is a start.  You could place "marlin.ucc" in
the first column and leave the machine totally inside the ucc domain as
well.

The second NS line is because mackerel will be acting as secondary name
server for the ucc.gu domain.  Do not include this line if you are not
authorative for the information included in the sub-domain.

To delegate authority for PTR records, the same concepts apply.

   stub 10.168.192.in-addr.arpa  db.192.168.10

may be added to your primary server's named.boot in recent versions of
bind.  In other versions (and recent ones :-) ), the following lines may
be added  to the db.192.168.10 zone file to perform the same function:

   xxx IN NS 
   xxx IN NS 
   xxx IN NS    ; if needed
...
   xxx IN NS    ; if needed

-----------------------------------------------------------------------------

Question 5.17.  DNS instead of NIS on a Sun OS 4.1.x system

Date: Sat Dec  7 01:14:17 EST 1996

Comments relating to running bind 4.9.x on a Sun OS 4.1.x system and the
effect on sendmail, ftp, telnet and other TCP/IP services bypassing NIS
and directly using named is documented quite well in the
comp.sys.sun.admin FAQ in questions one and two.  You can get them from:

* ftp.ece.uc.edu : /pub/sun-faq/FAQs/sun-faq.general
* http://www.cis.ohio-state.edu/hypertext/faq/usenet/comp-sys-sun-faq

as well as from rtfm.mit.edu in the usual place, etc.

-----------------------------------------------------------------------------

Question 5.18.  Patches to add functionality to BIND

Date: Wed Jan 14 11:57:20 EST 1998

There are others, but these are listed here:

* When using the round robin DNS and assigning 3 IPs to a host (for
  example), a process to guarantee that all 3 IPs are reachable may be
  found  at
  http://www-leland.stanford.edu/~schemers/docs/lbnamed/lbnamed.html

* Patches for 4.9.3-REL that will support the IPv6 AAAA record format may
  be  found at ftp.inria.fr : /network/ipv6/

  This is built into more recent versions of BIND (after 4.9.5?)

* A patch for 4.9.3-REL that will allow you to turn off forwarding of
  information from my server may be found at ftp.vix.com :
  /pub/bind/release/4.9.3/contrib/noforward.tar.gz

  Also look at

  ftp.is.co.za : /networking/ip/dns/bind/contrib/noforward.tar.gz

* How do I tell a server to listen to a particular interface to listen and
  respond to DNS queries on ?

  Mark Andrews has a patch that will tell a 4.9.4 server to listen to a
  particular interface and respond to DNS queries.  It may be found at an
  unofficial location: http://www.ultra.net/~jzp/andrews.patch.txt

  This is built into BIND 8.1.1.

* A patch to implement "selective forwarding" from Todd Aven at
  http://www.dns.net/dnsrd/servers.html.

-----------------------------------------------------------------------------

Question 5.19.  How to serve multiple domains from one server

Date: Tue Nov  5 23:44:02 EST 1996

Most name server implementations allow information about multiple domains
to be kept on one server, and questions about those domains  to be
answered by that one server.  For instance, there are many large  servers
on the Internet that each serve information about more than  1000
different domains.

To be completely accurate, a server contains information about zones,
which are parts of domains that are kept as a single unit.  [Ed note: for
a definition of zones and domains, see Section 2: The Name Service in the
"Name Server Operations Guide" included with the BIND 4.9.5 distribution.]

In the configuration of the name server, the additional zones need to be
specified.  An important consideration is whether a particular server is
primary or secondary for any specific zone--a secondary server maintains
only a copy of the zone, periodically refreshing its copy from another,
specified, server.  In BIND, to set up a server as a secondary server for
the x.y.z zone, to the configuration file /etc/named.boot add the line

      secondary   x.y.z   10.0.0.1        db.x.y.z

where 10.0.0.1 is the IP address of the server that the zone will be
copied from, and db.x.y.z is a local filename that will contain the copy
of the zone.

If this is a question related to how to set up multiple IP numbers on one
system, which you do not need to do to act as a domain server for
multiple domains, see

http://www.thesphere.com/%7Edlp/TwoServers/.

-----------------------------------------------------------------------------

Question 5.20.  hostname and domain name the same

Date: Wed Jul  9 21:47:36 EDT 1997

Q: I have a subdomain sub.foobar.com. I would like to name a host
sub.foobar.com. It should also be the mail relay for all hosts in
sub.foobar.com. How do I do this ?

A: You would add an A record for sub.foobar.com, and multiple MX records
pointing to this host (sub.foobar.com).  For example:

sub.foobar.com.         IN      A       1.2.3.4 ; address of host
;
foo.sub.foobar.com.     IN      MX      10 sub.foobar.com.
bar.sub.foobar.com.     IN      MX      10 sub.foobar.com.

The host, sub.foobar.com, may also need to be to configured to understand
that mail addressed to user@sub.foobar.com and possibly other sub.foobar.com 
hosts should be treated as local.

-----------------------------------------------------------------------------

Question 5.21.  Restricting zone transfers

Date: Wed Jan 14 12:16:35 EST 1998

Q: How do I restrict my zone transfers to my secondaries or other trusted
hosts?

A: Use the 'xfrnets' directive within the named.boot file or  the
'secure_zone' TXT RR within a zone file.  The BOG has more information on
both of these options.

As an example within an 4.9.x named.boot file:

   xfernets 10.1.2.0&255.255.255.0 44.66.10.0&255.255.255.0 

Only Nameservers on these networks will be able to do zone transfers from
the server with this configuration.

Please note that 'secure_zone' restricts all access to the containing
zone, as well as restricting zone transfers :-) .

BIND 8.x supports restricting zone transfers on a per-zone basis in  the
named.conf file, whereas BIND 4.9.x only supports xfrnets as a global
option.

-----------------------------------------------------------------------------

Question 5.22.  DNS in firewalled and private networks

Date: Mon Sep 14 22:15:16 EDT 1998

(The following section was contributed by Berislav Todorovic)

When talking about private networks, we distinguish between two cases:

* Networks consisting of firewall-separated private and public subnetworks

  * Same domain name used in private and public part of the network
  * Different domain names used in the public and private subnetwork

* Closed networks, not connected the Internet at all

* The first case of the  "Same domain name", we're talking about DNS
  configuration, usually referred to as "split DNS". In this case, two
  different DNS servers (or two separate DNS processes on the same
  multi-homed machine) have to be configured. One of them ("private DNS")
  will serve the internal network and will contain data about all hosts in
  the private part of the network. The other one ("public DNS") will serve
  Internet users and will contain only the most necessary RR's for
  Internet users (like MX records for email exchange, A and CNAME records
  for public Web servers, records for other publicly accessible hosts
  etc.). Both of them will be configured as primary for the same corporate
  domain (e.g.  DOMAIN.COM).  The public DNS will be delegated with the
  appropriate NIC as authoritative for domain DOMAIN.COM.

  Private DNS - resolves names from DOMAIN.COM for hosts inside the
  private network. If asked for a name outside DOMAIN.COM, they should
  forward the request to the public DNS (forwarders line should be used in
  the boot file).  They should NEVER contact a root DNS on the Internet.
  The boot file for the private DNS should, therefore, be:

    primary            domain.com              ZONE.domain.com
    primary            1.10.in-addr.arpa       REV.10.1
    forwarders         172.16.12.10
    slave
  Public DNS - resolves names from DOMAIN.COM for hosts on the public part
  of the network. If asked for a name outside DOMAIN.COM they should
  contact root DNS servers or (optionally) forward the request to a
  forwarder on the ISP network. Boot file for the public DNS should be of
  the form:

    primary            domain.com              ZONE.domain.com
    primary            12.16.172.in-addr.arpa  REV.172.16.12
    ... (other domains)
  Zone files for domain DOMAIN.COM on the public and private DNS should
  be:

   ; --- Public DNS - zone file for DOMAIN.COM

   domain.com.        IN   SOA   ns.domain.com. hostmaster.domain.com. ( ... )
                      IN   NS    ns.domain.com.
                      IN   NS    ns.provider.net.
                      IN   MX    10     mail.provider.net.

   ns                 IN   A     172.16.12.10
   www                IN   A     172.16.12.12
   ftp                IN   A     172.16.12.13
   ...

   ; --- Private DNS - zone file for DOMAIN.COM

   domain.com.        IN   SOA   ns1.domain.com. hostmaster.domain.com. ( ... )
                      IN   NS    ns1.domain.com.
                      IN   NS    ns2.domain.com.
   wks1-1             IN   A     10.1.1.1
   wks1-2             IN   A     10.1.1.2
   ...

  The second case of the  "Same domain name", is simpler than the previous
  case: in the internal network, a separate domain name might be used.
  Recommended domain name syntax is "name.local" (e.g. DOMAIN.LOCAL).
  Sample configuration:

   ; --- Private DNS - named.boot

   primary       domain.local           ZONE.domain.local
   ...
   forwarders    172.16.12.10
   slave

   ; --- Public DNS - named.boot

   primary       domain.com             ZONE.domain.com
   ...
  IMPLEMENTATION NOTES

  Location of the DNS service in both cases is irrelevant. Usually, they
  are located on two different physical servers, each of them connected to
  the appropriate part of the network (private, public). Certain savings
  may be done if public DNS service is hosted on the ISP network - in that
  case, the user will need only one (private) DNS server.

  Finally, both public and private DNS, in some cases, may be placed on
  the servers in the private network, behind the firewall. With a Cisco
  PIX, a statical public/private IP address mapping in this case would be
  needed.  Two servers for the same domain could be even placed on the
  same physical server, with two different DNS processes running on
  different IP interfaces.  Note that BIND 8 is needed in the latter case.

* If the network is not connected to the Internet at all, only private DNS
  servers are needed. However, due to the lack of Internet connectivity,
  internal servers will fail to contact the root DNS servers every time a
  user types, by mistake, an address outside the corporate domain
  DOMAIN.COM.  Some older servers won't even work if they can't reach root
  servers. To overcome this, it is most proper to create a so-called "fake
  root zone" on one or more DNS servers in the corporation. That would
  make all DNS servers within the corporation think there is only one or
  two DNS servers in the world, all located on the corporation network.
  Only domain names used within the corporation (DOMAIN.COM, appropriate
  inverse domains etc.) should be entered in the fake root zone file. Note
  that no cache line in the boot file of the "root" DNS makes sense.
  Sample configuration:

   ; --- named.boot

   primary     domain.com         ZONE.domain.com
   primary     1.10.in-addr.arpa  REV.10.1
   priamry     .                  ZONE.root
   ... (other data; NOTE - do *NOT* place any "cache" line here !!!)

   ; --- ZONE.root - fake root zone file, containing only corporation domains

   .                   IN NS  ns.domain.com.  hostmaster.domain.com.  ( ... )
                       IN NS  ns.domain.com.
                       IN NS  ns2.domain.com.

   domain.com.         IN NS  ns.domain.com.
   ns.domain.com.      IN  A  10.1.1.1
   domain.com.         IN NS  ns2.domain.com.
   ns2.domain.com.     IN  A  10.1.1.2

   1.10.in-addr.arpa.  IN NS  ns.domain.com.
                       IN NS  ns2.domain.com.

  Other zone files follow standard configuration.

-----------------------------------------------------------------------------

Question 5.23.  Different DNS answers for same RR

Date: Mon Sep 14 22:15:16 EDT 1998

(The following section was contributed by Berislav Todorovic)

Many times there is a need for a DNS server to send different answers for
same RR's, depending on the IP address of the request sender. For example,
many coprporations wish to make their customers to use the "geographically
closest" Web server when accessing corporate Web pages. A corporation may
impose the following policy: if someone asked for the IP address of
WWW.DOMAIN.COM, they may want to:

* Answer that the IP address is 172.16.2.3, if the request came from one
  of the following IP networks: 172.1/16, 172.2/16 or 172.10/16.
* Answer that the IP address is 172.16.1.1, if the request came from the
  IP address 172.16/16 or 172.17.128/18.
* By default, for all other requests send the answer that the IP address
  is  172.16.2.3.

The example above will need a DNS to send different A RR's, depending on
the source of queries. A similar approach may be imposed for MX's, CNAME's
etc. The question which arise here is: IS IT POSSIBLE?

[Ed note: There are commercial products such as Cisco's Distributed
Director that also will address this issue]

The simple answer to the question is: NOT DIRECTLY.  This is true if
standard DNS software (e.g. BIND) is used on the DNS servers.  However,
there are two workarounds which may solve this problem:

* Using two DNS servers on different UDP ports + UDP redirector
* Using two DNS servers on different IP addresses + NAT on the router

Solution 1: (tested on a Linux system and should work on other Unix boxes
as well). Software needed is:

* BIND 8
* udprelay - a package which redirects traffic to other UDP port
  (sunsite.unc.edu: /pub/Linux/system/network/misc/udprelay-0.2.tar.Z ).

Build and install udprelay and bring up two DNS servers on different UDP
ports, using different configuration files (i.e., bring one on 5300 and
the other one on 5400):

   // --- named.conf.5300
   options {
        directory "/var/named"
        listen-on port 5300 { any; };
        ... (other options)
      };

   zone "domain.com" {
        type master;
        file "domain.com.5300";
      };

   // --- named.conf.5400

   options {
        directory "/var/named"
        listen-on port 5400 { any; };
        ... (other options)
      };

   zone "domain.com" {
        type master;
        file "domain.com.5400";
      };

   ; domain.com.5300
   ... (SOA and other stuff)

   www          IN     A     172.16.2.3

   ; --- domain.com.5400
   ... (SOA and other stuff)

   www          IN     A     172.16.1.1

As can be seen, there will be two separate zone files for DOMAIN.COM,
depending on which UDP port the server listens to.  Each zone file can
contain different records.  Now, when configure udprelay to forward  UDP
traffic from port 53 to 5300 or 5400, depending on the remote  IP address:

   relay  172.1.0.0  mask 255.255.0.0 * 53   172.16.1.1 5300 53
   relay  172.2.0.0  mask 255.255.0.0 * 53   172.16.1.1 5300 53
   relay  172.10.0.0 mask 255.255.0.0 * 53   172.16.1.1 5300 53
   relay  172.16.0.0 mask 255.255.0.0 * 53   172.16.1.1 5400 53
   relay  172.17.0.0 mask 255.255.0.0 * 53   172.16.1.1 5400 53
   relay  *                           * 53   172.16.1.1 5400 53
After starting udprelay, all traffic coming to port 53 will be redirected
to 5300 or 5400, depending on the source IP address.

NOTE - This solution deals with the UDP part of DNS only. Zone xfers will
be able to be done from one DNS server only, since this solution doesn't
deal the TCP part of DNS. This is, thus, a partial solution but it works!

Solution 2: Bring up two DNS servers on your network, using "private" IP
addresses (RFC 1918), say ns1.domain.com (10.1.1.1) and ns2.domain.com
(10.1.1.2). Both servers will have the same public address - 172.16.1.1,
which will be used to access the servers.  Configure them to be both
primary for domain DOMAIN.COM.  Let one of them (say, ns1) be the
"default" DNS, which will be used in most of the cases. Establish NAT on
the router, so it translates the public IP address 172.16.1.1 to 10.1.1.1
and delegate your "default" DNS with the appropriate NIC, using its public
address 172.16.1.1. Once you're assured everything works, setup your
router to translate the public IP address 172.16.1.1 to either 10.1.1.1 or
10.1.1.2, depending on the requestor IP address. After that, depending on
the source IP address, the router will return one translation or the
latter, thus forwarding the remote side to the appropriate DNS server.

===============================================================================

Section 6.  PROBLEMS

 Q6.1        No address for root server
 Q6.2        Error - No Root Nameservers for Class XX
 Q6.3        Bind 4.9.x and MX querying?
 Q6.4        Do I need to define an A record for localhost ?
 Q6.5        MX records, CNAMES and A records for MX targets
 Q6.6        Can an NS record point to a CNAME ?
 Q6.7        Nameserver forgets own A record
 Q6.8        General problems (core dumps !)
 Q6.9        malloc and DECstations
 Q6.10       Can't resolve names without a "."
 Q6.11       Why does swapping kill BIND ?
 Q6.12       Resource limits warning in system
 Q6.13       ERROR:ns_forw: query...learnt 
 Q6.14       ERROR:zone has trailing dot
 Q6.15       ERROR:Zone declared more then once
 Q6.16       ERROR:response from unexpected source
 Q6.17       ERROR:record too short from [zone name]
 Q6.18       ERROR:sysquery: findns error (3)
 Q6.19       ERROR:Err/TO getting serial# for XXX
 Q6.20       ERROR:zonename IN NS points to a CNAME
 Q6.21       ERROR:Masters for secondary zone [XX] unreachable
 Q6.22       ERROR:secondary zone [XX] expired
 Q6.23       ERROR:bad response to SOA query from [address]
 Q6.24       ERROR:premature EOF, fetching [zone]
 Q6.25       ERROR:Zone [XX] SOA serial# rcvd from [Y] is < ours
 Q6.26       ERROR:connect(IP/address) for zone [XX] failed
 Q6.27       ERROR:sysquery: no addrs found for NS
 Q6.28       ERROR:zone [name] rejected due to errors

-----------------------------------------------------------------------------

Question 6.1.  No address for root server

Date: Wed Jan 14 12:15:54 EST 1998

Q: I've been getting the following messages lately from bind-4.9.2..
        ns_req: no address for root server

We are behind a firewall and have the following for our named.cache file -

        ; list of servers
        .               99999999    IN  NS  POBOX.FOOBAR.COM.
                        99999999    IN  NS  FOOHOST.FOOBAR.COM.
        foobar.com.     99999999    IN  NS  pobox.foobar.com.

You can't do that.  Your nameserver contacts POBOX.FOOBAR.COM, gets the
correct list of root servers from it, then tries again and fails because
of your firewall.

You will need a 'forwarder' definition, to ensure that all requests are
forwarded to a host which can penetrate the firewall.  And it is unwise to
put phony data into 'named.cache'.

Q: We are getting logging information in the form:

Apr  8 08:05:22 gute named[107]: sysquery: no addrs found for root NS
                (A.ROOT-SERVERS.NET)
Apr  8 08:05:22 gute named[107]: sysquery: no addrs found for root NS
                (B.ROOT-SERVERS.NET)
Apr  8 08:05:22 gute named[107]: sysquery: no addrs found for root NS
                (C.ROOT-SERVERS.NET)  
...

We are running bind 4.9.5PL1 Our system IS NOT behind a firewall.  Any ideas ?

This was discussed on the mailing list in November of 1996.  The short
answer  was to ignore it as it was not a problem.  That being said,  you
should  upgrade to a newer version at this time if you are running a
non-current  version :-)

-----------------------------------------------------------------------------

Question 6.2.  Error - No Root Nameservers for Class XX

Date: Sun Nov 27 23:32:41 EST 1994

Q: I've received errors before about "No root nameservers for class XX"
   but they've been because of network connectivity problems.
   I believe that Class 1 is Internet Class data.
   And I think I heard someone say that Class 4 is Hesiod??
   Does anyone know what the various Class numbers are?

From RFC 1700:

       DOMAIN NAME SYSTEM PARAMETERS
       The Internet Domain Naming System (DOMAIN) includes several
       parameters.  These are documented in [RFC1034] and [RFC1035].  The
       CLASS parameter is listed here.  The per CLASS parameters are 
       defined in separate RFCs as indicated.

       Domain System Parameters:

       Decimal   Name                                          References
       --------  ----                                          ----------
              0  Reserved                                           [PM1]
              1  Internet (IN)                              [RFC1034,PM1]
              2  Unassigned                                         [PM1]
              3  Chaos (CH)                                         [PM1]
              4  Hesoid (HS)                                       [PM1]
        5-65534  Unassigned                                         [PM1]
          65535  Reserved                                           [PM1]

DNS information for RFC 1700 was taken from

ftp.isi.edu : /in-notes/iana/assignments/dns-parameters

Hesiod is class 4, and there are no official root nameservers for class 4,
so you can safely declare yourself one if you like.  You might want  to
put up a packet filter so that no one outside your network is capable  of
making Hesiod queries of your machines, if you define yourself to be  a
root nameserver for class 4.

-----------------------------------------------------------------------------

Question 6.3.  Bind 4.9.x and MX querying?

Date: Sun Nov 27 23:32:41 EST 1994

If you query a 4.9.x DNS server for MX records, a list of the MX records
as well as a list of the authorative nameservers is returned.  This
happens because bind 4.9.2 returns the list of nameserver that are
authorative for a domain in the response packet, along with their IP
addresses in the additional section.

-----------------------------------------------------------------------------

Question 6.4.  Do I need to define an A record for localhost ?

Date: Sat Sep  9 00:36:01 EDT 1995

Somewhere deep in the BOG (BIND Operations Guide) that came with 4.9.3
(section 5.4.3), it says that you define this yourself  (if need be) in
the same zone files as your "real" IP addresses  for your domain.  Quoting
the BOG:

                                 ... As  implied by this PTR
         record, there should be a  ``localhost.my.dom.ain''
         A  record  (with address 127.0.0.1) in every domain
         that contains hosts.  ``localhost.'' will lose  its
         trailing dot when 1.0.0.127.in-addr.arpa is queried
         for;...

The sample files in the BIND distribution show you what needs to be done
(see the BOG).

Some HP boxen (especially those running HP OpenView) will also need
"loopback" defined with this IP address.   You may set it as a CNAME
record pointing to the "localhost." record.

-----------------------------------------------------------------------------

Question 6.5.  MX records, CNAMES and A records for MX targets

Date: Sun Nov 27 23:32:41 EST 1994

The O'Reilly "DNS and Bind" book warns against using non-canonical names
in MX records, however, this warning is given in the context of mail hubs
that MX to each other for backup purposes.  How does this apply to mail
spokes.  RFC 974 has a similar warning, but where is it specifically
prohibited to us an alias in an MX record ?

Without the restrictions in the RFC, a MTA must request the A records  for
every MX listed to determine if it is in the MX list then reduce the list.
This introduces many more lookups than would other wise be required. If
you are behind a 1200 bps link YOU DON'T WANT TO DO THIS. The addresses
associated with CNAMES are not passed as additional data so you will force
additional traffic to result even if you are running a caching server
locally.

There is also the problem of how does the MTA find all of it's IP
addresses. This is not straight forward. You have to be able to do this is
you allow CNAMEs (or extra A's) as MX targets.

The letter of the law is that an MX record should point to an A record.

There is no "real" reason to use CNAMEs for MX targets or separate As for
nameservers any more. CNAMEs for services other than mail should be used
because there is no specified method for locating the desired server yet.

People don't care what the names of MX targets are.  They're invisible to
the process anyway.  If you have mail for "mary" redirected to "sue" is
totally irrelevant.  Having CNAMEs as the targets of MX's just needlessly
complicates things, and is more work for the resolver.

Having separate A's for nameservers like "ns.your.domain" is pointless
too, since again nobody cares what the name of your nameserver is, since
that too is invisible to the process.  If you move your nameserver from
"mary.your.domain" to "sue.your.domain" nobody need care except you and
your parent domain administrator (and the InterNIC).  Even less so for
mail servers, since only you are affected.

Q: Given the example - 

     hello in cname     realname
     mailx in mx        0 hello

   Now, while reading the operating manual of bind it clearly states
   that this is *not* valid.  These two statements clearly contradict
   each other.  Is there some later RFC than 974 that overrides what is
   said in there with respect to MX and CNAMEs?  Anyone have the
   reference handy?

A: This isn't what the BOG says at all.  See below.  You can have a CNAME 
   that points to some other RR type; in fact, all CNAMEs have to point
   to other names (Canonical ones, hence the C in CNAME).  What you
   can't have is an MX that points to a CNAME.  MX RR's that point to
   names which have only CNAME RR's will not work in many cases, and
   RFC 974 intimates that it's a bad idea:

      Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
      a alias and the alias is listed in the MX records for REMOTE.  (E.g.
      REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL).  This
      can be avoided if aliases are never used in the data section of MX
      RRs.

   Here's the relevant BOG snippet:

         aliases    {ttl   addr-class   CNAME   Canonical name
         ucbmonet           IN           CNAME   monet

         The  Canonical  Name resource record, CNAME, speci-
         fies an alias or  nickname  for  the  official,  or
         canonical,  host  name.   This record should be the
         only one associated with the alias name.  All other
         resource  records  should  be associated  with the
         canonical  name,  not  with  the   nickname.  Any
         resource  records  that  include  a  domain name as
         their value (e.g., NS or MX) must list the  canoni-
         cal name, not the nickname.

-----------------------------------------------------------------------------

Question 6.6.  Can an NS record point to a CNAME ?

Date: Wed Mar  1 11:14:10 EST 1995

Can I do this ?  Is it legal ?

   @                       SOA     (.........)
                           NS      ns.host.this.domain.
                           NS      second.host.another.domain.
   ns                      CNAME   third
   third           IN      A       xxx.xxx.xxx.xxx

No.  Only one RR type is allowed to refer, in its data field, to a CNAME,
and that's CNAME itself.  So CNAMEs can refer to CNAMEs but  NSs and MXs
cannot.

BIND 4.9.3 (Beta11 and later) explicitly syslogs this case rather than
simply failing as pre-4.9 servers did.  Here's a current example:

      Dec  7 00:52:18 gw named[17561]: "foobar.com IN NS" \
             points to a CNAME (foobar.foobar.com)

Here is the reason why:

Nameservers are not required to include CNAME records in the Additional
Info section returned after a query.  It's partly an implementation
decision and partly a part of the spec.  The algorithm described in RFC
1034 (pp24,25; info also in RFC 1035, section 3.3.11, p 18) says 'Put
whatever addresses are available into the additional section, using glue
RRs [if necessary]'.  Since NS records are speced to contain only primary
names of hosts, not CNAMEs, then there's no reason for algorithm to
mention them. If, on the other hand, it's decided to allow CNAMEs in NS
records (and indeed in other records) then there's no reason that CNAME
records might not be included along with A records.  The Additional Info
section is intended for any information that might be useful but which
isn't strictly the answer to the DNS query processed.  It's an
implementation decision in as much as some servers used to follow CNAMEs
in  NS references.

-----------------------------------------------------------------------------

Question 6.7.  Nameserver forgets own A record

Date: Fri Dec  2 16:17:31 EST 1994

Q: Lately, I've been having trouble with named 4.9.2 and 4.9.3.  
   Periodically, the nameserver will seem to "forget" its own A record,
   although the other information stays intact.  One theory I had was
   that somehow a site that the nameserver was secondary for was
   "corrupting" the A record somehow.

A: This is invariably due to not removing ALL of the cached zones
   when you moved to 4.9.X. Remove ALL cached zones and restart
   your nameservers.

   You get "ignoreds" because the primaries for the relevant zones are
   running old versions of BIND which pass out more glue than is
   required. named-xfer trims off this extra glue.

-----------------------------------------------------------------------------

Question 6.8.  General problems (core dumps !)

Date: Sun Dec  4 22:21:22 EST 1994

Paul Vixie says:

   I'm always interested in hearing about cases where BIND dumps core.
   However, I need a stack trace.   Compile with -g and not -O (unless
   you are using gcc and know what you are doing) and then when it
   dumps core, get into dbx or gdb using the executable and the core
   file and use "bt" to get a stack trace.   Send it to me
   <paul@vix.com> along with specific circumstances leading to or
   surrounding the crash (test data, tail of the debug log, tail of the
   syslog... whatever matters) and ideally you should save your core
   dump for a day or so in case I have questions you can answer via
   gdb/dbx.

-----------------------------------------------------------------------------

Question 6.9.  malloc and DECstations

Date: Mon Jan  2 14:19:22 EST 1995

We have replaced malloc on our DECstations with a malloc that is more
compact in memory usage, and this helped the operation of bind a lot.  The
source is now available for anonymous ftp from

ftp.cs.wisc.edu : /pub/misc/malloc.tar.gz

-----------------------------------------------------------------------------

Question 6.10.  Can't resolve names without a "."

(Answer written by Mark Andrews) You are not using a RFC 1535 aware
resolver. Depending upon the age of your resolver you could try  adding a
search directive to resolv.conf.

 e.g.
 domain 
 search  [ ...]

If that doesn't work you can configure you server to serve the parent and
grandparent domains as this is the default search list.

"domain langley.af.mil" has an implicit "search langley.af.mil af.mil mil"
in the old resolvers, and you are timing out trying to resolve the
address with one of these domains tacked on.

When resolving internic.net the following will be tried in order.

        internic.net.langley.af.mil
        internic.net.af.mil
        internic.net.mil
        internic.net.

RFC 1535 aware resolvers try qualified address first.

        internic.net.
        internic.net.langley.af.mil
        internic.net.af.mil
        internic.net.mil

RFC 1535 documents the problems associated with the old search
algorithim,  including security issues, and how to alleviate some of the
problems.

-----------------------------------------------------------------------------

Question 6.11.  Why does swapping kill BIND ?

Date: Thu Jul  4 23:20:20 EDT 1996

The question was:

   I've been diagnosing a problem with BIND 4.9.x (where x is usually 3BETA9 
   or 3REL) for several months now.  I finally tracked it down to swap space
   utilization on the unix boxes.

   This happens under (at least) under Linux 1.2.9 & 1.2.13, SunOS 4.1.3U1, 
   4.1.1, and Solaris 2.5.  The symptom is that if these machines get into 
   swap at all bind quits resolving most, if not all queries.  Mind you that 
   these machines are not "swapping hard", but rather we're talking about a 
   several hundred K TEMPORARY deficiency.   I have noticed while digging 
   through various archives that there is some referral to "bind thrashing
   itself to death".   Is this what is happening ?

And the answer is:

   Yes it is. Bind can't tolerate having even a few pages swapped out.  
   The time required to send responses climbs to several seconds/request,
   and the request queue fills and overflows.

   It's possible to shrink memory consumption a lot by undefining STATS
   and XSTATS, and recompiling.  You could nuke DEBUG too, which will
   cut the code size down some, but probably not the data size.  If that
   doesn't do the job then it sounds like you'll need to move DNS onto a
   separate box.

   BIND tends to touch all of its resident pages all of the time with
   normal activity... if you look at the RSS verses the total process
   size, you will always see the RSS within, usually, 90% of the total
   size of the process.  This means that *any* paging of named-owned
   pages will stall named.  Thus, a machine running a heavily accessed
   named process cannot afford to swap *at all*.

   (Paul Vixie continues on this subject):
   I plan to try to get BIND to exhibit slightly better locality of
   reference in some future release.  Of course, I can only do this if
   the query names also exhibit some kind of hot spots.  If someone
   queries all your names often, BIND will have to touch all of its VM
   pool that often.  (Right now, BIND touches everything pretty often
   even if you're just hammering on some hot spots -- that's the part
   I'd like to fix.  Malloc isn't cooperating.)

-----------------------------------------------------------------------------

Question 6.12.  Resource limits warning in system

Date: Sun Feb 15 22:04:43 EST 1998

When bind-8.1.1 is started the following informational message appears in
the syslog...

   Feb 13 14:19:35 ns1named[1986]:
       "cannot set resource limits on this system"

What does this mean ?

A: It means that BIND doesn't know how to implement the "coresize",
"datasize", "stacksize", or "files" process limits on your OS.

If you're not using these options, you may ignore the message.

-----------------------------------------------------------------------------

Question 6.13.  ERROR:ns_forw: query...learnt

Date: Sun Feb 15 23:08:06 EST 1998

The following message appears in syslog:

   Jan 22 21:59:55 server1 named[21386]: ns_forw: query(testval) contains
        our address (dns1.foobar.org:1.2.3.4) learnt (A=:NS=)

what does it mean ?

A: This means that when it was looking up the NS records for the domain
containing "testval" (i.e. the root domain), it found an NS record
pointing to dns1.foobar.org, and the A record for this is 1.2.3.4.
This is server1's own IP address, but it's not authoritative for the
root domain.  The (A-:NS=) part of the message means that it didn't
learn these NS records from any other machine.

You may have listed dns1.foobar.org in your root server cache
file, even though it's not configured as a root server.  

\question 09jul:linuxq ERROR:recvfrom: Connection refused

Date: Wed Jul  9 21:57:40 EDT 1997

DNS on my linux system is reporting the error 

\verbatim
Mar 26 12:11:20 idg named[45]: recvfrom: Connection refused 

When I start or restart the named program I get no errors.  What could be
causing this ?

A: Are you running the BETA9 version of bind 4.9.3 ?   It is a bug that
does no harm and the error reporting was corrected in later releases.  You
should upgrade to a newer version of bind.

-----------------------------------------------------------------------------

Question 6.14.  ERROR:zone has trailing dot

Date: Wed Jul  9 22:11:51 EDT 1997

If syslog reports "zone has trailing dot", the zone information contains a
trailing dot in the named.boot file where it does not belong.

   example:
   secondary  domain.com.         xxx.xxx.xxx.xxx    S-domain.com
                        ^
-----------------------------------------------------------------------------

Question 6.15.  ERROR:Zone declared more then once

Date: Wed Jul  9 22:12:45 EDT 1997

If syslog reports "Zone declared more then once",

A zone is specified multiple times in the named.boot file

   example:
   secondary  domain.com         198.247.225.251    S-domain.com
   secondary  zone.com           198.247.225.251    S-zone.com
   primary    domain.com         P-domain.com

   domain.com is declared twice, once as primary, and once as secondary

-----------------------------------------------------------------------------

Question 6.16.  ERROR:response from unexpected source

Date: Wed Jul  9 22:12:45 EDT 1997

If syslog reports "response from unexpected source", BIND (pre 4.9.3) has
a bug if implimented on a multi homed server.  This error indicates that
the response to a query came from an address other then the one sent to.
So, if ace gets a response from an unexpected source, ace will ignore the
response.

-----------------------------------------------------------------------------

Question 6.17.  ERROR:record too short from [zone name]

Date: Mon Jun 15 21:34:49 EDT 1998

If syslog report "record too short from [zone name]", The secondary server
is trying to pull a zone from the primary server.  For some reason, the
primary sent an incomplete zone.  This usually is a problem at the primary
server.

   To troubleshoot, try this:

   dig [zonename] axfr @[primary IP address]

   Often, this is caused by a line broken in the middle.

When the primary server's "named.boot" file contains "xfrnets" entries
for other servers and the secondary is not listed, this error can occur.
Creating an "xfrnets" entry for the secondary will solve the error.

-----------------------------------------------------------------------------

Question 6.18.  ERROR:sysquery: findns error (3)

Date: Wed Jul  9 22:17:09 EDT 1997

If syslog reports "sysquery: findns error (3)" or
"qserial_query(zonename): sysquery FAILED", there is no ns record for  the
zone.  or the NS record is not defined correctly.

-----------------------------------------------------------------------------

Question 6.19.  ERROR:Err/TO getting serial# for XXX

Date: Wed Jul  9 22:18:41 EDT 1997

If syslog reports "Err/TO getting serial# for XXX", there could be a
number of possible errors:

   - An incorrect IP address in named.boot,
   - A network reachibility problem,
   - The primary is lame for the zone.

An external check to see if you can retrieve the SOA is the best way to
work out which it is.

-----------------------------------------------------------------------------

Question 6.20.  ERROR:zonename IN NS points to a CNAME

Date: Wed Jul  9 22:20:29 EDT 1997

If syslog reports "zonename IN NS points to a CNAME" or  "zonename IN MX
points to a CNAME", named is 'reminding' you that due to various RFCs, an
NS or MX record cannot point to a CNAME.

   EXAMPLE 1
   ---------
   domain.com    IN SOA      (...stuff...)
                 IN NS       ns.domain.com.
   ns            IN CNAME    machine.domain.com.
   machine       IN A        1.2.3.4

   The IN NS record points to ns, which is a CNAME for machine.  This
   is what results in the above error

   EXAMPLE 2
   ---------
   domain.com    IN SOA      (...stuff...)
                 IN MX       mail.domain.com.
   mail          IN CNAME    machine.domain.com.
   machine       IN A        1.2.3.4

   This would cause the MX variety of the error.

   The fix is point MX and NS records to a machine that is defined explicitly
   by an IN A record.

-----------------------------------------------------------------------------

Question 6.21.  ERROR:Masters for secondary zone [XX] unreachable

Date: Wed Jul  9 22:24:27 EDT 1997

If syslog reports "Masters for secondary zone [XX] unreachable", the
initial attempts to load a zone failed, and the name server is still
trying.  If this occurs multiple times, a problem exists, likely on the
primary server.  This is a fairly generic error, and could indicate a vast
number of problems.  It might be that named is not running on the primary
server, or they do not have the correct zone file.  If this keeps up long
enough a zone might expire.

-----------------------------------------------------------------------------

Question 6.22.  ERROR:secondary zone [XX] expired

Date: Wed Jul  9 22:25:53 EDT 1997

If syslog reports "secondary zone [XX] expired", there has been a
expiration of a secondary zone on this server.

An expired zone is one in which a transfer hasn't successfully been
completed in the amount of time specified before a zone expires.

This problem could be anything which prevents a zone transfer: The primary
server is down, named isn't running on the primary, named.boot has the
wrong IP address, etc.

-----------------------------------------------------------------------------

Question 6.23.  ERROR:bad response to SOA query from [address]

Date: Wed Jan 14 12:15:11 EST 1998

If syslog reports "bad response to SOA query from [address], zone [name]",
a syntax error may exist in the SOA record of the zone your server is
attempting to pull.

It may also indicate that the primary server is lame, possibly due to a
syntax error somewhere in the zone file.

-----------------------------------------------------------------------------

Question 6.24.  ERROR:premature EOF, fetching [zone]

Date: Wed Jul  9 22:28:26 EDT 1997

If syslog reports "premature EOF, fetching [zone]", a syntax error exists
on the zone at the primary location, likely towards the End of File (EOF)
location.

-----------------------------------------------------------------------------

Question 6.25.  ERROR:Zone [XX] SOA serial# rcvd from [Y] is < ours

Date: Wed Jul  9 22:30:03 EDT 1997

If syslog reports "Zone [name] SOA serial# rcvd from [address] is < ours",
the zone transfer failed because the primary machine has a lower serial
number in the SOA record than the one on file on this server.

-----------------------------------------------------------------------------

Question 6.26.  ERROR:connect(IP/address) for zone [XX] failed

Date: Wed Jan 14 12:21:40 EST 1998

If syslog reports "connect(address) for zone [name] failed: No route to
host" or "connect(address) for zone [name] failed: Connection timed out",
it could be that there is no route to the specified host or a slow primary
system.  Try a traceroute to the address specified to isolate the problem.
The problem may be a mistyped IP address in named.boot.

A very slow primary machine or a connection may have been initialized,
then connectivity lost for some reason, etc.  Try networking
troubleshooting  tools like ping and traceroute, then try connecting to
port 53 using  nslookup or dig.

If syslog reports "connect(address) for zone [name] failed: Connection
refused", the destination address is not allowing the connection.  Either
the destination is not running DNS (port 53), or possibly filtering the
connection from you.  It is also possible that the  named.boot is pointing
to the wrong address.

-----------------------------------------------------------------------------

Question 6.27.  ERROR:sysquery: no addrs found for NS

Date: Wed Jul  9 22:37:01 EDT 1997

If syslog reports "sysquery: no addrs found for NS" , the IN NS record may
be pointing to a host with no IN A record.

-----------------------------------------------------------------------------

Question 6.28.  ERROR:zone [name] rejected due to errors

Date: Wed Jul  9 22:37:51 EDT 1997

If syslog reports "primary zone [name] rejected due to errors", there will
likely be another more descriptive error along with this, like  "zonefile:
line 17: database format error".  That zone file should be investigated
for errors.

===============================================================================

Section 7.  ACKNOWLEDGEMENTS

 Q7.1        How is this FAQ generated ?
 Q7.2        What formats are available ?
 Q7.3        Contributors

-----------------------------------------------------------------------------

Question 7.1.  How is this FAQ generated ?

Date: Mon Jun 15 21:45:53 EDT 1998

This FAQ is maintained in BFNN (Bizzarre Format with No Name).  This
allows me to create ASCII, HTML, and GNU info (postscript coming soon)
from one source file.

The perl script "bfnnconv.pl" that is available with the linux FAQ is used
to generate the various output files from the BFNN source.  This script is
available at

txs-11.mit.edu : /pub/linux/docs/linux-faq/linux-faq.source.tar.gz

-----------------------------------------------------------------------------

Question 7.2.  What formats are available ?

Date: Fri Dec  6 16:51:31 EST 1996

You may obtain one of the following formats for this document:

* ASCII: http://www.intac.com/~cdp/cptd-faq/cptd-faq.ascii
* BFNN: http://www.intac.com/~cdp/cptd-faq/cptd-faq.bfnn
* GNU info: http://www.intac.com/~cdp/cptd-faq/cptd-faq.info
* HTML: http://www.intac.com/~cdp/cptd-faq/index.html

-----------------------------------------------------------------------------

Question 7.3.  Contributors

Date: Thu Jul 16 10:45:57 EDT 1998

Many people have helped put this list together.  Listed in e-mail address
alphabetical order, the following people have contributed to this FAQ:

* <BERI@etf.bg.ac.yu> (Berislav Todorovic)
* <Benoit.Grange@inria.fr> (Benoit.Grange)
* <D.T.Shield@csc.liv.ac.uk> (Dave Shield)
* <Karl.Auer@anu.edu.au> (Karl Auer)
* <Todd.Aven@BankersTrust.Com>
* <adam@comptech.demon.co.uk> (Adam Goodfellow)
* <andras@is.co.za> (Andras Salamon)
* <barmar@bbnplanet.com> (Barry Margolin)
* <barr@pop.psu.edu> (David Barr)
* <bj@herbison.com> (B.J. Herbison)
* <bje@cbr.fidonet.org> (Ben Elliston)
* <brad@birch.ims.disa.mil> (Brad Knowles)
* <ckd@kei.com> (Christopher Davis)
* <cdp2582@hertz.njit.edu> (Chris Peckham)
* <cricket@hp.com> (Cricket Liu)
* <cudep@csv.warwick.ac.uk> (Ian 'Vato' Dickinson [ID17])
* <dj@netscape.com> (David Jagoda)
* <djk@cyber.com.au> (David Keegel)
* <dillon@best.com> (Matthew Dillon)
* <dparter@cs.wisc.edu> (David Parter)
* <e07@nikhef.nl> (Eric Wassenaar)
* <fitz@think.com> (Tom Fitzgerald)
* <fwp@CC.MsState.Edu> (Frank Peters)
* <gah@cco.caltech.edu> (Glen A. Herrmannsfeldt)
* <glenn@popco.com> (Glenn Fleishman)
* <harvey@indyvax.iupui.edu> (James Harvey)
* <hubert@cac.washington.edu> (Steve Hubert)
* <ivanl@pacific.net.sg> (Ivan Leong)
* <jpass@telxon.com> (Jim Pass)
* <jhawk@panix.com> (John Hawkinson)
* <jmalcolm@uunet.uu.net> (Joseph Malcolm)
* <jprovo@augustus.ultra.net> (Joe Provo)
* <jrs@foliage.com> (J. Richard Sladkey)
* <jsd@gamespot.com> (Jon Drukman)
* <jwells@pacificcoast.net> (John Wells)
* <kop@meme.com> (Karl O. Pinc)
* <kevin@cfc.com> (Kevin Darcy)
* <lamont@abstractsoft.com> (Sean T. Lamont)
* <lavondes@tidtest.total.fr> (Michel Lavondes)
* <mark@ucsalf.ac.uk> (Mark Powell)
* <marka@syd.dms.CSIRO.AU> (Mark Andrews)
* <mathias@unicorn.swi.com.sg> (Mathias Koerber)
* <mfuhr@dimensional.com> (Michael Fuhr)
* <mike@westie.gi.net> (Michael Hawk)
* <mjo@iao.ford.com> (Mike O'Connor)
* <nick@flapjack.ieunet.ie> (Nick Hilliard)
* <oppedahl@popserver.panix.com> (Carl Oppedahl)
* <patrick@oes.amdahl.com> (Patrick J. Horgan)
* <paul@software.com> (Paul Wren)
* <pb@fasterix.frmug.fr.net> (Pierre Beyssac)
* <ph10@cus.cam.ac.uk> (Philip Hazel)
* <phil@netpart.com> (Phil Trubey)
* <raj@ceeri.ernet.in> (Raj Singh)
* <rocky@panix.com> (R. Bernstein)
* <rv@seins.Informatik.Uni-Dortmund.DE> (Ruediger Volk)
* <sedwards@sedwards.com> (Steve Edwards)
* <shields@tembel.org> (Michael Shields)
* <spsprunk@pop.srv.paranet.com> (Stephen Sprunk)
* <tanner@george.arc.nasa.gov> (Rob Tanner)
* <vixie@vix.com> (Paul A Vixie)
* <wag@swl.msd.ray.com> (William Gianopoulos)
* <whg@inel.gov> (Bill Gray)
* <wolf@pasteur.fr> (Christophe Wolfhugel)

Thank you !

Bold Colorz

Saturday, April 3, 2010

tcp ip

comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 1 of 2)

comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2)

No comments:

Post a Comment