Australian Internet registration services

Configuring a Delegated Domain Name System

The DNS

In the early days of the Internet, all host names and their associated IP addresses were recorded in a single file called hosts.txt, maintained by the Network Information Centre in the USA. Not surprisingly, as the Internet grew so did this file, and by the mid-80's it had become impractically large to distribute to all systems over the network, and impossible to keep up to date. The Internet Domain Name System (DNS) was developed as a distributed database to solve this problem. It's primary goal is to allow the allocation of host names to be distributed amongst multiple naming authorities, rather than centralised at a single point.

DNS Structure

The DNS is arranged as a hierarchy, both from the perspective of the structure of the names maintained within the DNS, and in terms of the delegation of naming authorities. At the top of the hierarchy is the root domain "." which is administered by the Internet Assigned Numbers Authority (IANA). Administration of the root domain gives the IANA the authority to allocate domains beneath the root. The process of assigning a domain to an organisational entity is called delegating, and involves the administrator of a domain creating a sub-domain and assigning the authority for allocating sub-domains of the new domain the subdomain's administrative entity.

This is a hierarchical delegation, which commences at the "root" of the Domain Name Space ("."). A fully qualified domain name, is obtained by writing the simple names obtained by tracing the DNS hierarchy from the leaf nodes to the root, from left to right, separating each name with a stop ".", eg.

    fred.xxxx.edu.au.

is the name of a host system (huxley) within the XXXX University (xxx), an educational (edu) institution within Australia (au).

The sub-domains of the root are known as the top-level domains, and include the edu (educational), gov (government), and com (commercial) domains. Although an organisation anywhere in the world can register beneath these three-character top level domains, the vast majority that have are located within, or have parent companies based in, the United States. The top-level domains represented by the ISO two-character country codes are used in most other countries, thus organisations in Australia are registered beneath au.

The majority of country domains are sub-divided into organisational-type sub-domains. In some countries two character sub-domains are created (eg. ac.nz for New Zealand academic organisations), and in others three character sub-domains are used (eg. com.au for Australian commercial organisations). Regardless of the standard adopted each domain may be delegated to a separate authority.

Organisations that wish to register a domain name, even if they do not plan to establish an Internet connection in the immediate short term, should contact the administrator of the domain which most closely describes their activities.

Even though the DNS supports many levels of sub-domains, delegations should only be made where there is a requirement for an organisation or organisational sub-division to manage their own name space. Any sub-domain administrator must also demonstrate they have the technical competence to operate a domain name server (described below), or arrange for another organisation to do so on their behalf.

Domain Name Servers

The DNS is implemented as collection of inter-communicating nameservers. At any given level of the DNS hierarchy, a nameserver for a domain has knowledge of all the immediate sub-domains of that domain.

For each domain there is a primary nameserver, which contains authoritative information regarding Internet entities within that domain. In addition Secondary nameservers can be configured, which periodically download authoritative data from the primary server. Secondary nameservers provide backup to the primary nameserver when it is not operational, and further improve the overall performance of the DNS, since the nameservers of a domain that respond to queries most quickly are used in preference to any others. Thus, in addition to having a primary nameserver on site, each organisation should have at least one secondary on site, and another elsewhere on the Internet, preferably well connected. This is particularly important for entities with slow speed or dial-up Internet connections to reduce use of their link to support the DNS.

Setting up a Domain Name Server

Nameservers running on UNIX systems are based on the Berkeley Internet Name Daemon (BIND), which usually runs as the daemon named. Configuring BIND is a simple process that is full traps for the unwary!. Because of the way nameservers closely interact with each other, and the fact that the majority of BIND implementations are rather more delicate than we would like, mistakes are easily propagated throughout the DNS and often quite difficult to resolve.

named.boot

