A practical guide to Fedora and Red Hat Enterprise Linux, 7th Edition (2014)

Troubleshooting

When you start a DNS cache, the /var/log/messages file contains lines similar to the following:

# cat /var/log/messages
...
17:00:51 guava systemd[1]: Starting Berkeley Internet Name Domain (DNS)...
17:00:52 guava named-checkconf[2003]: zone localhost.localdomain/IN: loaded serial 0
17:00:52 guava named-checkconf[2003]: zone localhost/IN: loaded serial 0
17:00:52 guava named-checkconf[2003]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
17:00:52 guava named-checkconf[2003]: zone 0.in-addr.arpa/IN: loaded serial 0
17:00:52 guava named[2008]: starting BIND 9.9.3-rl.156.01-P1-RedHat-...P1.fc19 -u named
17:00:52 guava named[2008]: adjusted limit on open files from 4096 to 1048576
17:00:52 guava named[2008]: found 1 CPU, using 1 worker thread
17:00:52 guava named[2008]: using 1 UDP listener per interface
17:00:52 guava named[2008]: using up to 4096 sockets
17:00:52 guava named[2008]: loading configuration from '/etc/named.conf'
17:00:52 guava named[2008]: reading built-in trusted keys from '/etc/named.iscdlv.key'
17:00:52 guava named[2008]: using default UDP/IPv4 port range: [1024, 65535]
17:00:52 guava named[2008]: using default UDP/IPv6 port range: [1024, 65535]
17:00:52 guava named[2008]: listening on IPv4 interface lo, 127.0.0.1#53
17:00:52 guava named[2008]: listening on IPv6 interface lo, ::1#53
17:00:52 guava named[2008]: generating session key for dynamic DNS
17:00:52 guava named[2008]: sizing zone task pool based on 6 zones
17:00:52 guava named[2008]: using built-in DLV key for view _default
17:00:52 guava named[2008]: automatic empty zone: 125.100.IN-ADDR.ARPA
17:00:52 guava named[2008]: automatic empty zone: 126.100.IN-ADDR.ARPA
17:00:52 guava named[2008]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
17:00:52 guava named[2008]: automatic empty zone: D.F.IP6.ARPA
17:00:52 guava named[2008]: automatic empty zone: 8.E.F.IP6.ARPA
17:00:52 guava named[2008]: automatic empty zone: 9.E.F.IP6.ARPA
17:00:52 guava named[2008]: automatic empty zone: A.E.F.IP6.ARPA
17:00:52 guava named[2008]: automatic empty zone: B.E.F.IP6.ARPA
17:00:52 guava named[2008]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA
17:00:52 guava named[2008]: command channel listening on 127.0.0.1#953
17:00:52 guava named[2008]: command channel listening on ::1#953
17:00:52 guava named[2008]: managed-keys-zone: journal is out of date: removing journal
17:00:52 guava named[2008]: managed-keys-zone: loaded serial 3
17:00:52 guava named[2008]: zone 0.in-addr.arpa/IN: loaded serial 0
17:00:52 guava named[2008]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
17:00:52 guava named[2008]: zone localhost.localdomain/IN: loaded serial 0
17:00:52 guava named[2008]: zone localhost/IN: loaded serial 0
17:00:52 guava named[2008]: all zones loaded
17:00:52 guava systemd[1]: Started Berkeley Internet Name Domain (DNS).
17:00:52 guava named[2008]: running

When you create or update DNS information, you can use dig or host to test whether the server works as planned. The most useful part of the output from dig is usually the answer section, which gives the nameserver’s reply to your query:

$ dig example.com
...
;; ANSWER SECTION:
example.com. 172800 IN A 192.0.32.10
...

The preceding output shows that the example.com domain has a single A record that points to 192.0.32.10. The TTL of this record, which tells you how long the record can be held in cache, is 172,800 seconds (two days). You can also use dig to query other record types by using the –toption followed by the type of record you want to query for (–t works with host, too):

