Process Software: DNS Defined - Maintaining the DNS Database

To set up the DNS database for your zone, you need to maintain zone data in different database files and resource records in these files.

This chapter describes how to start a primary and secondary server, and the database files and resource records needed to administer these servers.

Starting a Primary and Secondary Server

When you start a name server, you'll want the server to immediately identify the directory where you want to store the database files and the names of these files.

In the case of TCPware, the configuration procedure generates a boot file, named.boot. TCPware follows the BIND convention. The boot file is read when the name server is started. The server finds the files, reads them, and builds the database.

Set up the primary server first, such as in the named.boot file in Example 1.

Example 1 Boot File for a Primary Server

; Data file to boot a primary name server.
;
; directory that stores all the data files
directory TCPWARE_ROOT:[TCPWARE.NAMED]
;
; type	       domain                      Source
host/file
primary	       process.com                 NAMED.HOSTS
primary	       95.42.192.in-addr.arpa      NAMED.REV
primary	       138.115.198.in-addr.arpa    NAMED.REV2
primary	       0.0.127.in-addr.arpa        NAMED.LOCAL
;
; load the cache data last
cache                                      DB. CACHE

In this DNS implementation, the boot file indicates the directory that stores all the name server data files and primary server and cache information. The primary server is for the process.com. domain. The reverse mapping domain name for this is 95.42.192.IN-ADDR. ARPA..

The data points to five different files. (Note the dot in the domain column.)

named.hosts — stores all host and address data for the zone

named.rev and named.rev2 — store the reverse domain name mapping data

named.local — stores the loopback address of the server host

db. cache — stores the root server data for caching purposes

Again, these filenames follow the BIND convention; other implementations might use a filename like rootservers, named.root, or named.ca instead of db.cache.

The named.hosts, named.rev, named.rev2, named.local, and db.cache files contain resource records. (More on resource records shortly.)

Also set up at least one secondary name server. Copy the named.rev, named.rev2, and db.cache files to the secondary server; these do not change. The named.local file is closely related but needs some SO A record changes.

Also copy the named.boot file, but make changes to it. Change the word primary to secondary, except on the local loopback line, and add the primary server's address before each backup filename in the secondary records, as in Example 2. Compare this to Example 1.

Example 2 Boot File for a Secondary Server

; Data file to boot a secondary name server.
; directory that stores all the data files
directory	TCPWARE_ROOT:[TCPWARE.NAMED]
;
; type	   domain                    primary         backup file
secondary  process.com	             192.42.95.1     NAMED.HOSTS
secondary  95.42.192.in-addr.arpa    192.42.95.1     NAMED.REV
secondary  138.115.198.in-addr.arpa  192.42.95.1     NAMED.REV2
primary    0.0.127.in-addr.arpa                      NAMED.LOCAL
;
; load the cache data last
cache                                                DB. CACHE

Database Files

The database files defined in a properly configured boot file store all name server information for a zone. Table 3 lists the name, contents, and use of each file.

Table 3 DNS Database Files
File	Contents	Use
named.hosts	Host and address information for the entire namespace for which the name server has authority	Primary and secondary servers for host-name-to-IP-address mapping
named.rev	Reverse mapping information that returns a host domain name when given an IP address	Primary and secondary servers for IP-address-to-host-name mapping
named.local	Local loopback address	All name servers
named.ca	Internet address of the name servers that are the authority for the domain, and the root servers, for caching purposes	All name servers

Sample Configuration

Figure 6 shows a sample Class C network configuration (the hosts share the first three octets in the internet address). All the hosts are in the process.com. domain.

Figure 6: Sample Network Configuration

Example 3 shows the named.boot file set up on host sirius.process.com. (address 192.42.95.1) for the configuration in Figure 6. Note the entries for the other database files and the reverse address mapping data. (Note that the 198.115.138 network set up in named.rev2 is not shown in the figure.)

Example 3 named.boot File for Sample Network

directory        TCPWARE_ROOT:[TCPWARE.NAMED]
;
; type      domain                      source host/file
primary	    process.com                 NAMED.HOSTS
primary	    95.42.192.in-addr.arpa      NAMED.REV
primary	    138.115.198.in-addr.arpa    NAMED.REV2
primary	    0.0.127.in-addr.arpa        NAMED.LOCAL
;
cache                                   DB.CACHE

Resource Records

