Troubleshooting BIND
One of the most common culprits of BIND problems is incorrectly located chroot files. If you have the BIND chroot package installed, make sure the configuration files are located in the chroot directory.
Here's a quick list of symptoms that indicate your files may not be located correctly.
The named daemon starts without loading any zone files. Here is a sample of the /var/log/messages file that shows that named doesn't load them:.
Nov 9 17:35:41 bigboy named[1157]: starting BIND 9.2.3 -u
named -t /var/named/chroot
Nov 9 17:35:41 bigboy named[1157]: using 1 CPU
Nov 9 17:35:41 bigboy named[1157]: loading configuration
from '/etc/named.conf'
Nov 9 17:35:41 bigboy named[1157]: listening on IPv4 inter-
face lo, 127.0.0.1#53
Nov 9 17:35:41 bigboy named[1157]: listening on IPv4 inter-
face eth0, 10.41.32.71#53
Nov 9 17:35:41 bigboy named[1157]: command channel listening
on 127.0.0.1#953
Nov 9 17:35:41 bigboy named[1157]: command channel listening
on ::1#953
Nov 9 17:35:41 bigboy named[1157]: running
Restarting named gives rndc "connect failed" messages:
[root@bigboy tmp]# service named restart
Stopping named: rndc: connect failed: connection refused
[ OK ]
Starting named: [ OK ]
[root@bigboy tmp]#
The chroot files are empty:
[root@bigboy tmp]# cat /var/named/chroot/etc/named.conf
[root@bigboy tmp]# cat /var/named/chroot/etc/rndc.key
[root@bigboy tmp]#
To correctly relocate the files:
1. | Copy the /etc/rndc.* and /etc/named.conf files to the /var/named/chroot/etc/ directory:
[root@bigboy tmp]# cp -f /etc/rndc.* /var/named/chroot/etc/
[root@bigboy tmp]# cp /etc/named.conf /var/named/chroot/etc/
| 2. | Restart named twice; it should shutdown correctly without error the second time.
[root@bigboy tmp]# service named restart
Stopping named: rndc: connect failed: connection refused
[ OK ]
Starting named: [ OK ]
[root@bigboy tmp]# service named restart
Stopping named: [ OK ]
Starting named: [ OK ]
[root@bigboy tmp]#
| 3. | Check your /var/log/messages file for the loading of the zone files:
Nov 9 17:36:34 bigboy named[1180]: zone 0.0.127.in-addr.arpa/IN:
loaded serial 1997022700
Nov 9 17:36:34 bigboy named[1180]: zone localhost/IN: loaded
serial 42
Nov 9 17:36:34 bigboy named[1180]: running
Nov 9 09:36:35 bigboy named: named startup succeeded
|
General Troubleshooting Steps
Once your files are in the right place, you can continue with the following troubleshooting steps:
1. | Determine whether your DNS server is accessible on DNS UDP/TCP port 53. Lack of connectivity could be caused by a firewall with incorrect permit, NAT, or port forwarding rules to your DNS server. Failure could also be caused by the named process being stopped. It is best to test this from both inside your network and from the Internet.
Troubleshooting with TELNET is covered in Chapter 4, "Simple Network Troubleshooting."
| 2. | Linux status messages are logged to the file /var/log/messages. Use it to make sure all your zone files are loaded when you start BIND/ named. Check your /etc/named.conf file if they fail to do so. (Linux logging is covered in Chapter 5, "Troubleshooting with syslog."
Feb 21 09:13:13 bigboy named: named startup succeeded
Feb 21 09:13:13 bigboy named[12026]: loading configuration from
'/etc/named.conf'
Feb 21 09:13:13 bigboy named[12026]: no IPv6 interfaces found
Feb 21 09:13:13 bigboy named[12026]: listening on IPv4 interface
lo, 127.0.0.1#53
Feb 21 09:13:13 bigboy named[12026]: listening on IPv4 interface
wlan0, 192.168.1.100#53
Feb 21 09:13:13 bigboy named[12026]: listening on IPv4 interface
eth0, 172.16.1.100#53
Feb 21 09:13:14 bigboy named[12026]: command channel listening on
127.0.0.1#953
Feb 21 09:13:14 bigboy named[12026]: zone 0.0.127.in-addr.arpa/IN:
loaded serial 1997022700
Feb 21 09:13:14 bigboy named[12026]: zone 1.16.172. in-
addr.arpa/IN: loaded serial 51
Feb 21 09:13:14 bigboy named[12026]: zone 1.168.192. in-
addr.arpa/IN: loaded serial 51
Feb 21 09:13:14 bigboy named[12026]: zone my-web-site.org/IN:
loaded serial 2004021401
Feb 21 09:13:14 bigboy named[12026]: zone localhost/IN: loaded
serial 42
Feb 21 09:13:14 bigboy named[12026]: zone my-web-site.org/IN:
loaded serial 200301114
Feb 21 09:13:14 bigboy named[12026]: running
| 3. | Use the host ( nslookup in Windows) command for both forward and reverse lookups to make sure the zone files were configured correctly.
If this fails, try:
Double check for your updated serial numbers in the modified files and also inspect the individual records within the files for mistakes. Ensure there isn't a firewall that could be blocking DNS traffic on TCP and/or UDP port 53 between your server and the DNS server. Use the dig command to determine whether the name server for your domain is configured correctly.
|
Here is an example of querying DNS server ns1.my-web-site.org for the IP address of www.linuxhomenetworking.com. (You can also replace the name server's name with its IP address.)
[root@bigboy tmp]# host www.linuxhomenetworking.com ns1.my-site.com
Using domain server:
Name: ns1.my-web-site.org
Address: 192.168.1.100#53
Aliases:
www.linuxhomenetworking.com has address 65.115.71.34
[root@bigboy tmp]#
Here is an example of querying your default DNS server for the IP address of www.linuxhomenetworking.com. As you can see, the name of the specific DNS server to query has been left off the end. Failure in this case could be due not only to an error on your BIND configuration or domain registration but also to an error in your DNS client's DNS server entry in your Linux /etc/resolv.conf file or the Windows TCP/IP properties for your NIC.
[root@bigboy tmp]# host www.linuxhomenetworking.com
www.linuxhomenetworking.com has address 65.115.71.34
[root@bigboy tmp]#
The format for the command is:
dig <domain-name> <name-server> soa
The name server is optional. If you specify a name server, then dig queries that name server instead of the Linux server's default name server. It is sometimes good to query both your name server, as well as a well-known name server such as ns1.yahoo.com to make sure your DNS records have propagated properly. The dig command only works with fully qualified domain names, because it doesn't refer to the /etc/resolv.conf file.
This command uses the local DNS server for the query. It returns the SOA record information and the addresses of the domain's DNS servers in the authority section.
[root@bigboy tmp]# dig linuxhomenetworking.com SOA
...
...
;; AUTHORITY SECTION:
linuxhomenetworking.com. 3600 IN NS ns1.my-isp-
provider.net.
linuxhomenetworking.com. 3600 IN NS ns2.my-isp-
provider.net.
;; ADDITIONAL SECTION:
ns1.my-isp-provider.net. 3600 IN A 65.115.70.68
ns2.my-isp-provider.net. 3600 IN A 65.115.70.69
...
...
[root@bigboy tmp]#
Here is a successful dig using DNS server ns1.yahoo.com for the query. As before, it returns the SOA record for the zone.
[root@bigboy tmp]# dig ns1.yahoo.com linuxhomenetworking.com SOA
...
...
;; AUTHORITY SECTION:
linuxhomenetworking.com. 3600 IN NS ns2.my-isp-provider.net.
linuxhomenetworking.com. 3600 IN NS ns1.my-isp-provider.net.
;; ADDITIONAL SECTION:
ns1.my-isp-provider.net. 3600 IN A 65.115.70.68
ns2.my-isp-provider.net. 3600 IN A 65.115.70.69
...
...[root@bigboy tmp]#
Sometimes your SOA dig will fail. This command uses the DNS server ns1.yahoo.com for the query. In this case the authority section doesn't know of the domain and points to the name server for the entire .com domain at VeriSign.
[root@bigboy tmp]# dig ns1.yahoo.com linuxhomeqnetworking.com SOA
...
...
;; QUESTION SECTION:
;linuxhomeqnetworking.com. IN SOA
;; AUTHORITY SECTION:
com. 0 IN SOA a.gtld-servers.net.
nstld.verisign-grs.com. 1077341254 1800 900 604800 900
...
...
[root@bigboy tmp]#
Possible causes of failure include:
Typographical errors. In this case the misspelling "linuxhomeqnetworking.com" was entered on the command line. Incorrect domain registration. Correct domain registration, but there is a lag in the propagation of the domain information across the Internet. Delays of up to four days are not uncommon. A firewall could be blocking DNS traffic on TCP and/or UDP port 53 between your server and the DNS server.
 | 