BIND Troubleshooting Tools

From Webmin Documentation
Jump to: navigation, search

There are a number of tools that are available to assist with testing and troubleshooting problems with your BIND configuration. The simplest tool on most systems is the host command, which simply performs an address lookup or a reverse address lookup. More complete information can be gathered using dig. On extremely old systems, nslookup might still be the only available option for this type of testing, but it is rather confusing and inconsistent in a number of ways and is not recommended.

Using host

The host utility provides a very easy to use command line interface for looking up a name or an address. In its simplest usage form it will return the IP address or addresses when given a host name as its argument. The mail host address or addresses will also be returned if available. If the command line argument is an IP address, a reverse lookup will be performed and the host name will be returned. host also has a few additional options that may be helpful in tracing DNS problems or testing your configuration for correctness. You may query your system default name server, or you can query any name server you need to test by appending a server address to the end of the command line.

The simplest usage of host is to lookup an address, or a name.

[joe@delilah joe]$ host swelltech.com
swelltech.com has address 216.40.244.74
[joe@delilah joe]$ host 216.40.244.74
74.244.40.216.in-addr.arpa domain name pointer swelltech.com.

Above, I've requested the address for the domain swelltech.com, and then the name for the address 216.40.244.74. I could also ask for the name servers that are authoritative for a domain by using the -t ns command line option..

[joe@delilah joe]$ host -t ns google.com
google.com name server ns2.google.com.
google.com name server ns3.google.com.
google.com name server ns4.google.com.
google.com name server ns1.google.com.

Finally, the MX record can be retrieved by using the -t mx option.

[joe@delilah joe]$ host -t mx yahoo.com yahoo.com mail is handled by 1 mx2.mail.yahoo.com. yahoo.com mail is handled by 5 mx4.mail.yahoo.com. yahoo.com mail is handled by 1 mx1.mail.yahoo.com.

In the above MX record example, yahoo.com has three mail servers defined. The MX record has an additional field to indicate the priority of the server relative to other servers, in this case mx1.mail.yahoo.com and mx2.mail.yahoo.com have a priority of 1 so they will be preferred over mx4.mail.yahoo.com, which will only be used in the event the other two servers are unavailable.

Note: Not all options of the host utility are discussed here. For more detailed coverage of all of the command line options consult the host man page, either via the Webmin man pages interface or from the command line.

The -v option enables verbose output, which is in a format compatible with BINDs own master file format, so it can be directly imported into a BIND configuration without additional parsing or modification. The -t option allows you to specify the query type to make of the name server. There are many query types, but common types that may be useful include cname which lists the canonical name entries for the host if available, and the ns type which lists the authoritative name servers for the host.

One of the more verbose options of host is the -a option which will list all available fields for the host, including all A records, CNAME records, NS records, etc. Using host with this option against your own name server is a good way to insure it is providing all of the information you expect.

Using dig

dig, or domain information groper, provides the ability to query any domain server for information about the domains it serves. It operates in both an interactive mode and a batch query mode. Using dig is much like using host, in that in its simplest mode you enter just the command and the name to lookup. However, dig is more verbose by default and presents a much wider array or information, though in a somewhat less readable form.

Just like host, it is possible to query your default system resolver, or you can query a name server specified on the command line. For example, I could query my local name server about the nostarch.com domain.

[joe@delilah joe]$ dig @192.168.1.1 nostarch.com
    
; <<>> DiG 9.2.1 <<>> @192.168.1.1 nostarch.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21448
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
        
;; QUESTION SECTION:
;nostarch.com.                  IN      A
       
;; ANSWER SECTION:
nostarch.com.           8585    IN      A       66.80.60.21
        
;; AUTHORITY SECTION:
nostarch.com.           8585    IN      NS      ns1.megapath.net.
nostarch.com.           8585    IN      NS      ns2.megapath.net.
       
;; ADDITIONAL SECTION:
ns1.megapath.net.       123591  IN      A       66.80.130.23
ns2.megapath.net.       123591  IN      A       66.80.131.5
        
;; Query time: 281 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Oct 26 19:42:45 2002
;; MSG SIZE  rcvd: 126

Above, we have a large amount of information, though not all of it is generally useful to us. First is the version of dig, and the command line options we specified. The comes some status information, including the NOERROR designator that indicates the name was retrieve without error. If the domain did not exist, or could not be queried, there would be an NXDOMAIN error or some other error. Next are the flags of the query. In this case, we have one query and one answer which are contained in the QUESTION and ANSWER sections below it. The next two items inform us of the number of AUTHORITY and ADDITIONAL sections that follow. In this case, the authority section gives us the primary and secondary name servers for this domain, ns1.megapath.com and ns2.megapath.com, and the additional section provides the IP addresses of those name servers.

The last few lines give the time the query required, the server that was queried and the port on which it was queried, the time and date on which the query was made, and the size of the message received from the name server.

Like host, dig has a mode in which you can query all of the information available about the domain. This can be done by appending the ANY argument to the end of the command line. Furthermore, the options NS, MX, CNAME, etc. are also available and do just what you would expect.

Using whois to confirm glue records

Name service cannot possibly work without accurate glue records at your registrar. These records provide the top-level domain name servers with the information they need to point clients to the right name server for any given second-level domain. If these records are incorrect, nothing that requires a name lookup will work for your domain.

To check the glue records, use the whois command:

$ whois virtualmin.com

This will produce a bunch of information about your zone, but the important part is the name servers section, which will include two records of the form:

Domain servers in listed order:
        NS0.VIRTUALMIN.COM      70.86.4.226
        NS1.VIRTUALMIN.COM      70.85.191.202

Other top-level domains, like .net and .org, or other country domains, may have slightly different wording or conventions for what information is provided, but there will always be a section for name servers. If these are incorrect, you'll need to update the information with your registrar.