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.
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.)
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 220.127.116.11 NAMED.HOSTS secondary 95.42.192.in-addr.arpa 18.104.22.168 NAMED.REV secondary 138.115.198.in-addr.arpa 22.214.171.124 NAMED.REV2 primary 0.0.127.in-addr.arpa NAMED.LOCAL ; ; load the cache data last cache DB. CACHE
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.
|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|
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.
Example 3 shows the named.boot file set up on host sirius.process.com. (address 126.96.36.199) 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
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 188.8.131.52
In Example 4:
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.
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.
|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.
|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|
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:
Example 6 contains Name Server (NS) records for the configuration in Figure 6. In the records:
@ IN NS sirius.process.com. IN NS nic.near.net. IN NS bu.edu. cluster IN NS delta.process.com.
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 184.108.40.206 rigel A 220.127.116.11 deneb A 18.104.22.168 vega A 22.214.171.124 altair.subz NS altair.subz.process.com A 126.96.36.199 ;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.
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 188.8.131.52 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.
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 184.108.40.206 TCP TELNET FTP SMTP WKS 220.127.116.11 UDP TIME castor WKS 18.104.22.168 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.
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.
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.
; 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.
Suppose that the gateway shown in Figure 6 connects to another Class C network, other.com., as shown in Figure 7.
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 22.214.171.124; on network other.com., its address is 126.96.36.199.
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 188.8.131.52 A 184.108.40.206
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.
There are also other record types that have occasional usage.
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.
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 220.127.116.11 sirius IN A 18.104.22.168 IN HINFO "VAXstation 4000-90" "VMS V5.5-2" nfsserver IN CNAME elnath rigel IN A 22.214.171.124 deneb IN A 126.96.36.199 vega IN A 188.8.131.52
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.
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 184.108.40.206.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.
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 220.127.116.11 . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET 3600000 A 18.104.22.168 . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 22.214.171.124 . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 126.96.36.199 . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 188.8.131.52 . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 184.108.40.206 . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 220.127.116.11 . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 18.104.22.168 . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 22.214.171.124
This section contains the specific instructions for how to add a new subdomain and host, delete a host, and add and delete gateways.
Here are some other tips to remember when working with subdomains, hosts, and gateways.