path: root/contrib/bind/doc/misc/FAQ.2of2

Newsgroups: comp.protocols.tcp-ip.domains,comp.answers,news.answers
Path: vixie!news1.digital.com!su-news-hub1.bbnplanet.com!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.mathworks.com!news.kei.com!uhog.mit.edu!rutgers!njitgw.njit.edu!hertz.njit.edu!cdp2582
From: cdp2582@hertz.njit.edu (Chris Peckham)
Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2)
Message-ID: <cptd-faq-2-849940949@njit.edu>
Followup-To: comp.protocols.tcp-ip.domains
Originator: cdp2582@hertz.njit.edu
Keywords: BIND,DOMAIN,DNS
Sender: news@njit.edu
Supersedes: <cptd-faq-2-847336183@njit.edu>
Nntp-Posting-Host: hertz.njit.edu
X-Posting-Frequency: posted during the first week of each month
Reply-To: domain-faq@njit.edu (comp.protocols.tcp-ip.domains FAQ comments)
Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA
References: <cptd-faq-1-849940949@njit.edu> 
Date: Sat, 7 Dec 1996 06:42:49 GMT
Approved: news-answers-request@MIT.EDU
Expires: Sat 11 Jan 97 02:42:29 EDT
Lines: 1277
Xref: vixie comp.protocols.tcp-ip.domains:12905 comp.answers:22441 news.answers:85683

Posted-By: auto-faq 3.1.1.2
Archive-name: internet/tcp-ip/domains-faq/part2
Revision: 1.13 1996/12/07 06:42:15


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


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

Section 5.  CONFIGURATION

 Q5.1        Changing a Secondary server to a Primary server ?
 Q5.2        Moving a Primary server to another server
 Q5.3        How do I subnet a Class B Address ?
 Q5.4        Subnetted domain name service
 Q5.5        Recommended format/style of DNS files
 Q5.6        DNS on a system not connected to the Internet
 Q5.7        Multiple Domain configuration
 Q5.8        wildcard MX records
 Q5.9        How do you identify a wildcard MX record ?
 Q5.10       Why are fully qualified domain names recommended ?
 Q5.11       Distributing load using named
 Q5.12       Order of returned records
 Q5.13       resolv.conf
 Q5.14       How do I delegate authority for sub-domains ?
 Q5.15       DNS instead of NIS on a Sun OS 4.1.x system
 Q5.16       Patches to add functionality to BIND 
 Q5.17       How to serve multiple domains from one server

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

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

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

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

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

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

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

Question 5.2.  Moving a Primary server to another server

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

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

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

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

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

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

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

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

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

Date: Fri Apr 28 13:34:52 EDT 1995

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

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

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

Subnetting can also be used to improve routing conditions.

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

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

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

Question 5.4.  Subnetted domain name service

Date: Mon Aug  5 23:00:16 EDT 1996

If you are looking for some examples of handling subnetted class C
networks as separate DNS domains, see the Internet Draft

draft-ietf-cidrd-classless-inaddr-02.txt

for more information.   This file is available for anonymous ftp at

ds.internic.net :
/internet-drafts/draft-ietf-cidrd-classless-inaddr-02.txt

or other IETF mirror sites (ftp.is.ca.za [Africa], nic.nordu.net [Europe],
munnari.oz.au [Pacific Rim], ds.internic.net [US East Coast], or
ftp.isi.edu [US West Coast]).

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

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

We first define the domain for the class C net,

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

Now, in the delegated nameserver, one.nameserver

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

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

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

ftp.vix.com : /pub/bind/contrib/gencidrzone

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