$ dig -t MX tldp.com
...
;; ANSWER SECTION:
tldp.com. 5 IN MX 0 mx1.sub5.homie.mail.dreamhost.com.
tldp.com. 5 IN MX 0 mx2.sub5.homie.mail.dreamhost.com.
...

If you query for a domain that does not exist, dig returns the SOA record for the authority section of the highest-level domain in your query that does exist:

$ dig domaindoesnotexist.info
...
;; AUTHORITY SECTION:
info. 900 IN SOA a0.info.afilias-nst.info. noc.afilias-nst.info. ...
...

Because it tells you the last zone that was queried correctly, this information can be useful in tracing faults.

TSIGs

If two servers using TSIGs (page 881) fail to communicate, confirm the system clock is set to the same time on both servers. The TSIG authentication mechanism is dependent on the current time. If the clocks on the two servers are not synchronized, TSIG will fail. Consider setting up NTP(page 1264) on the servers to prevent this problem.

Setting Up Different Types of DNS Servers

This section describes how to set up a full-functioned nameserver, a slave server, and a split-horizon server.

A Full-Functioned Nameserver

Because the IP addresses used in this example are part of the private address space (page 1267), you can copy the example and run the server without affecting global DNS. Also, to prevent contamination of the global DNS, each zone has the notify option set to NO. When you build a nameserver that is integrated with the Internet, you will want to use IP addresses that are unique to your installation. You might want to change the settings of the notify statements.

named.conf

The named.conf file in this example limits the IP addresses that named answers queries from and sets up logging.

$ cat /etc/named.conf
options {
directory "/var/named";
allow-query {127.0.0.1; 192.168.0.0/24;};};

zone "." IN {
type hint;
file "named.ca";};

zone "0.168.192.in-addr.arpa" IN {
type master;
file "named.local";
notify NO;
};

zone "sam.net" IN {
type master;
file "sam.net";
notify NO;
};

logging{
channel "misc" {
file "/var/log/bind/misc.log" versions 4 size 4m;
print-time YES;
print-severity YES;
print-category YES;
};
channel "query" {
file "/var/log/bind/query.log" versions 4 size 4m;
print-time YES;
print-severity NO;
print-category NO;
};
category default {
"misc";
};
category queries {
"query";
};
};

The allow-query statement in the Options clause specifies the IP addresses of systems the server answers queries from. You must include the local system as 127.0.0.1 if it will be querying the server. The server is authoritative for the zone sam.net; the zone file for sam.net is/var/named/sam.net.

Logging

Logging is turned on by the Logging clause. Logging is separate from named messages, which go to syslogd. The Logging clause in the preceding example opens two logging channels: one that logs information to /var/log/bind/misc.log and one that logs information to/var/log/bind/query.log. When either of these logs grows to 4 megabytes (size 4m in the file statement), it is renamed by appending .1 to its filename and a new log is started. The numbers at the ends of other, similarly named logs are incremented. Any log that would have a larger number than that specified by the versions keyword (4 in the example) is removed. See logrotate (page 618) for another way to maintain log files.

The print statements determine whether the time, severity, and category of the information are sent to the log; specify each as YES or NO. The category determines what information is logged to the channel. In the previous example, default information is sent to the misc channel and queries are sent to the query channel. Refer to the named.conf man page for more choices.

named.local

The origin for the reverse zone file (named.local) is 0.168.192.in-addr.arpa (as specified in the Zone clause that refers to this file in named.). Following the SOA and NS resource records, the first three PTR resource records equate address 1 in the subnet 0.168.192.in-addr.arpa (192.168.0.1) with the names gw.sam.net., www.sam.net., and ftp.sam.net., respectively. The next three PTR records equate 192.168.0.3 with mark.sam.net., 192.168.0.4 with mail.sam.net., and 192.168.0.6 with ns.sam.net..