The remaining database files stored and maintained on the name server (named.hosts, named.rev, named.local, and named.ca) use resource records as their data structure. It's best to describe these records first before describing the type of data in each database file.

The standard format of a resource record is:

owner    ttl    class type    data

Tabs or spaces separate the individual fields. The first field (owner) must start in column one on each line. Example 4 shows a sample record.

Example 4 Sample Resource Record

ns.nasa.gov.    99999999    IN A    128.102.16.10

In Example 4:

ns.nasa.gov. is the owner field value identifying the owner domain associated with the record. The dot after gov makes the domain name fully qualified. If you omit the dot, you have a relative domain name (see the paragraph below for an explanation).
99999999 is the ttl field value identifying the time to live (TTL) for a record (in seconds); in this case, an intentionally large value. TTL specifies how long a name server should cache the record before discarding the cached data and proceeding to query another name server for it. You can often omit this value since you set the TTL value by default in the minimum time-to-live field of the Start of Authority (SOA) record. (More on SOA records further on.)
IN is the class field value identifying the protocol group. In most cases, this is the Internet protocol group (IN). (There are also CHAOS [CH] and Hesiod [HS] classes, but these aren't in widespread use.) Since all zone data is generally in the same protocol group, you only need to use this field in the first record of the zone.
A is the type field value identifying the type of record, in this case an Address (A) record.
128.102.16.10 is the data field value that varies with each type of record. In this case, the Address (A) record requires the internet address as a data value.

Note: Specify fully qualified domain names (those with a dot at the end) unless you want to specify relative domain names. DNS appends the relative domain onto the end of a non-fully-qualified name. You can define the relative domain in the named.boot file entry and can alter this using a $origin directive in any file (see the Shortcuts and Suggestions section further on for an explanation). Address (A) records often contain relative domain names — more on A records further on.

Common Record Types

Table 4 shows the most common record types found in server database files. Although the actual order doesn't matter, SOA records should be first.

Table 4 Common DNS Resource Record Types
Resource Record	Meaning	Description
SOA	Start of authority	Designates the start of zone data. This should be the first record in a file.
NS	Name server	Lists the name of the machine that provides domain service. Since it’s preferable to have multiple name servers for a domain, there are usually multiple NS records.
A	Address	There should be one A record for each host address in a domain. Also use an A record as a glue record for name servers outside the zone (more on this later).
CNAME	Canonical name	Specifies an alias for a host with its official, or canonical, name. Any other record uses the host’s canonical name and never its alias.
HINFO	Host information	Provides optional hardware and software data for a host.
WKS	Well-known services	Lists well-known services a host provides, including the protocol .(TCP, UDP) and the services (TELNET, FTP, SMTP) on port number below 256.
MX	Mail exchanger	Determines where you want mail for a domain delivered. A file can have multiple MX records, one for each delivery machine. The record’s data fields include delivery preference and host name.
PTR	Pointer	Used mainly in reverse address mapping and to define gateways (more on this later)

Occasionally you will find special characters in a record. These characters have specific meanings, defined in the next table.

Table 5 Special Characters Used in Records
Character	Symbol	Meaning
Parentheses	()	Group data that exceed a line boundary, often the case in SOA records
Semicolon	;	Starts a comment line; remainder of the line is ignored by the software
At sign	@	Denotes the current domain name as identified in the boot file
Asterisk	*	Used as a wildcard

Start of Authority Records

Example 5 shows a Start of Authority (SOA) record for the configuration in Figure 6. (Note the use of parentheses to group the multi-line data.)

Example 5 Sample SOA Record

@ IN SOA sirius.process.com.
jdoe.sirius.process.com. (
          99       ;     Serial
          28800    ;     Refresh
          7200     ;     Retry
          604800   ;     Expire
          86400 )  ;     Minimum

In Example 5:

@ identifies the origin domain name (in this case, process.com) derived from the boot file, named.hosts.
IN is the protocol class (Internet).
SOA is the record type (Start of Authority).
sirius.process.com. is the name of the host with the authority for the data contained in the current file.
jdoe.sirius.process.com. is the mailbox for the person responsible for the zone, originally jdoe@sirius.process.com. You must substitute full dot notation for the original notation (since the @ has special meaning in the file) and make the name fully qualified or DNS won't recognize the mailbox.
28800 (eight hours, in seconds) is the refresh time interval a secondary name server waits before checking for an updated zone file serial number and making a zone transfer. If you make more frequent changes, the value should be lower.
72001 (two hours, in seconds) is the retry time interval a secondary name server waits to retry the primary name server after a failed refresh attempt.
6048001 (seven days, in seconds) is the expiration time of the zone data if the secondary server can't reach the primary server. After that interval, the secondary server data ceases to be authoritative for the zone.
86400 (one day, in seconds) is the minimum time-to-live for the zone data (no TTL values explicitly defined in other records can be less). Secondary servers will use the same value as the primary.

Name Server Records

Example 6 contains Name Server (NS) records for the configuration in Figure 6. In the records:

@ identifies the origin. Note that you can omit the @ if you already used it in the previous SOA record. This pertains to the IN field as well.
NS is the record type. Note that if you want to set an explicit TTL value for the record, you place it just before this field.
sirius.process.com. and root servers nic.near.net and bu.edu. are the zone's name servers. Also, delta.process.com is the name server for the cluster.process.com domain.

Example 6 Sample NS Records

@          IN     NS     sirius.process.com.
           IN     NS     nic.near.net.
           IN     NS     bu.edu.
cluster    IN     NS     delta.process.com.

Address Records and Glue Records

Example 7 shows Address (A) records for all the hosts on process.com, including the ones for the local host (the loopback address, 127.0.0.1) and name server sirius. Note that you could have included a TTL value, positioned just before the type field. Note also that the hostnames (except localhost.) appear in relative naming format: sirius is actually sirius.process.com..

Example 7 Sample A Records

localhost.     A     127.0.0.1
sirius         A     192.42.95.1
rigel          A     192.42.95.2
deneb          A     192.42.95.3
vega           A     192.42.95.4
altair.subz   NS     altair.subz.process.com
               A     192.42.95.5              ;glue record

In the example, a new name server altair.subz.process.com. (not shown in the diagram) is introduced. It isn't part of process.com, but is part of a new subz.process.com subzone (or child zone). Because this server is outside the current zone, it needs a glue record — the A record that immediately follows it.

The glue record provides the necessary address of the name server that the NS record doesn’t provide. It essentially “glues” the A record together with the associated NS record in the subzone's database. It isn't part of the authoritative data, but is necessary as a referral. According to RFC 1034, “parent zones [must] have all the information needed to access servers for their children zones.”

RFC 1537 warns against using unnecessary or wrong glue records. If you add a wrong glue record, the zone transfer might never happen.

A Records, Host Information Records, and Canonical Name Records

Example 8 shows a Host Information (HINFO) record and a Canonical Name (CNAME) record grouped with an A record for the configuration in Figure 6.

Example 8 Sample A, HINFO., and CNAME Records

sirius        IN A         192.42.95.1
              IN HINFO     "VAXstation	4000-90" "VMS V5.5-2"
nfsserver     IN CNAME     elnath

The HINFO record is the host information for sirius, identifying it as a VAXstation-4000-90 running VMS V5.5-2. The first field is the hardware and the second field is the operating system. If there are spaces in the text, you have to embed the text in quotes. Note that the second field isn't optional: if you don't want to identify an operating system, you still have to include a pair of quotes as a value.

In the CNAME record, nfsserver identifies the nickname (alias) for canonical name host elnath. When you query an alias, using ping, for example, the name server cross-references the canonical name and uses it to look up the information.

If the canonical name has two address records, such as for a gateway, the name server returns both addresses. However, if you want to distinguish between two gateway interface addresses, create an alias for each interface and add an A record instead of a CNAME record for each alias.

Well Known Services Records

Example 9 shows sample Well Known Services (WKS) records. These records are advisory only and describe the kind of services a protocol provides on a particular interface. Separate the service names or port numbers with spaces. If you use service names, they have to appear in your /etc/services or similar type file.

Example 9 Sample A and WKS Records

algol     IN WKS     192.42.95.6     TCP     TELNET FTP SMTP
             WKS     192.42.95.6     UDP     TIME
castor       WKS     192.42.95.7     TCP     TELNET

In the example, host algol provides TELNET, FTP, and SMTP over TCP, and the TIME service over UDP; castor provides only TELNET over TCP.

Mail Exchanger Records

Example 10 shows Mail Exchanger (MX) records for the configuration in Figure 6. (More on MX records in the next chapter.)

Example 10 Sample A and MX Records

process.com.     IN MX     0     sirius.process.com.
process.com.     IN MX    10     elnath.process.com.
process.com.     IN MX    20     hadar.process.com.

In the MX records, the preference values 0,10, and 20 indicate that your system should send mail addressed to process.com first to sirius. If sirius isn't available, the mail should then go to elnath, and so on. The lower the number, the higher the preference. Preference values can range from 0 to 65535. You can give the same preference value to more than one mail host.

Pointer Records for Reverse Address Mapping

According to BIND conventions, reverse address mapping occurs in a named.rev file on the server. These files use Pointer (PTR) records to implement the reverse mapping.

Example 11 shows a sample named.rev file for the configuration in Figure 6.

@ identifies the origin, derived from the named.boot file, as 95.42.192.in- addr.arpa..
The PTR records begin with the numbered host names 1,2, 3, and 4. They are in relative hostname specification; read in full, these host names would be 1.95.42.192.in-addr.arpa. and so on. Note that PTR records can only point to canonical names and never aliases.

Example 11 Sample named.rev File Showing PTR Records

; Data file for 95.42.192.in-addr.arpa domain (reverse mapping).
;
@     IN SOA     sirius.process.com.
jdoe.sirius.process.com (
                        94          ; Serial
                        86400       ; Refresh
                        600         ; Retry
                        3600000     ; Expire
                        86400   )   ; Minimum
      IN NS     sirius.process.com.
      IN NS     nic.near.net.
      IN NS     bu.edu.
1     IN PTR    sirius.process.com.
2     IN PTR    rigel.process.com.
3     IN PTR    deneb.process.com.
4     IN PTR    vega.process.com.

PTR Records Defining Gateways

Suppose that the gateway shown in Figure 6 connects to another Class C network, other.com., as shown in Figure 7.

Figure 7: Sample Gateway Configuration

Even though the gateway host is in process.com. and has the domain name process-gw.process.com., it has two addresses corresponding to the two different networks. On network process.com., its address is 192.42.95.123; on network other.com., its address is 198.15.138.1.

How do you set up gateway information in the database files?

First set up the A records for the gateway in the named.hosts file for the zone (process.com.) that contains the gateway, as follows:

process-gw.process.com.     IN A     192.42.95.123
                               A     198.15.138.1

Then set up PTR records in the named.rev files for both zones. The process.com. database has in it both the gateway location pointer and the reverse mapping pointer:

95.42.192.in-addr.arpa.     IN PTR     process-gw.process.com
                               PTR     process-gw.process.com

The other.com. database will also have the corresponding data:

138.15.198.in-addr.arpa.    IN PTR     process-gw.process.com
                               PTR     process-gw.process.com

process-gw.process.com. could also have been set up as a name server. In fact, gateways and routers make good name servers. They are generally well connected (accessible to multiple networks and domains) and closely monitored — there is less of a chance of them going down.

Other Record Types

There are also other record types that have occasional usage.

MINFO (Mail Info) is similar to HINFO except that it identifies the domain name style mailbox, in dotted decimal notation, for a mailing list and the mailbox that receives error messages.
TXT (Text) is like a comments line, in quotation marks, to follow another record; the limit is 256 characters.
ISDN (Integrated Services Digital Network) specifies telephone numbers for this type of system.
X25 (X.25) specifies the Public Switched Data Network (PSDN) address for X.25 networks.
RT (Route Through) is for ISDN and X.25 networks and specifies the intermediary host that routes packets to a destination host, and is syntactically like an MX record.

Shortcuts and Suggestions

You can use the $origin directive to change the origin specification in a file. The syntax is: $origin domain-name.

In database files other than the boot file, make sure to add a trailing dot at the end of a domain name you want to be fully qualified. Names without trailing dots are relative domain names and have the origin domain name appended after them.

You can use the $include directive to include an external file in a database file. The syntax is: $ include filename [origin-domain-name] . Note that you can optionally specify a relative origin domain name for the included file or do so within that file, although this doesn't change the relative origin in the database file itself. Include files often contain MX or other records you can update more easily in a separate, external file.

Remember that all resource records have to be of the same protocol class (group) in a database file.

Sample Database Files

`named.hosts`

Example 12 shows the named.hosts file for the configuration in Figure 6.

Example 12 Sample named.hosts File

@     IN SOA     sirius.process.com. jdoe.sirius.process.com. (
                 99        ; Serial
                 86400     ; Refresh
                 1800      ; Retry
                 3600000   ; Expire
                 86400 )   ; Minimum
                 IN NS     sirius.process.com.
                 IN NS     nic.near.net.
                 IN NS     bu.edu.
cluster          IN NS     delta.process.com.
localhost.       IN A      127.0.0.1
process.com.     IN MX     0     sirius.process.com.
process.com.     IN MX     10    elnath.process.com.
process.com.     IN MX     20    hadar.process.com.
process.com.     IN A      192.42.95.1
sirius           IN A      192.42.95.1
                 IN HINFO  "VAXstation 4000-90" "VMS V5.5-2"
nfsserver        IN CNAME  elnath
rigel            IN A      192.42.95.2
deneb            IN A      192.42.95.3
vega             IN A      192.42.95.4

`named.rev`

Example 13 shows the named.rev file for the configuration in Figure 6.

Example 13 Sample named.rev File

@     IN SOA     sirius.process.com. jdoe.sirius.process.com.
(
                 94          ; Serial
                 86400       ; Refresh
                 600         ; Retry
                 3600000     ; Expire
                 86400)      ; Minimum 
        IN NS    sirius.process.com.
        IN NS    nic.near.net.
        IN NS    bu.edu.
        IN PTR   sirius.process.com.
2       IN PTR   rigel.process.com.
3       IN PTR   deneb.process.com.
4       IN PTR   vega.process.com.

`named.local`

Example 14 shows the named.local file for the configuration in Figure 6. This file uses the 0.0.127.in-addr.arpa. standard local loopback reverse mapping address as its origin. The localhost points to the address 1.0.0.127.in-addr.arpa..

Example 14 Sample named.local File

@    IN SOA	sirius.process.com. jdoe.sirius.process.com. (
                2        ; Serial
                3600     ; Refresh
                600      ; Retry
                3600000  ; Expire
                86400)   ; Minimum
     IN NS      sirius.process.com
1    IN PTR     localhost.

The named.local file, like db.cache (next), is basically an overhead file that doesn't change much from server to server. However, it is necessary on the server because if an application requests a local loopback, a local mapping to 0.0.127 has to be in place. No other name server is in the position to do the mapping.

`db.cache`

Example 15 shows the db.cache file with the caching information records for the sample configuration in Figure 6. Note the dot in the first field of the first record; this identifies the root domain. You should set the TTL values intentionally high, as was done here.

Example 15 Sample db.cache File

.                     3600000   IN NS     A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.   3600000      A      198.41.0.4
.                     3600000      NS     B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET    3600000      A      128.9.0.107
.                     3600000      NS     C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.   3600000      A      192.33.4.12
.                     3600000      NS     D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.   3600000      A      128.8.10.90
.                     3600000      NS     E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.   3600000      A      192.203.230.10
.                     3600000      NS     F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.   3600000      A      192.5.5.241
.                     3600000      NS     G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.   3600000      A      192.112.36.4
.                     3600000      NS     H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.   3600000      A      128.63.2.53
.                     3600000      NS     I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.   3600000      A      192.36.148.17

What Do I Do When?

This section contains the specific instructions for how to add a new subdomain and host, delete a host, and add and delete gateways.

Add A Subdomain

Set up the new domain servers.
Add a boot file for each new server (named.host).
Add an NS record for each new server to the parent database in the named.hosts file.
Add any necessary glue records to the zone database in the named.hosts file.

Add a Host

Add the host to the zone database in the named.hosts file.
Add A records and, if necessary, CNAME, HINFO, WKS, and MX records, to the named.hosts file.
Add the reverse address mapping data in the named.rev file.

Delete a Host

Remove all host records from the zone database (the named.hosts file).
Remove all PTR records from the reverse address mapping file (named.rev)

Add a Gateway

Add host data.
Add the gateway location PTR records for each network the gateway is on to the named.hosts file.

Delete a Gateway

Delete host data.
Delete gateway location FFR records for each network the gateway is on from the named.hosts file.

Some other tips

Here are some other tips to remember when working with subdomains, hosts, and gateways.

Don't use IP addresses as domain names. This creates an unnecessary load on root servers.
Always notify domain/zone managers, system administrators, or whoever is responsible about any additions or changes to a database.
Remember to add the extra dot at the end of a domain name to make them fully qualified when necessary.
Make sure to increment the serial numbers in the SOA records whenever you edit the database files.