To start with, there is the named.boot file that named reads at startup. It can usually be found in /etc or /usr/local/etc of a Berkeley based UNIX system. Here is a simple example:

    directory      /usr/local/domain
    ;
    ;type          domain          source host/file   backup file
    ;
    cache                          root.cache
    ;
    primary        edu.au          zone/edu.au
    primary        aarnet.edu.au   zone/aarnet.edu.au
    primary        avcc.edu.au     zone/avcc.edu.au
    primary        130.139.in-addr.arpa   rev/130.139.rev
    primary        123.83.192.in-addr.arpa   rev/123/83.192.rev
    primary        0.0.127.in-addr.arpa      rev/loopback
    ;
    secondary      au               128.250.1.21    bak/au
    secondary      latrobe.edu.au    132.147.1.1    bak/latrobe.edu.au
    ;
    forwarders     139.130.4.4

Where:

Each named requires a "root cache" file in order to initialise named correctly with a reference to a root nameserver. A current version of the named.boot file is located at ftp://ftp.rs.internic.net/domain/named.root:

    ;
    ;       This file holds the information on root name servers needed to
    ;       initialize cache of Internet domain name servers 
    ;       (e.g. reference this file in the "cache  .  "
    ;       configuration file of BIND domain name servers).
    ;
    ;       This file is made available by InterNIC registration services
    ;       under anonymous FTP as
    ;           file                /domain/named.root
    ;           on server           FTP.RS.INTERNIC.NET
    ;       -OR- under Gopher at    RS.INTERNIC.NET
    ;           under menu          InterNIC Registration Services (NSI)
    ;              submenu          InterNIC Registration Archives
    ;           file                named.root
    ;
    ;       last update:    May 11, 1994
    ;       related version of root zone:   940516
    ;
    .                        99999999 IN  NS    NS.INTERNIC.NET.
    NS.INTERNIC.NET.         99999999     A     198.41.0.4
    .                        99999999     NS    NS1.ISI.EDU. 
    NS1.ISI.EDU.             99999999     A     128.9.0.107
    .                        99999999     NS    C.NYSER.NET.
    C.NYSER.NET.             99999999     A     192.33.4.12
    .                        99999999     NS    TERP.UMD.EDU.
    TERP.UMD.EDU.            99999999     A     128.8.10.90
    .                        99999999     NS    NS.NASA.GOV.
    NS.NASA.GOV.             99999999     A     128.102.16.10
                             99999999     A     192.52.195.10
    .                        99999999     NS    NS.NIC.DDN.MIL.
    NS.NIC.DDN.MIL.          99999999     A     192.112.36.4
    .                        99999999     NS    AOS.ARL.ARMY.MIL.
    AOS.ARL.ARMY.MIL.        99999999     A     128.63.4.82
                             99999999     A     192.5.25.82
    .                        99999999     NS    NIC.NORDU.NET.
    NIC.NORDU.NET.           99999999     A     192.36.148.17
    ; End of File

This shows the basic format of a zone file. It contains Internet (IN), nameserver (NS), and IP address (A) resource records. The NS records specify, on the right-hand-side, the names of the systems that are nameservers for the root domain, as indicated in the label field (a ".") on the left-hand-side. For each nameserver so specified there are A records that provide the IP address(es) of the corresponding systems. Note that if there is no left-hand-side label, then the previous label is used. The value 99999999 is the Time-To-Live value for the resource record; normally the default value for the current domain is used (see below). None of the root nameservers are located in Australia.

Let's now look at the start of zone file zone/aarnet.edu.au:


; Authoritative data for aarnet.EDU.AU (ORIGIN assumed aarnet.EDU.AU)
;
;    NB: format of serial number: yyyymmddxx
;
@             IN  SOA    jatz.aarnet.edu.au.  mit900.jatz.aarnet.edu.au. (
                         1994072801     ; Serial
                         10800          ; Refresh - 3 hours
                         1800           ; Retry - 30 minutes
                         3600000        ; Expire - 1000 hours (41.6 Days)
                         43200   )      ; Minimum - 12 hours

The "origin" for this zone file is aarnet.edu.au since this is the domain name specified with the primary keyword in the named.boot file.

BEWARE! Any name or label that appears on either the left or right-hand-side of a resource record that does not have a terminating full stop will have the origin added to the name/label. Missing full stops are one of the most common causes of error in DNS zone files.

