DNS zone files are used to resolve domain names to the domain's assigned IP addresses. These files, by default, are found under the /var/named directory and are typically named db.domain.com or domain.com.db. In these examples, we will use db.example.com. The following is a sample forward DNS file for a master (primary) record:
@ IN SOA ns.example.com. root.example.com. ( 1999080101 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) IN NS ns1.example.com. IN NS ns2.example.com. IN MX 0 mail.example.com. IN A 192.168.0.212 localhost IN A 127.0.0.1 www IN A 192.168.0.212 ns1 IN A 192.168.0.10 ns2 IN A 192.168.0.11 ftp IN CNAME www mail IN CNAME www irc IN CNAME irc.example.net.
The first section is the SOA (start of a zone authority) entry. The SOA entry contains the domain of the originating host, the domain address of the maintainer, the file serial number, and various time parameters (refresh, retry, expire, and minimum time to live).
The second section of the preceding sample /var/named/db.example.com specifies the domain's primary and secondary DNS servers. These are denoted by the NS tokens. The first NS entry is the primary DNS server, and the second NS entry specifies the secondary DNS server. You can also add tertiary and further DNS servers with the same NS entries.
The third section includes other references, options, and settings for the domain entry. The A tokens point to host addresses. For example, the A token in this example sets the domain example.com to 192.168.0.212. Another A token sets www.example.com to 192.168.0.212 as well. An additional token used in this example section is CNAME (canonical name). The CNAME token points an alias to the appropriate IP address or domain. In the above example, ftp.example.com points to the same address as www, which was already defined as 192.168.0.212. Also, mail.example.com is directed to www. There is also a CNAME pointer for irc.example.com that redirects the request to an Internet Relay Chat (IRC) server, located in this example at irc.example.net.
The MX (mail exchange) token points to the mail exchange server for the domain. When the mail server program, such as Postfix, processes an email message, it first looks for this record of the destination address. If you want reliable mail delivery, you should specify an additional MX record pointing to another mail server. While mail shouldn't be dropped if the single mail server is unavailable for a while, it will be delayed.
MX 30 mailserver MX 60 mailserver.backup.com MX 90 mailserver.localdomain.org
The relative priority of an MX server is determined by the preference number (the second field) in the DNS MX record. The smallest preference number has the highest priority and is the first server to be tried.
Table 37-1 summarizes the types of heads you need to know in zone files.
Table 37-1. Common registry types used in zone files
Type |
Description |
---|---|
SOA |
Start of authority |
NS |
Authorized name server |
A |
Host address |
CNAME |
Canonical name |
MX |
Mail server exchange |
PTR |
Reverse name pointer |
Forwarding is very useful in many situations. It simply forwards all DNS queries or just specific zones to other DNS servers, caching the results and speeding up future name resolutions.
It's possible to create DNS forwarding using the forwarders
parameter at a global level or per-zone basis in a zone section of the named.conf file.
The following example forwards all queries to two other nameservers (10.163.200.103 and 10.163.200.104):
options { directory "/var/named"; forwarders {10.163.200.103; 10.163.200.104;}; };
A server can also be used as a forward-only DNS server that forwards all name server work. Just add the forward only
parameter to the file:
options { directory "/var/named"; forwarders {10.163.200.103; 10.163.200.104;}; forward only; };
The following example shows a zone-specific forwarding parameter:
zone "example.com" IN { type forward; forwarders {10.163.200.103; 10.163.200.104;}; };
This way, all nameserver queries from example.com will be handled by another DNS server.
Reverse DNS files
are used to resolve IP addresses to their assigned hostnames. Reverse DNS is set up per subnet, meaning all 192.168.0.n
addresses would have a single reverse DNS file defined, as would 192.168.1.n
, 192.168.2.n
, and so on (where n
is equal to all nodes from 0 through 255).
Reverse DNS files are named by the subnet address (in reverse order) followed by the in-addr.arpa filename. For instance, the reverse DNS file for the 192.168.100.n
subnet would be db.100.168.192.in-addr.arpa, and the reverse DNS file for the 205.23.12.n
subnet would be db.12.23.205.in-addr.arpa.
Although the subnet and in-addr.arpa filenames are always used, many administrators replace the db. with rev., simply for clarification (for instance, rev.12.23.205.in-addr.arpa or 12.23.205.in-addr.arpa.rev). Regardless of which naming convention you use, simply keep the same naming convention throughout your environment, and make sure all appropriate references (such as in /etc/named.conf) match.
The following is an example of the reverse DNS file db.0.168.192.in-addr.arpa. You will notice that it looks similar to the forward DNS files, with the same SOA head entry, but uses different tokens in the body of the file.
@ IN SOA ns.example.com. root.example.com. ( 199080101 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ); minimum (1 day) IN NS ns.example.com. 1 IN PTR gateway.example.com. 2 IN PTR boss.example.com. 3 IN PTR node3.example.com. ;4 IN PTR node4.example.com. 212 IN PTR www.example.com. 254 IN PTR router.example.com.
In this example, the first six lines are identical to the forward DNS files. The first six lines of the file are the SOA entry information, which includes the host information, the file serial number, and various time settings. The remaining body of the example differs greatly from the forward DNS file, however. The remaining entries use the PTR (pointer) token. The PTR token resolves the specific node on a subnet to a domain name. The first column of PTR entries in the example specifies the node number on the subnet. For instance, 1 refers to 192.168.0.1, 2 refers to 192.168.0.2, and so forth. You'll notice that nodes that aren't assigned are either not listed, or the ones that are disabled are commented out. (For instance, the entry for 4 is commented out with the semicolon at the beginning of the line.) Therefore, the entry for 1 will resolve 192.168.0.1 to gateway.example.com, the entry for 212 will resolve 192.168.0.212 to www.example.com, and so forth.
A variety of DNS tools are available to help you utilize and test the DNS service. The ones you should know are listed in Table 37-2. DNS tools should be installed on every Linux workstation, not just DNS servers. Tools such as dig and nslookup are a great help even for regular users who want to look up an IP address or domain using a name server.
Table 37-2. DNS tools
Tool |
Simple usage |
Description |
---|---|---|
dig |
dig @
|
Queries |
dnsquery |
dnsquery -n
|
Queries domain |
host |
host domain |
Looks up the host for a domain name |
nslookup |
nslookup record
[
nslookup
|
Queries Internet name servers for IP address and domain information |
dig
dig [@nameserver] domain
dig is a powerful tool that can be used to retrieve detailed information from DNS name servers.
Specifies the name server to query.
Specifies the registry type that you are querying. If omitted, the default is a. Available types include:
Network address
Any (all) information about the specified domain
Mail exchanger for the domain
Name servers for the domain
Zone of authority record
Host information
Zone transfer
Arbitrary text
Specifies a reverse name resolution
Useful for name resolution troubleshooting
You can make simple name resolution tests using different types of records. This is how to query an SOA record:
#dig @nameserver.petro.org.br. petro.org.br. soa
;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52650 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 6 ;; QUESTION SECTION: ;petro.org.br. IN SOA ;; ANSWER SECTION: petro.org.br. 3600 IN SOA nameserver.petro.org.br. admin.petro.org.br. 177 900 600 86400 3600 ;; AUTHORITY SECTION: petro.org.br. 3600 IN NS nameserver.petro.org.br. petro.org.br. 3600 IN NS nameserver02.petro.org.br. ;; ADDITIONAL SECTION: 1 IN PTR gateway.petro.org.br. 2 IN PTR boss.petro.org.br. 3 IN PTR node3.petro.org.br. 212 IN PTR www.petro.org.br. 254 IN PTR router.petro.org.br. ;; Query time: 1 msec ;; SERVER: 164.85.216.64#53(nameserver) ;; WHEN: Tue Mar 21 19:27:48 2006 ;; MSG SIZE rcvd: 512 And how to look for the MX records: #dig petro.org.br mx
; <<>> DiG 9.2.2-P1 <<>> petro.org.br mx ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4842 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;petro.org.br.INMX ;; AUTHORITY SECTION: org.br.900INSOAa.dns.br. hostmaster.registro.br. 2006032712 1800 900 604800 900 ;; Query time: 152 msec ;; SERVER: 172.24.1.20#53(172.24.1.20) ;; WHEN: Mon Mar 27 15:55:42 2006 ;; MSG SIZE rcvd: 92