Question 5.5.  Recommended format/style of DNS files

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

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

   I've gone back and forth on the question of whether the BOG should
   include a section on this topic.  I know what I myself prefer, but
   I'm wary of ramming my own stylistic preferences down the throat of
   every BOG reader.  But since you ask :-)...
 
   Create /var/named.  If your system is too old to have a /var, either
   create one or use /usr/local/adm/named instead.  Put your named.boot
   in it, and make /etc/named.boot a symlink to it.  If your system
   doesn't have symlinks, you're S-O-L (but you knew that).  In
   named.boot, put a "directory" directive that specifies your actual
   BIND working directory:
 
        directory       /var/named
 
   All relative pathnames used in "primary", "secondary", and "cache"
   directives will be evaluated relative to this directory.  Create two
   subdirectories, /var/named/pri and /var/named/sec.  Whenever you add
   a "primary" directive to your named.boot, use "pri/WHATEVER" as the
   path name.  And then put the primary zone file into "pri/WHATEVER".
   Likewise when you add "secondary" directives, use "sec/WHATEVER" and
   BIND (really named-xfer) will create the files in that
   subdirectory.
 
   (Variations: (1) make a midlevel directory "zones" and put "pri" and
   "sec" into it; (2) if you tend to pick up a lot of secondaries from
   a few hosts, group them together in their own subdirectories --
   something like /var/named/zones/uucp if you're a UUCP Project name
   server.)
 
   For your forward files, name them after the zone.  dec.com becomes
   "/var/named/zones/pri/dec.com".  For your reverse files, name them
   after the network number.  0.1.16.in-addr.arpa becomes
   "/var/named/zones/pri/16.1.0".

   When creating or maintaining primary zone files, try to use the same
   SOA values everywhere, except for the serial number which varies per
   zone.  Put a $ORIGIN directive at the top of the primary zone file,
   not because its needed (it's not since the default origin is the
   zone named in the "primary" directive) but because it make it easier
   to remember what you're working on when you have a lot of primary
   zones.  Put some comments up there indicating contact information
   for the real owner if you're proxying.  Use RCS and put the "Id"
   in a ";" comment near the top of the zone file.
 
   The SOA and other top level information should all be listed
   together.  But don't put IN on every line, it defaults nicely.  For
   example:
 
==============
@       IN      SOA     gw.home.vix.com. postmaster.vix.com. (
                        1994082501      ; serial
                        3600    ; refresh (1 hour)
                        1800    ; retry (30 mins)
                        604800  ; expire (7 days)
                        3600 )  ; minimum (1 hour)
 
                NS      gw.home.vix.com.
                NS      ns.uu.net.
                NS      uucp-gw-1.pa.dec.com.
                NS      uucp-gw-2.pa.dec.com.
 
                MX      10 gw.home.vix.com.
                MX      20 uucp-gw-1.pa.dec.com.
                MX      20 uucp-gw-1.pa.dec.com.
==============
 
   I don't necessarily recommend those SOA values.  Not every zone is
   as volatile as the example shown.  I do recommend that serial number
   format; it's in date format with a 2-digit per-day revision number.
   This format will last us until 2147 A.D. at which point I expect a
   better solution will have been found :-).  (Note that it would last
   until 4294 A.D. except that there are some old BINDs out there that
   use a signed quantity for representing serial number interally; I
   suppose that as long as none of these are still running after 2047
   A.D., that we can use the above serial number format until 4294
   A.D., at which point a better solution will HAVE to be found.)
 
   You'll note that I use a tab stop for "IN" even though I never again
   specify it.  This leaves room for names longer than 7 bytes without
   messing up the columns.  You might also note that I've put the MX
   priority and destination in the same tab stop; this is because both
   are part of the RRdata and both are very different from MX which is
   an RRtype.  Some folks seem to prefer to group "MX" and the priority
   together in one tab stop.  While this looks neat it's very confusing
   to newcomers and for them it violates the law of least
   astonishment.
 
   If you have a multi-level zone (one which contains names that have
   dots in them), you can use additional $ORIGIN statements but I
   recommend against it since there is no "back" operator.  That is,
   given the above example you can add:
 
=============
$ORIGIN home
gw              A       192.5.5.1
=============
 
   The problem with this is that subsequent RR's had better be
   somewhere under the "home.vix.com" name or else the $ORIGIN that
   introduces them will have to use a fully qualified name.  FQDN
   $ORIGIN's aren't bad and I won't be mad if you use them.
   Unqualified ones as shown above are real trouble.  I usually stay
   away from them and just put the whole name in:
 
=============
gw.home         A       192.5.5.1
=============
 
   In your reverse zones, you're usually in some good luck because the
   owner name is usually a single short token or sometimes two.
 
=============
$ORIGIN 5.5.192.in-addr.arpa.
@       IN      SOA     ...
                NS      ...
1               PTR     gw.home.vix.com.
=========================================
$ORIGIN 1.16.in-addr.arpa.
@       IN      SOA     ...
                NS      ...