$ cat named.local
; zone "0.168.192.in-addr.arpa"
;
$TTL 3D
@ IN SOA ns.sam.net. mgs@sobell.com. (
2005110501 ; serial
8H ; refresh
2H ; retry
4W ; expire
1D) ; minimum
IN NS ns.sam.net.
1 IN PTR gw.sam.net.
3 IN PTR mark.sam.net.
4 IN PTR mail.sam.net.
6 IN PTR ns.sam.net.

sam.net

The zone file for sam.net takes advantage of many BIND features and includes TXT (page 860), CNAME (page 858), and MX (page 859) resource records. When you query for resource records, named returns the TXT resource record along with the records you requested. The first of the two NS records specifies an unqualified name (ns) to which BIND appends the zone name (sam.net), yielding an FQDN of ns.sam.net. The second nameserver is specified with an FQDN name that BIND does not alter. The MX records specify mail servers in a similar manner and include a priority number at the start of the Data field, where lower numbers indicate preferred servers.

$ cat sam.net
; zone "sam.net"
;
$TTL 3D
@ IN SOA ns.sam.net. mgs@sobell.com. (
2013110501 ; serial
8H ; refresh
2H ; retry
4W ; expire
1D ) ; minimum

TXT "Sobell Associates Inc."
NS ns ; Nameserver address (unqualified)
NS ns.max.net.; Nameserver address (qualified)
MX 10 mail ; Mail exchange (primary/unqualified)
MX 20 mail.max.net.; Mail exchange (2nd/qualified)

localhost IN A 127.0.0.1

www IN CNAME ns
ftp IN CNAME ns

gw IN A 192.168.0.1
TXT "Router"

ns IN A 192.168.0.6
MX 10 mail
MX 20 mail.max.net.

mark IN A 192.168.0.3
MX 10 mail
MX 20 mail.max.net.
TXT "MGS"

mail IN A 192.168.0.4
MX 10 mail
MX 20 mail.max.net.

Some resource records have a value in the Name field; those without a name inherit the name from the previous resource record. In a similar manner, the previous resource record might have an inherited name value, and so on. The five resource records following the SOA resource record inherit the @, or zone name, from the SOA resource record. These resource records pertain to the zone as a whole. In the preceding example, the first TXT resource record inherits its name from the SOA resource record; it is the TXT resource record for the sam.net zone (give the commandhost –t TXT sam.net to display the TXT resource record).

Following these five resource records are resource records that pertain to a domain within the zone. For example, the MX resource records that follow the A resource record with the Name field set to mark are resource records for the mark.sam.net. domain.

The A resource record for localhost is followed by two CNAME resource records that specify www(.sam.net.) and ftp(.sam.net.) as aliases for the nameserver ns.sam.net.. For example, a user connecting to ftp.sam.net will connect to 192.168.0.6. The resource records named gw, ns, mark, and mail are resource records for domains within the sam.net zone.

Log files

Before restarting named, create the directory for the log files and give it permissions and ownership as shown below. If you are running named in a chroot jail, create the bind directory in /var/named/chroot/var/log.

# mkdir /var/log/bind
# chmod 744 /var/log/bind
# chown named /var/log/bind
# ls -ld /var/log/bind
drwxr--r--. 2 named root 4096 10-19 14:43 /var/log/bind

With the log directory in place, named.conf in /etc (or in /var/named/chroot/etc if you are running named in a chroot jail), named.ca, named.local, and sam.net zone files in /var/named (or in /var/named/chroot/var/named if you are running named in a chroot jail), restart named and check the log files. The file /var/log/messages should show something like the following:

