Linux Ocean

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 is 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 doesnot 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 interface

lo, 127.0.0.1#53

Nov 9 17:35:41 bigboy named[1157]: listening on IPv4 interface

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

294 Configuring DNS Chapter 18

20Harrison_ch18.qxd 2/25/05 10:09 AM Page 294

[ 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

Troubleshooting with syslog.

Feb 21 09:13:13 bigboy named: named startup succeeded

Feb 21 09:13:13 bigboy named[12026]: loading configuration from

vi 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.inaddr.

arpa/IN: loaded serial 51

Feb 21 09:13:14 bigboy named[12026]: zone 1.168.192.inaddr.

arpa/IN: loaded serial 51

Troubleshooting BIND 295

20Harrison_ch18.qxd 2/25/05 10:09 AM Page 295

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]#

? You can also use the dig command to determine whether known DNS

servers on the Internet have received a valid update for your zone.

(Remember if you decide to change the DNS servers for your domain that

it could take up to four days for it to propagate across the Internet.)

296 Configuring DNS Chapter 18

20Harrison_ch18.qxd 2/25/05 10:09 AM Page 296

The format for the command is:

dig 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-ispprovider.

net.

linuxhomenetworking.com. 3600 IN NS ns2.my-ispprovider.

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.

Troubleshooting BIND 297

20Harrison_ch18.qxd 2/25/05 10:09 AM Page 297

[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.