2.0             PTR     gatekeeper.dec.com.
=============

   It is usually pretty hard to keep your forward and reverse zones in
   synch.  You can avoid that whole problem by just using "h2n" (see
   the ORA book, DNS and BIND, and its sample toolkit, included in the
   BIND distribution or on ftp.uu.net (use the QUOTE SITE EXEC INDEX
   command there to find this -- I never can remember where it's at).
   "h2n" and many tools like it can just read your old /etc/hosts file
   and churn it into DNS zone files.  (May I recommend
   contrib/decwrl/mkdb.pl from the BIND distribution?)  However, if you
   (like me) prefer to edit these things by hand, you need to follow
   the simple convention of making all of your holes consistent.  If
   you use 192.5.5.1 and 192.5.5.3 but not (yet) 192.5.5.2, then in
   your forward file you will have something like
 
=============
...
gw.home         A       192.5.5.1
;avail          A       192.5.5.2
pc.home         A       192.5.5.3
=============
 
   and in your reverse file you will have something like
 
=============
...
1               PTR     gw.home.vix.com.
;2              PTR     avail
3               PTR     pc.home.vix.com.
=============
 
   This convention will allow you to keep your sanity and make fewer
   errors.  Any kind of automation (h2n, mkdb, or your own
   perl/tcl/awk/python tools) will help you maintain a consistent
   universe even if it's also a complex one.  Editing by hand doesn't
   have to be deadly but you MUST take care.

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

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

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

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

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

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

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

Question 5.7.  Multiple Domain configuration

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

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

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

You may do this by using CNAMEs:

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

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

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

Question 5.8.  wildcard MX records

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

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

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

No. It just doesn't work.

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

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

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

It just doesn't work.

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

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

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

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

        exact match MX
        exact match A
        wildcard MX

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

RFC 974 explains this pretty well.

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

Question 5.10.  Why are fully qualified domain names recommended ?

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

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

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

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

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

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

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

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

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

Question 5.11.  Distributing load using named

Date: Wed Mar  1 11:04:43 EST 1995

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

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

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

Not nice.

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

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

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

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

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

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

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

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

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

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

Question 5.12.  Order of returned records

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


         6.1.3.4  Multihomed Hosts

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

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

In BIND 4.9.x's resolver code, the "sortlist" directive in resolv.conf
can be used to configure this.

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

Question 5.13.  resolv.conf

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

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

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

   It's historical.  Some kernels can't unbind a UDP socket's source
   address, and some resolver versions (notably not including BIND
   4.9.2 or 4.9.3's) try to do this.  The result can be wide area
   network traffic with 127.0.0.1 as the source address.  Rather than
   giving out a long and detailed map of version/vendor combinations of
   kernels/BINDs that have/don't this problem, I just tell folks not to
   use 127.0.0.1 at all.
 
   0.0.0.0 is just an alias for the first interface address assigned
   after a system boot, and if that interface is a up-and-down point to
   point link (PPP, SLIP, whatever), there's no guarantee that you'll
   be able to reach yourself via 0.0.0.0 during the entire lifetime of
   any system instance.  On most kernels you can finesse this by adding
   static routes to 127.0.0.1 for each of your interface addresses, but
   some kernels don't like that trick and rather than give a detailed
   map of which ones work and which ones don't, I just globally
   recommend against 0.0.0.0.
 
   If you know enough to know that 127.0.0.1 or 0.0.0.0 is safe on your
   kernel and resolver, then feel free to use them.  If you don't know
   for sure that it is safe, don't use them.  I never use them (except
   on my laptop, whose hostname is "localhost" and whose 0.0.0.0 is
   127.0.0.1 since I ifconfig my lo0 before any other interface).  The
   operational advantage to using a real IP address rather than an
   wormhole like 0.0.0.0 or 127.0.0.1, is that you can then "rdist" or
   otherwise share identical copies of your resolv.conf on all the
   systems on any given subnet, not all of which will be servers.

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

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

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

Date: Sat Dec  7 02:04:17 EST 1996

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

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

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

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

   @               IN      SOA ...
                   IN      A       130.95.100.3
                   IN      MX      mackerel.gu.uwa.edu.au.
                   IN      MX      uniwa.uwa.edu.au.
    
   marlin          IN      A       130.95.100.4
 
   ucc             IN      NS      marlin.gu.uwa.edu.au.
                   IN      NS      mackerel.gu.uwa.edu.au.

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

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

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

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

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

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

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

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

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

Question 5.16.  Patches to add functionality to BIND

Date: Tue Nov  5 23:53:47 EST 1996

There are others, but these are listed here:

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

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

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

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

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

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

Question 5.17.  How to serve multiple domains from one server

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

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

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

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

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

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

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

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

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

Section 6.  PROBLEMS

 Q6.1        No address for root server
 Q6.2        Error - No Root Nameservers for Class XX
 Q6.3        Bind 4.9.x and MX querying?
 Q6.4        Do I need to define an A record for localhost ?
 Q6.5        MX records, CNAMES and A records for MX targets
 Q6.6        Can an NS record point to a CNAME ?
 Q6.7        Nameserver forgets own A record
 Q6.8        General problems (core dumps !)
 Q6.9        malloc and DECstations
 Q6.10       Can't resolve names without a "."
 Q6.11       Err/TO errors being reported
 Q6.12       Why does swapping kill BIND ?

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

Question 6.1.  No address for root server

Date: Mon Jan  2 13:49:43 EST 1995

Q: I've been getting the following messages lately from bind-4.9.2..
        ns_req: no address for root server
 
We are behind a firewall and have the following for our named.cache file -
 
        ; list of servers
        .               99999999    IN  NS  POBOX.FOOBAR.COM.
                        99999999    IN  NS  FOOHOST.FOOBAR.COM.
        foobar.com.     99999999    IN  NS  pobox.foobar.com.
You can't do that.  Your nameserver contacts POBOX.FOOBAR.COM, gets the
correct list of root servers from it, then tries again and fails because
of your firewall.

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

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

Question 6.2.  Error - No Root Nameservers for Class XX

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

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

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

       Domain System Parameters:

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

DNS information for RFC 1700 was taken from
ftp.isi.edu : /in-notes/iana/assignments/dns-parameters

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

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

Question 6.3.  Bind 4.9.x and MX querying?

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Q: Given the example - 

     hello in cname     realname
     mailx in mx        0 hello

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

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

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

   Here's the relevant BOG snippet:

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

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

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

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

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

Can I do this ?  Is it legal ?


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

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

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

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

Here is the reason why:

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

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

Question 6.7.  Nameserver forgets own A record

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

Q: Lately, I've been having trouble with named 4.9.2 and 4.9.3.  
   Periodically, the nameserver will seem to "forget" its own A record,
   although the other information stays intact.  One theory I had was
   that somehow a site that the nameserver was secondary for was
   "corrupting" the A record somehow.
 
A: This is invariably due to not removing ALL of the cached zones
   when you moved to 4.9.X. Remove ALL cached zones and restart
   your nameservers.
 
   You get "ignoreds" because the primaries for the relevant zones are
   running old versions of BIND which pass out more glue than is
   required. named-xfer trims off this extra glue.

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

Question 6.8.  General problems (core dumps !)

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

Paul Vixie says:

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

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

Question 6.9.  malloc and DECstations

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

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

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

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

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

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

	e.g.
	domain <domain>
	search <domain> [<domain2> ...]

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

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

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

RFC 1535 aware resolvers try qualified address first.

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

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

Question 6.11.  Err/TO errors being reported

Date: Sun May  5 23:46:32 EDT 1996

Why are errors like

     Apr  2 20:41:58 nameserver named[25846]: Err/TO getting serial# for 
     "foobar.domain1.com"
     Apr  2 20:41:59 nameserver named[25846]: Err/TO getting serial# for 
     "foobar.domain2.com"

reported ?  These generally indicate that there is one of the following
problems:

* A network problem between you and the primary,
* A bad IP address in named.boot,
* The primary is Lame for the zone.

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

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

Question 6.12.  Why does swapping kill BIND ?

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

The question was:

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

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

And the answer is:

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

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

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

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

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

Section 7.  ACKNOWLEDGEMENTS

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

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

Question 7.1.  How is this FAQ generated ?

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

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

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

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

Question 7.2.  What formats are available ?

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

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

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

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

Question 7.3.  Contributors

Date: Sat Dec  7 01:29:29 EST 1996

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

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

Thank you !