# cat /var/log/messages
...
15:11:40 guava named[9824]: starting BIND 9.9.3-rl.156.01-P1-RedHat-...P1.fc19 -u named
...
15:11:40 guava named[9824]: loading configuration from '/etc/named.conf'
15:11:40 guava named[9824]: using default UDP/IPv4 port range: [1024, 65535]
15:11:40 guava named[9824]: using default UDP/IPv6 port range: [1024, 65535]
15:11:40 guava named[9824]: listening on IPv4 interface lo, 127.0.0.1#53
...
15:11:40 guava named[9824]: command channel listening on 127.0.0.1#953
15:11:40 guava named[9824]: command channel listening on ::1#953
15:11:40 guava named[9824]: the working directory is not writable

You can safely ignore the working directory is not writable error message. The misc.log file might show errors that do not appear in the messages file:

# cat /var/log/bind/misc.log
15:11:40.594 general: info: zone 0.168.192.in-addr.arpa/IN: loaded serial 2013110501
15:11:40.596 general: info: zone sam.net/IN: loaded serial 2013110501
15:11:40.596 general: info: managed-keys-zone ./IN: loaded serial 0
15:11:40.600 general: notice: running

See “Error messages” on page 865 if named generates an error message.

A Slave Server

To set up a slave server, copy the /etc/named.conf file from the master server to the slave server, replacing the type master statement with type slave and adding a masters { 1.2.3.4; }; directive. Remove any zones the slave server will not be acting as a slave for, including the root (.) zone, if the slave server will not respond to recursive queries. If necessary, create the /var/log/bind directory for log files as explained at the end of the previous section.

notify statement

Slave servers copy zone information from the primary master server or another slave server. The notify statement specifies whether you want a master server to notify slave servers when information on the master server changes. Set the (global) value of notify in the Options clause or set it within a Zone clause, which overrides a global setting for a given zone. The format is

notify YES | NO | EXPLICIT

YES causes the master server to notify all slaves listed in NS resource records for the zone as well as servers at IP addresses listed in an also-notify statement. When you set notify to EXPLICIT, the server notifies servers listed in the also-notify statement only. NO turns off notification.

When you start named, it copies the zone files to /var/named. If you specify notify YES on the master server, the zone files on the slave server will be updated each time you change the serial field of the SOA resource record in a zone. You must manually distribute changes to/etc/named.conf and included files.

A Split Horizon (DMZ) Server

Assume you want to set up a LAN that provides all of its systems and services to local users on internal systems, which might be behind a firewall, but only certain public services—such as Web, FTP, and mail—to Internet (public) users. A split horizon (also called DMZ) DNS server takes care of this situation by treating queries from internal systems differently from queries from public systems (systems on the Internet).

View clauses

BIND 9 introduced View clauses in named.conf. View clauses facilitate the implementation of a split DNS server. Each view provides a different perspective of the DNS namespace to a group of clients. When there is no View clause, all zones specified in named.conf are part of the implicit default view.

Assume an office has several systems on a LAN and public Web, FTP, DNS, and mail servers. The single connection to the Internet is NATed (page 1262), so it is shared by the local systems and the servers. The system connected directly to the Internet is a router, firewall, and server. This scenario takes advantage of the View clauses in named.conf and supports separate secondary nameservers for local and public users. Although public users need access to the DNS server as the authority on the domain that supports the servers, they do not require the DNS server to support recursive queries. Not supporting recursion for public users limits the load on the DNS server and the Internet connection. For security reasons, public users must not have access to information about local systems other than the servers. Local users should have access to information about local systems and should be able to use the DNS server recursively.

Figure 24-11 shows that the server responds differently to queries from the LAN and from the Internet.

Figure 24-11 A split horizon DNS server

The firewall-config (page 900) or firewall-cmd utility (page 906) controls which ports on which systems users on internal and external systems can access. DNS controls which systems are advertised to which users.

The named.conf file has four clauses: an Options clause, two View clauses, and a Logging clause. The Options clause specifies that the zone files be located in the /var/named directory. The View clauses specify the characteristics and zones that a resolver is given access to, which depend on the resolver’s address. One zone is for use by the LAN/local users; the other is used by Internet/public users. The Logging clause sets up the misc2.log file for default messages; you must create a /var/log/bind directory as explained under “Log files” (page 889).