Immediately after the SOA record are a list of NS records that specify the nameservers (primary and all secondaries) for the domain (remember that resource records without a label assume the label of the preceding record, ie. the origin, "@", or aarnet.EDU.AU.):


           IN      NS   jatz.aarnet.edu.au.
           IN      NS   cruskit.aarnet.edu.au.
           IN      NS   munnari.oz.au.

Each system listed in these NS records must either be the primary nameserver, or be configured as a secondary (ie. be running named and have an appropriate secondary statement in that nameserver's named.boot file). Just naming a system with an NS record as shown above will not make the named system a secondary nameserver. Note that the NS records that appear in this list must be the same as the NS records that appear in the zone file of the parent domain (in this example edu.au). Note also the names of the systems are fully qualified domain names, complete with a trailing "." (this is important, and the omission of the "." is the cause of many DNS problems!

The remainder of the aarnet.EDU.AU zone file contains information about host systems with the domain:


    jatz           IN    A           139.130.204.4
                   IN    MX   10     nico
    nico           IN    A           139.130.204.16
                   IN    HINFO       "Sparc10"   "SunOS"
                   IN    MX   10     nico
    scotch-finger  IN    A           139.130.204.8
                   IN    MX   10     nico

In this section the records are:

Thus mail for jatz.aarnet.edu.au should be forwarded to nico. This would be the normal case where a system is configured to accept mail from the Internet (described below). For systems that are generally not capable of exchanging electronic mail directly, the MX record will point at some form of mail server, eg. as shown above for the Macintosh system scotch- finger.aarnet.edu.au. The decimal value in the MX record is a preference that selects one MX record over another, for example


    @              IN    MX   10    nico
                   IN    MX   20    munnari.oz.au.

This defines a series of MX records that indicate (for this domain) that mail for aarnet.edu.au should be directed to jatz, but if jatz is not reachable, then try munnari.oz.au. Note that any system that is the target of an MX record should be configured to accept or forward mail for the domain name associated with the MX.

At the end of this example zone file the following resource records are found:


    ;
    ; Standard domain names
    ;
    mailhost             IN    CNAME  nico
    localhost            IN    A      127.0.0.1
    loghost              IN    CNAME  localhost

The CNAME record allows aliases to be defined within the DNS. Since several applications assume the existence of the host names mailhost and loghost, these are provided as aliases for actual hosts. Because they are just aliases, the left-hand-side of a CNAME record cannot be used anywhere else on the right-hand- side of a resource record (another common source of DNS problems!)

The name localhost is configured to be the internal loopback IP address which is defined to be 127.0.0.1.

The format of the zone files that support the reverse mapping of IP address to domain name use different resource records but are in all other respects formatted in the same way. For the small example domain used here the following zone might be used;


    ; Authoritative data for 130.139.in-addr.arpa
    ;
    @               IN  SOA   jatz.aarnet.edu.au. mit.jatz.aarnet.edu.au. (
                                    1993092001    ; Serial
                                    10800         ; Refresh - 3 hours
                                    1800          ; Retry - 30 minutes
                                    3600000       ; Expire - 1000 hours
                                    43200   )     ; Minimum - 12 hours
                    IN  NS    jatz.aarnet.edu.au.
                    IN  NS    anu.anu.edu.au.
    ;
    4.204           IN  PTR   jatz.aarnet.edu.au.
    8.204           IN  PTR   scotch-finger.aarnet.edu.au.
    16.204          IN  PTR   nico.aarnet.edu.au.

The records in this domain are of the form x4.x3.x2.xl.in-addr.arpa. representing the IP address xl.x2.x3.x4. The right-hand-side of the Pointer (PTR) record indicates the host associated with this address. The reason the address bytes are backwards is because IP address have the most significant component on the left, but domain names have the most significant component on the right. The in-addr.arpa domains are used by the gethostbyaddr() to return the name of a system given its IP address.

Since the parent domain of 130.139.in-addr.arpa. is in-addr.arpa., you need to contact the delegated domain authority of in-addr.arpa, the US InterNIC, to get your sub-domain of in- addr.arpa delegated to your nameservers. Once you have established an Internet connection, a form to arrange the delegation of an in-addr.arpa. sub-domain can be retrieved from ftp://ftp.aarnet.edu.au/pub/templates/in-addr-template, filled in and sent via electronic mail to domreg@apnic.net.

An in-addr.arpa. domain is also required for the loopback address described above (this is rev/loopback):


    @    IN   SOA  jatz.aarnet.EDU.AU. mit.jatz.aarnet.edu.au. (
                        1992092001  ; Serial
                        10800       ; Refresh - 3 hours
                        1800        ; Retry - 30 minutes
                        3600000     ; Expire - 1000 hours
                        43200   )   ; Minimum - 12 hours
         IN   NS     jatz.aarnet.edu.au.
    1    IN   PTR    localhost.

Because the loopback domain is just that, the information in this zone file is not passed to any other server and thus the values assigned to the various timers is not critical.

Setting the host to query the DNS

Having configured BIND by creating the appropriate boot and zone files, and started the nameserver(s) by launching named , applications that make use of the network and the associated name to IP address functions must somehow be made to direct queries to the DNS through the DNS resolver, in addition too, or instead of using a hosts file or a Network Information Service (NIS) server. The method by which this is done varies from one UNIX implementation to another. In all cases however, the resolver will consult the file /etc/resolv.conf to obtain the name of the domain in which this machine has been configured, and the addresses of nameservers to be used to initiate DNS queries, eg. resolv.conf on a system within the aarnet.edu.au domain might contain:


    domain aarnet.EDU.AU
    nameserver 139.130.204.4
    nameserver 139.130.204.2
    nameserver 130.56.4.1

Note that the nameservers specified do not need to be primary or even secondary for the corresponding domain, any nameserver will be able to respond to DNS queries (but their are obvious efficiencies in including at least one server for the local domain).

Under SunOS, use of the DNS can be enabled by either building the NIS host maps using the -b flag to makedbm or by replacing the libc run-time shareable library with a version that only uses the DNS for resolving host names and addresses. In either case, because dynamically linked shareable libraries are used, applications do not need to be recompiled or relinked. The DNS-capable library is available over the network, or from Sun Microsystems.

Under Ultrix there is a file called /etc/svc.conf that specifies which methods (DNS, hosts, NIS) should be used to resolve names (and other things), and the order they are applied in. Like SunOS, this is implemented through shareable libraries, so again no application changes are required. The svcsetup command can be used to modify svc.conf to enable use of BIND.

A similar facility is provided under System V Release 4 implementations, but in this case the relevant file is /etc/netconfig.

Some UNIX systems come with resolver routines that detect the presence of resolv.conf and automatically use the DNS. Others will include one set of network utilities (telnet, ftp, etc.) that use the hosts file (or NIS), and another set that can be used instead of those that use the DNS. In all cases, the vendor's supplied documentation should be consulted.

References

There is a good DNS Resources Directory on the World Wide Web.

Books:

DNS and Bind
     Paul Albitz & Criket Liu
     O'Reilly & Associates              1-56592-010-4

TCP/IP Network Administration
     Craig Hunt
     O'Reilly & Associates              0-937175-82-X

BSD 4.3 System Management Manual
     Dunlap, K., "Name Server Operations Guide for Bind,
     Release 4.3", UC Berkeley, SMM:11-3.

Internet RFCs:

   1032 Stahl, M., "Domain Administrators Guide", RFC 1032, SRI
        International, November 1987.

   1033 Lottor, M., "Domain Administrators Operations Guide" RFC 1033,
        SRI International, November 1987.

   1034 Mockapetris, P., "Domain Names - Concepts and Facilities",
        STD 13, RFC 1034, ISI, November 1987.

   1035 Mockapetris, P., "Domain Names - Implementation and
        Specification", STD 13, RFC 1035, ISI, November 1987.

   1359 ACM SIGUCCS Networking Taskforce, "Connecting to the Internet -
        What Connecting Institutions Should Anticipate", FYI 16,
        RFC 1359, August 1992.

   1340 Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
        RFC 1340, ISI, July 1992.

   1480 Cooper, A., and J. Postel, "The US Domain", RFC 1480, 
        June 1993.

   974  Partridge, C., "Mail Routing and the Domain Name System",
        STD 14, RFC 974, BBN, January 1986.