comp.protocols.tcp-ip.domains FAQ - Section 5
CONFIGURATION

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 -

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 <subdomain server addr> 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 <server1>
   xxx IN NS <server2>
   xxx IN NS <server3>			; if needed
...
   xxx IN NS <serverN>			; 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:

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:

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: Thu Feb 11 14:40:20 EST 1999

(The following section was mainly contributed by Berislav Todorovic)

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

Question 5.23. Modifying the Behavior of DNS with ndots

Date: Mon Jan 18 22:26:27 EST 1999

This section is based on contributions by Albert E. Whale.

ndots is an option that allows one to modify how domain lookups are performed. The option is available in BIND releases 4.9.3 and higher.

Section 6.2 (Resolver Configuration) of the BOG lists the options and modifications that are possible in the resolv.conf file. There is also an errata sheet which is specific to the definition of the ndots option.

The command syntax in /etc/resolv.conf is 

   options ndots:3
where (3) three can be any number you choose to modify the ndots behavior.

The definition of the ndots option follows: 

    sets the lower threshold (measured in ``number of dots'') on names
    given to res_query() such that names with at least this number of
    dots will be tried as absolute names before any local-domain or
    search-list processing is done.  The default for this internal
    variable is ``1''.
This option may have a bearing on the "forwarders" and "slave" configuration. If the server which is designed to resolve names (but is not granted full access to the Internet) is also a nameserver for it's own domain, the ndots: command will force the server to attempt to resolve the request locally before sending the request to the "forwarder". This allows the server to resolve local names locally, and names which are not in it's cache via the forwarder.

Question 5.24. 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:

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:

Solution 1: (tested on a Linux system and should work on other Unix boxes as well). Software needed is: 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.

Next: PROBLEMS.
Back: DEFINITIONS .
Return to contents.

Chris Peckham - 16 June 1999

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