There are several ways to specify which clients see a view. The following named.conf file uses match-clients statements:

$ cat /etc/named.conf
options {
directory "/var/named";
}; //end options


view "local" IN { // start local view
match-clients { 127.0.0.1; 192.168.0.0/24;};
recursion YES;


zone"zach.net" IN {
type master;
file "local.net";
notify YES;
};

zone "0.168.192.in-addr.arpa" IN {
type master;
file "named.local";
notify YES;
};

zone "." IN {
type hint;
file "named.ca";
};

}; // end local view

view "public" IN { // start public view
match-clients { "any";};
recursion NO;

zone"zach.net" IN {
type master;
file "public.net";
notify YES;
};

zone "0.168.192.in-addr.arpa" IN {
type master;
file "named.public";
notify YES;
};

zone "." IN {
type hint;
file "named.ca";
};

}; // end public view

logging{
channel "misc" {
file "/var/log/bind/misc2.log" versions 2 size 1m;
print-time YES;
print-severity YES;
print-category YES;
};
category default {
"misc";
};
}; //end logging

The ordering of View clauses within named.conf is critical because the view that is presented to a client is the first view that the client matches. The preceding named.conf file holds two View clauses: one for local users and one for public users, in that order. Local users are defined to be those on the 192.168.0.0/24 subnet or localhost (127.0.0.1); public users are defined to be any users. If you reversed the order of the View clauses, all users—including local users—would get the view intended for the public and no users would see the local view.

Many statements from the Options clause can be used within View clauses, where they override statements in the (global) Options clause. The recursion statement, which can appear within an Options clause, appears in each View clause. This named.conf file sets up a server that provides recursive answers to queries that originate locally and iterative answers to queries from the public. This setup provides quick, complete answers to local users, limiting the network and processor bandwidth that is devoted to other users while continuing to provide authoritative name service for the local servers.

To make named.conf easier to understand and maintain, zones in different View clauses can have the same name but different zone files. Both the local and public View clauses in the example have zones named zach.net: The public zach.net zone file is named public.net and the local one is named local.net.

The Logging clause is described on page 887.

The zone files defining zach.net are similar to the ones in the previous examples; the public file is a subset of the local one. Following the SOA resource record in both files is a TXT, two NS, and two MX resource records. Next are three CNAME resource records that direct queries addressed to www.zach.net, ftp.zach.net, and mail.zach.net to the system named ns.zach.net. The next four resource records specify two nameserver addresses and two mail servers for the ns.zach.net domain.

The final four resource records appear in the local zach.net zone file and not in the public zone file; they are address (A) resource records for local systems. Instead of keeping this information in /etc/hosts files on each system, you can keep it on the DNS server, where it can be updated easily. When you use DNS instead of /etc/hosts, you must change the hosts line in /etc/nsswitch.conf (page 495) accordingly.

$ cat local.net
; zach.net local zone file
;
$TTL 3D
@ IN SOA ns.zach.net. mgs@sobell.com. (
201311118 ; serial
8H ; refresh
2H ; retry
4W ; expire
1D ) ; minimum

IN TXT “Sobell Associates Inc.”
IN NS ns ; Nameserver address (unqualified)
IN NS ns.speedy.net.; Nameserver address (qualified)
IN MX 10 mail ; Mail exchange (primary/unqualified)
IN MX 20 mail.max.net.; Mail exchange (2nd/qualified)
ns IN A 192.168.0.1
mail IN A 192.168.0.2

www IN CNAME mail
ftp IN CNAME mail
gw IN CNAME ns

speedy IN A 192.168.0.5
grape IN A 192.168.0.3
potato IN A 192.168.0.4
peach IN A 192.168.0.6

The public version of the zach.net zone file follows:

