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.
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.
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.
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:
Comments are indicated with a leading semi-colon.
The cache line indicates that the file root.cache (in /usr/local/domain) has information about root nameservers that can get the nameserver started. This information is replaced as soon as possible with "real" information obtained from the root nameservers.
The primary keyword identifies a domain for which this nameserver shall act as a primary nameserver. The definition of the domain itself is called a zone file and in this case is the file aarnet.edu.au in the directory /usr/local/domain/zone. A nameserver can be primary for several domains, including sub-domains of domains it is primary for, eg. aarnet.edu.au and edu.au.
The DNS contains more than just domain-name to IP address mappings. This line and the next indicate that this nameserver will act as a primary nameserver for the so-called reverse mappings of IP address to domain-name for the Class B network 139.130.0.0 and the Class C network 192.83.123.0. This feature is described below.
Configuring a nameserver to be a secondary nameserver for a domain is done using the secondary keyword and providing the name of the domain to be secondaried, the IP address of the primary name server from which the corresponding zone file will loaded (by this named communicating with the named on the primary nameserver), and the name of a file in which this zone file will be stored. Secondary zone transfers occur when named starts, and at intervals defined within the zone file.
This nameserver is secondary for another domain. As noted above, it's good to have at least one secondary "somewhere else", in case your organisation's link to the Internet is down for an extended period.
The forwarder line specifies the IP address of one or more nameservers to which this nameserver should pass all queries and responses. These "forwarders" act as caches of frequently requested DNS questions and answers, potentially improving the speed of DNS lookups, reducing the load on nameservers higher up in the DNS hierarchy (particularly the root servers), and limiting the amount of DNS traffic carried over major trunk links, eg. from Australian to the rest of the Internet. AARNet operates a system located at the topological centre of the network to support this function, and recommends that all AARNet client sites include the IP address of this system, 139.130.4.4, in the forwarder line of any named.boot configuration file.
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.
All the other values are timers, measured in seconds.
The values for refresh and retry put extra load on the nameservers (especially the secondaries) and on the network if they're too low, but conversely allow nameserver inconsistencies for longer than is really desirable if they're too high. A value of 2 or 3 hours (7200 or 10800 seconds) for refresh, and 30 minutes (1800 seconds) for retry is suggested.
Note that the value of minimum field effectively controls how quickly you can make changes to the zone file since it determines how long it will take between when you decide that you want to make a change, and when you can confidently say that the change has propagated everywhere (by virtue of the changed record's TTL expiring).
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.
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.
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.