When working with DNS, it can be a painful experience. From the time it takes for the root servers to update with your new records to simple mistakes made when working with large zone files. Here I explain six tools which can help route out DNS problems using the terminal. All of these work out of the box on OSX.
nslookup is used to pull up the basic information associated with a domain. Using nslookup is as simple as providing the following arguments:
$ nslookup nickcharlton.org.uk
A likely response could be similar to the following:
Server: 22.214.171.124 Address: 126.96.36.199#53 Non-authoritative answer: Name: nickcharlton.org.uk Address: 188.8.131.52
This response tells you the nameserver which was queried, in this case one of those of OpenDNS which I use at home and the response from the name server when it was queried. The last IP is that of my server.
Dig is a most useful tool, it officially stands for Domain Information Gopher and allows you to pull the data from the name server just as your machine would in taking a request. This allows you to pull the public records for the domain.
$ dig nickcharlton.org.uk
<<>> DiG 9.4.2-P2 <<>> nickcharlton.org.uk ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4635 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;nickcharlton.org.uk. IN A ;; ANSWER SECTION: nickcharlton.org.uk. 603718 IN A 184.108.40.206 ;; Query time: 19 msec ;; SERVER: 220.127.116.11#53(18.104.22.168) ;; WHEN: Sat Feb 21 03:49:25 2009 ;; MSG SIZE rcvd: 53
What can be taken from here is the A record for the domain. That is the record which takes a domain and points it to the IP of the remote machine.
dig (with @IP/Domain)
Whilst not strictly a tool within it’s own right, it is different from it’s basic no arguments call. This allows you to pull records from a specific server, which is useful for testing the records from a new server before it is live. An example is provided below, and would be used if pulling records from a local server:
$ dig @localhost nickcharlton.org.uk
And it’s response:
; <<>> DiG 9.4.2-P2 <<>> @kubrick.nickcharlton.org.uk nickcharlton.org.uk ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63435 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;nickcharlton.org.uk. IN A ;; ANSWER SECTION: nickcharlton.org.uk. 604800 IN A 22.214.171.124 ;; AUTHORITY SECTION: nickcharlton.org.uk. 604800 IN NS ns1.nickcharlton.org.uk. nickcharlton.org.uk. 604800 IN NS ns2.nickcharlton.org.uk. ;; ADDITIONAL SECTION: ns1.nickcharlton.org.uk. 10800 IN A 126.96.36.199 ns2.nickcharlton.org.uk. 10800 IN A 188.8.131.52 ;; Query time: 27 msec ;; SERVER: 184.108.40.206#53(220.127.116.11) ;; WHEN: Sat Feb 21 03:50:44 2009 ;; MSG SIZE rcvd: 121
Note the increase in the details of the records. I’m not entirely sure why this happens, so if you could enlighten me, please do. (Also note that the appropriate call I used was towards my server directly, and not local host, as I don’t have a DNS server here.)
This tool allows you to deal with your current DNS settings. The most commonly use argument of this is “reload” and that allows you to flush, or reload your DNS settings so that they are all fresh.
$ rndc reload
Host translates IP’s from domains and vice versa. This is what happens when you query a domain, you get an IP response. It can also be used backwards.
$ host nickcharlton.org.uk
nickcharlton.org.uk has address 18.104.22.168 nickcharlton.org.uk mail is handled by 20 fb.mail.gandi.net. nickcharlton.org.uk mail is handled by 10 spool.mail.gandi.net.
Last there is whois. This is obviously the most well known of the lot and provides ownership information for the domain. I will not provide an example here, as it will be very long, but this is simply used as below:
$ whois nickcharlton.org.uk