Network Troubleshooting Steps

Once configuration troubleshooting this is completed, 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 Linux 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 simiya.com/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 simiya.com/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-site.com 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-site.com
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]#

4) 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.)

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 only, 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.myisp.net.
linuxhomenetworking.com. 3600   IN      NS      ns2.myisp.net.

;; ADDITIONAL SECTION:
ns1.myisp.net.      3600    IN      A       65.115.70.68
ns2.myisp.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.myisp.net.
linuxhomenetworking.com. 3600   IN      NS      ns1.myisp.net.

;; ADDITIONAL SECTION:
ns1.myisp.net.      3600    IN      A       65.115.70.68
ns2.myisp.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.