Contents
The Domain Naming System (DNS) is a hierarchical distributed database that lets you have name-to-number mappings on your network's computers. DNS's tree-like structure is similar to the directory structure of the UNIX or MS-DOS file system. A domain's label is similar to a directory name, but with a dot (.) separating each domain label in the full domain name.
DNS is used in the Internet to translate names of network nodes into addresses. For example, the name decel.ecel.uwa.edu.au is the number 130.95.4.2, and vice versa. In the example address, .au is the top-level domain, edu.au is a subdomain, and ecel.uwa.edu.au is also a subdomain that is part of both domains au and edu.au.
A name server is a program that stores information about the domain name space. An authoritative name server has complete information about the part of the domain name space it is responsible for.
For example, there are two domains, x.z and y.z. The authoritative name servers for both of these are called nic.x.z and nic.y.z, respectively. If nic.x.z is asked if there is a node called a.x.z, then nic.x.z can definitively say yes or no, because it is the authoritative name server for the x.z domain. If nic.x.z is asked about a node called a.y.z, nic.x.z must query nic.y.z, because nic.y.z is the authoritative name server for the domain y.z. nic.x.z then caches the response; it can then quickly answer future queries, but its answers will not be authoritative, because nic.x.z is not responsible for the y.z domain.
There is a subtle difference between a zone and a domain. The domain is the entire set of machines encompassed by an organizational domain. For example, the domain uwa.edu.au contains all machines at the University of Western Australia.
A zone contains domain names and any data that a domain contains. It is an area of the DNS about which a name server has complete information and, therefore, the name server has authority for the zone. A name server can have authority for multiple zones.
A zone may delegate domain names and data elsewhere. When you delegate, you assign authority for your subdomains to different name servers. Instead of information about the delegated subdomain, your data now includes pointers to the authoritative name servers for that subdomain. Go to "Delegation of Authority" for details.
The following sections assume you have a copy of the domain name server software and you already have a domain name selected. For general information about these topics, check your MultiNet documentation. If you need basic information about IP addresses and subnetting, click here to see the document "Beginning IP for New Users." For information about using IP addresses in the DNS, see "Reverse Name Lookups," later in this document.
The DNS file is probably called .NAMED or IN.NAMED, depending on the implementation of UNIX you are using. (The examples in this section use .NAMED; substitute the name of your DNS file, if different.) If you are using BIND, use the most recent version.
Create a file called NAMED.BOOT. This describes to .NAMED where to find required startup information. This file is usually located in /etc/named.boot. If you place NAMED.BOOT in a directory with the rest of your .NAMED files, you also need to specify the boot file's path.
If you are a leaf node (subdomain) and there are other name servers at your site, a typical boot file will resemble the following example:
directory /etc/namedfiles
cache . root.cache
primary ecel.uwa.edu.au ecel.uwa.domain
primary 0.0.127.in-addr.arpa 0.0.127.domain
primary 4.95.130.in-addr.arpa 4.95.130.domain
forwarders 130.95.128.1
The lines in the example NAMED.BOOT file are explained below:
- cache
- Information that .NAMED uses to boot up, such as the name or IP number of other name servers.
- primary
- The domain name of one of the domains for which this server is authoritative. A primary name server loads data from its own data files for its zones. The first value usually is the domain to append to other domain names included in that file. The domain name at the end of the line is the filename (relative to /etc of the directory, if a one was specified). The filename can contain slashes to refer to subdirectories.
- You also need capability for forward and reverse lookups. Enter the numbers back-to-front for the reverse lookup file. The example shown above is for the subnet ecel.uwa.edu.au, whose IP address is 130.95.4.*. The reverse lookup name must be entered in the form 4.95.130 and must always end with in-addr.arpa. For details, see the section "Reverse Name Lookups." If you experience problems with reverse lookups, check the order first.
- forwarders
- A list of IP addresses for forwarding recursive queries. Designating a site-wide server at your site as a forwarder allows that server to handle all off-site queries generated at your site. The forwarder develops a cache of answers to queries, thus reducing the number of requests to root name servers and improving DNS performance. For example, you can use the address for the name server that is authoritative for the zone above yours.
Note: If you use forwarders, try to keep your configuration simple and avoid chaining forwarders so A doesn't forward to B, B to C, and C back to A, for instance.
- secondary
- The name of the domain for which this computer will act as a secondary name server. A secondary name server uses a process called a zone transfer to load data over the network from another name server, instead of reading data from its own files. You should have at least one secondary server for your site, but you do not need to be a secondary server for anyone else. Although not necessary, designating one or more secondary name servers helps to make the DNS more robust.
The next example shows how to specify secondary name servers. If you have a large number of domains, this alternative layout might be easier to use than the one in the first example. The structure is essentially the same, but the filenames use the domain name rather than the IP subnet address to describe the contents.
cache . multinet:domain-name-service.cache
;
; Primary servers
;
primary fr.net fr.net
primary frmug.fr.net frmug.fr.net
primary 127.in-addr.arpa 127
;
; Secondary servers
;
secondary ensta.fr 147.250.1.1 ensta.fr
secondary gatelink.fr.net 134.214.100.1 gatelink.fr.net
secondary insa-lyon.fr 134.214.100.1 insa-lyon.fr
secondary loesje.org 145.18.226.21 loesje.org
secondary nl.loesje.org 145.18.226.21 nl.loesje.org
secondary pcl.ac.uk 161.74.160.5 pcl.ac.uk
secondary univ-lyon1.fr 134.214.100.1 univ-lyon1.fr
secondary wmin.ac.uk 161.74.160.5 wmin.ac.uk
secondary westminster.ac.uk 161.74.160.5 westminster.ac.uk
;
;
; Secondary for addresses
;
secondary 74.161.in-addr.arpa 161.74.160.5 161.74
secondary 214.134.in-addr.arpa 134.214.100.1 134.214
secondary 250.147.in-addr.arpa 147.250.1.1 147.250
;
; Classes C
;
secondary 56.44.192.in-addr.arpa 147.250.1.1 192.44.56
secondary 57.44.192.in-addr.arpa 147.250.1.1 192.44.57
- To designate a secondary server for another domain, you can enter a line into the NAMED.BOOT similar to the following:
secondary gu.uwa.edu.au 130.95.100.3 130.95.128.1
- You can specify several IP addresses for your machine to query. On startup, your copy of .NAMED will try to obtain information about those domains from all specified machines. Then .NAMED remembers the information and acts as if it were the authoritative server for those domains.
Next create the data files that contain the name definitions.
You can use File Transfer Protocol (FTP) to get a copy of the cache file from ftp.rs.internic.net, or copy and paste the following:
; 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: Nov 8, 1995
; related version of root zone: 1995110800
;
;
; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
;
; formerly C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;
; formerly TERP.UMD.EDU
;
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;
; formerly NS.NASA.GOV
;
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;
; formerly NS.ISC.ORG
;
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
;
; formerly NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
; End of File
Here is an example of a forward-mapping file. Explanations follow the example.
; Authoritative data for ecel.uwa.edu.au
;
@ IN SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. (
93071200 ; Serial (yymmddxx)
10800 ; Refresh 3 hours
3600 ; Retry 1 hour
3600000 ; Expire 1000 hours
86400 ) ; Minimum 24 hours
IN A 130.95.4.2
IN MX 100 decel
IN MX 150 uniwa.uwa.edu.au.
IN MX 200 relay1.uu.net.
IN MX 200 relay2.uu.net.
localhost IN A 127.0.0.1
decel IN A 130.95.4.2
IN HINFO SUN4/110 UNIX
IN MX 100 decel
IN MX 150 uniwa.uwa.edu.au.
IN MX 200 relay1.uu.net
IN MX 200 relay2.uu.net
gopher IN CNAME decel.ecel.uwa.edu.au.
accfin IN A 130.95.4.3
IN HINFO SUN4/110 UNIX
IN MX 100 decel
IN MX 150 uniwa.uwa.edu.au.
IN MX 200 relay1.uu.net
IN MX 200 relay2.uu.net
chris-mac IN A 130.95.4.5
IN HINFO MAC-II MACOS
Comments (;)
The first two lines in the file are comments, which explain the file's contents.
@ Sign
The "at" sign (@)–the first character in the line–defines the domain for which this file is authoritative. All records between @ and localhost refer to the most recent machine or domain name.
SOA Record
The first section is the start of authority (SOA) resource record:
@ IN SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. (
93071200 ; Serial (yymmddxx)
10800 ; Refresh 3 hours
3600 ; Retry 1 hour
3600000 ; Expire 1000 hours
86400 ) ; Minimum 24 hours
IN A 130.95.4.2
There can be only one SOA record in a data file. All values shown contain IN, which indicates that the value is an Internet record. The SOA record contains information for the other name servers about this domain and how to treat the information they are given. The domain name is found in the NAMED.BOOT file in the line corresponding to this filename.
The address decel.ecel.uwa.edu.au is the address of the machine running your .NAMED file–the machine that created this data. The next, postmaster.ecel.uwa.edu.au, is an e-mail address for the person responsible for the data in the DNS. Typically, you use postmaster, hostmaster, or root.
Note: Use dots (.), not the "at sign" (postmaster@....), to delimit the e-mail address.
The SOA record contains five important values:
- Serial number. Identification number the secondary name server uses to decide if its zone data is up to date. If the secondary's serial number is lower than the master server's number, the zone data on the secondary is determined to be outdated. When the data is out of date, the secondary pulls up a new copy of the zone. If you change the file, always change the serial number, or other name servers will not update their information. This example uses the creation date in the format yymmddxx.
- Refresh. The time in seconds to check accuracy of data and refresh information about the SOA.
- Retry. The frequency in seconds to retry if an authoritative server cannot be contacted. The retry interval is usually shorter than the refresh interval.
- Expire. The time in seconds that a secondary name server will keep information about a zone without successfully updating it or confirming that the data is up to date. This is to help the information withstand long downtimes of machines or connections without having to re-collect all the information.
- Minimum. The default time-to-live (TTL) value handed out by a name server for all records in a zone without an explicit TTL value. The TTL is the amount of time the data will be cached before being discarded.
Now you can map ecel.uwa.edu.au to an address – 130.95.4.2 – which in this case is decel, the main machine. If you try to find an IP number for the domain ecel.uwa.edu.au, you will get the IP number for decel.ecel.uwa.edu.au.
MX Record
Mail exchanger (MX) records specify either process or forward mail destined for the machine or domain. Processing the mail means either delivering it to the recipient or routing it elsewhere via a gateway. Forwarding the mail means either sending it on to its final destination, sending it to another MX, or queuing it until it can be delivered later. This allows people with non-MX mailers to send e-mail to the address fred@ecel.uwa.edu.au without having to know the precise name of the machine having authority over Fred's domain.
IN MX 100 decel
IN MX 150 uniwa.uwa.edu.au.
IN MX 200 relay1.uu.net
IN MX 200 relay2.uu.net
The smallest number indicates the site to try first. The larger the number, the lower in priority the site is.
In this example, all mail for fred@ecel.uwa.edu.au is routed first to decel.ecel.uwa.edu.au. If that does not work (decel is down, for example), Fred's mail is routed to uniwa.uwa.edu.au. If uniwa routing fails, then the network tries site relay1.uu.net.
You can assign an MX record to every machine capable of handling mail. This allows mail to be cached on remote machines and will help to reduce the load on the network.
Note: Not all machines have mailers that pay attention to MX records; some pay attention only to IP numbers. All machines must have MX-capable Mail Transfer Agents (MTAs), as there are many addresses that can only be reached this way.
Localhost
The localhost line creates a machine called localhost.ecel.uwa.edu.au:
localhost IN A 127.0.0.1
decel IN A 130.95.4.2
IN HINFO SUN4/110 UNIX
IN MX 100 decel
IN MX 150 uniwa.uwa.edu.au.
IN MX 200 relay1.uu.net
IN MX 200 relay2.uu.net
The machine decel, with an IP number 130.95.4.2, is the main host in the domain.
If you use Finger to get information about localhost or connect via Telnet the name lookup returns 127.0.0.1, which is the address for your machine. Other DNS packages, such as the Sun OS or UC Berkeley BSD-type operating system, may handle this situation differently.
Note there are also some MX records to route mail for localhost. MX records are explained in the preceding section
HINFO
The Host Information (HINFO) values identify the host's hardware type and operating system.
HINFO values are generally the Official Machine Names as they appear in the Domain Name System HINFO records and the NIC Host Table. An entry in HINFO is optional.
A machine name or CPU type in HINFO may be up to 40 characters long, and must contain uppercase letters,
digits, and the two punctuation characters, hyphen (-) and forward slash (/). It must start with a letter and end
with a letter or digit.
Note: Refer to RFC 1700,
Assigned Numbers, for the complete up-to-date list of official machine names. RFC 1700 lists useful
information such as services values, Ethernet manufacturer hardware addresses, HINFO preferred values,
and much more. Their use is described in RFC-952. Also see the Appendix of this document for a list of official system names and for details about how to obtain RFCs 952, 1700, or others, via the Internet.
Note the two HINFO lines from the example:
IN HINFO SUN4/110 UNIX
and
IN HINFO MAC-II MACOS
- The HINFO line for decel identifies it as a Sun Microsystems 4/110 running the UNIX operating system.
- The second HINFO line is for a Macintosh on the network that needs an IP number. The HINFO line lets you see that it is a Mac II running a Mac OS.
For example, if you want this Mac to appear like a fully connected UNIX machine for Internet services, you can enter the following MX record:
IN MX 100 decel
This causes any mail sent to chris@chris-mac.ecel.uwa.edu.au to automatically reroute to decel.
CNAMEs
CNAME stands for canonical name. A CNAME acts as an alias to point a query to a specified leaf node.
In the example, the address of the Gopher server is gopher.ecel.uwa.edu.au. Using a CNAME allows you to avoid maintaining a separate server just for Gopher requests. The example shows how to designate a CNAME that points Gopher requests to your main machine. Then, if you find the server has become filled with large files, such as digital movies, graphics, or very long documents, you can change CNAME to point to a different machine. You can also use CNAMEs to point to and maintain FTP, mailhost, netfind, Archie, Whois, or DNS, which makes it easier for people to find these services in your domain.
A reverse name lookup finds the PTR record (address-to-name mapping record) associated with the domain name.
IP addresses and domain names are both arranged in a hierarchy. Domain names become less specific as you read them from left to right (ecel.uwa.edu.au –> server –> university –> all educational institutions –> country); IP addresses become more specific when read from left to right.
To find the name associated with the IP number 1.2.3.4, look for information stored in the DNS under the name 4.3.2.1.in-addr.arpa. The addresses are organized this way so that when you are allocated a B class subnet, for instance, you are allocated all the IP numbers in the domain 130.95. To turn that into a reverse name lookup domain, invert the numbers. For example, the IP address of decel is 130.95.4.2 and the reverse lookup, which goes leaf-to-root, becomes 2.4.95.130.in-addr.arpa.
If you want more information about assigning IP addresses, see "Beginning IP for New Users."
Here is the example reverse name lookup file:
0.0.127.in-addr.arpa
--
; Reverse mapping of domain names 0.0.127.in-addr.arpa
; This makes 127.0.0.1 -> localhost.
@ IN SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. (
91061801 ; Serial (yymmddxx)
10800 ; Refresh 3 hours
3600 ; Retry 1 hour
3600000 ; Expire 1000 hours
86400 ) ; Minimum 24 hours
;
1 IN PTR localhost.ecel.uwa.edu.au.
--
4.95.130.in-addr.arpa
--
; reverse mapping of domain names 4.95.130.in-addr.arpa
;
@ IN SOA decel.ecel.uwa.edu.au. postmaster.ecel.uwa.edu.au. (
92050300 ; Serial (yymmddxx format)
10800 ; Refresh 3hHours
3600 ; Retry 1 hour
3600000 ; Expire 1000 hours
86400 ) ; Minimum 24 hours
2 IN PTR decel.ecel.uwa.edu.au.
3 IN PTR accfin.ecel.uwa.edu.au.
5 IN PTR chris-mac.ecel.uwa.edu.au.
--
You need an SOA record for each reverse name lookup. The SOA details are the same as for the forward mapping. (Note that the result of the reverse name lookup on the 127 domain is obvious, as there is only one number in the file.)
Each of the numbers listed down the left-hand side indicates that the line contains information for that number of the subnet. Each of the subnets must be the more significant digit, for example, the 130.95.4 in IP number 130.95.4.2 is implicit for all numbers in the file. The PTR must point to a machine that can be found in the DNS.
Reverse name lookups are optional. Use of reverse name lookups can be helpful for troubleshooting, because they allow you to see where people have logged in from. In addition, some protocols, such as talk, won't allow you to connect to a machine that doesn't have a name.
When domain grows too large, it can be broken into several logical and separate entities, in which each can look after its own DNS. Maintain a central area for information that everyone needs to see, and delegate the authority for the other parts of the organization to allow them to manage themselves.
Here is an example. The authoritative name server for the zone uwa.edu.au delegates the authority for the zone ecel.uwa.edu.au to another zone called decel.ecel.uwa.edu.au. A node named foo.ecel.uwa.edu.au is actually in the zone for which decel is authoritative. Machine bar.uwa.edu.au is in yet another zone for which the domain uniwa.uwa.edu.au is authoritative.
Every domain that exists must have name server (NS) records associated with it. 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 must have created an NS record for your machine in your domain.
In the next example, the computer club (ucc) is connected to the network and given control over its own part of the domain space.
@ 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.
Mackerel is the authoritative server for gu.uwa.edu.au; marlin is authoritative for ucc.gu.uwa.edu.au. For convenience, marlin is assigned an IP in another domain. (Alternatively, you can place marlin.ucc in the first column, leaving it inside the ucc domain.)
The second NS line indicates mackerel will act as secondary name server for the ucc.gu domain. (Do not designate a server a secondary if you are not authoritative for the information included in the subdomain.)
(Click on the title to read this document).
The examples and much of the information contained in this document was furnished by Craig Richmond (craig@ecel.uwa.edu.au).
For further reading on the Domain Naming System, we recommend DNS and BIND in a Nutshell by Paul Albitz and Cricket Liu; O'Reilly & Associates; Inc., Sebastopol, CA; 1992.
Posted: Fri Apr 11 11:19:06 PDT 1997