$ cat public.net
; zach.net public zone file
;
$TTL 3D
@ IN SOA ns.zach.net. mgs@sobell.com. (
201311118 ; serial
8H ; refresh
2H ; retry
4W ; expire
1D ) ; minimum

IN TXT “Sobell Associates Inc.”
IN NS ns ; Nameserver address (unqualified)
IN NS ns.speedy.net.; Nameserver address (qualified)

IN MX 10 mail; Mail exchange (primary/unqualified)
IN MX 20 mail.max.net. ; Mail exchange (2nd/qualified)

www IN CNAME mail
ftp IN CNAME mail
gw IN CNAME ns

ns IN A 192.168.0.1
mail IN A 192.168.0.2

Here there are two reverse zone files, each of which starts with SOA and NS resource records, followed by PTR resource records for each of the names of the servers. The local version of this file also lists the names of the local systems:

$ cat named.local
;"0.168.192.in-addr.arpa" reverse zone file
;
$TTL 3D
@ IN SOA ns.zach.net. mgs@sobell.com. (
2013110501 ; serial
8H ; refresh
2H ; retry
4W ; expire
1D) ; minimum
IN NS ns.zach.net.
IN NS ns.speedy.net.
1 IN PTR ns.zach.net.
2 IN PTR mail.zach.net.
3 IN PTR grape.zach.net.
4 IN PTR potato.zach.net.
5 IN PTR speedy.zach.net.
6 IN PTR peach.zach.net.

$ cat named.public
;"0.168.192.in-addr.arpa" reverse zone file
;
$TTL 3D
@ IN SOA ns.zach.net. mgs@sobell.com. (
2013110501 ; serial
8H ; refresh
2H ; retry
4W ; expire
1D) ; minimum
IN NS ns.zach.net.
IN NS ns.speedy.net.
1 IN PTR ns.zach.net.
2 IN PTR mail.zach.net.

Chapter Summary

DNS maps domain names to IP addresses, and vice versa. It is implemented as a hierarchical, distributed, and replicated database on the Internet. You can improve the security of BIND, which implements DNS, by running it inside a chroot jail and using transaction signatures (TSIGs) and SELinux.

When a program on the local system needs to look up an IP address that corresponds to a domain name, it calls the resolver. The resolver queries the local DNS cache, if available, and then queries DNS servers on the LAN or Internet. There are two types of queries: iterative and recursive. When a server responds to an iterative query, it returns whatever information it has at hand; it does not query other servers. Recursive queries cause a server to query other servers if necessary to respond with an answer.

There are three types of servers. Master servers, which hold the master copy of zone data, are authoritative for a zone. Slave servers are also authoritative and copy their data from a master server or other slave servers. DNS caches are not authoritative and either answer queries from cache or forward queries to another server.

The DNS database holds resource records for domains. Many types of resource records exist, including A (address), MX (mail exchange), NS (nameserver), PTR (pointer for performing reverse name resolution), and SOA (start of authority, which describes the zone).

Exercises

1. What kind of server responds to recursive queries? How does this server work?

2. What kind of DNS record is likely to be returned when a Web browser tries to resolve the domain part of a URI?

3. What are MX resource records for?

4. How would you find the IP address of example.com from the command line?

5. How would you instruct a Linux system to use the local network’s DNS cache, located at 192.168.1.254, or the ISP’s DNS cache, located at 1.2.3.4, if the LAN nameserver is unavailable?

6. How would you instruct a DNS server to respond only to queries from the 137.44.* IP range?

7. How might a resolver attempt to find the IP address of the example domain?

Advanced Exercises

8. How would you set up a private domain name hierarchy that does not include any of the official InterNIC-assigned domain names?

9. Which part of DNS is most vulnerable to an attack from a malicious user and why?

10. It is often irritating to have to wait for DNS records to update around the world when you change DNS entries. You could prevent this delay by setting the TTL to a small number. Why is setting the TTL to a small number a bad idea?

11. Outline a method by which DNS could be used to support encryption.