Using dig with external nameservers

This article explains how to use the open source tool "dig" to query records on an external DNS server. The previous article in this series, Verifying DNS configurations, covered manually checking new DNS configurations on Slicehost's DNS servers.


Bigger picture

In the previous article we discussed double-checking DNS configuration changes. Dig can also help us understand how our DNS records look from the perspective of other machines on the Internet.

The dig tests we have performed so far contain the option "@dns1.stabletransit.com". This option instructs dig to query Slicehost's primary DNS server. With that option we are testing the records on Slicehost's DNS server rather than any DNS records for the domain that might be cached on other Internet DNS servers. That means what we've done so far demonstrates techniques for testing DNS set up for Slicehost slices before you go live or before you transfer DNS from a previous hosting provider to Slicehost.

Once you are happy with the results from the previous tests, it should be safe to change the authoritative DNS servers for your domain to Slicehost's DNS servers:

dns1.stabletransit.com
dns2.stabletransit.com

You can set the authoritative DNS servers through your domain's registrar via their preferred method (with their own web-based tool or by contacting them directly). After the changes have been submitted to the registrar the new values propagate across the Internet. In a (hopefully) short time the DNS records on other DNS servers will match those you configured with Slicehost's DNS tool.

Testing authoritative nameservers

We can check the authoritative DNS servers for a domain by entering something like:

dig @8.8.8.8 +short NS domain.com

This is similar to the command we issued when we were testing for a correct NS configuration earlier. The critical difference is that instead of using Slicehost's primary nameserver for our test we are pointing dig to a public DNS server run by Google - "8.8.8.8". We want to make sure we get our test results from an external server, and 8.8.8.8 is one of a few DNS servers that have been made available to the public for this purpose.

The result of our test should be:

dns2.stabletransit.com.
dns1.stabletransit.com.

If the external DNS server we're querying returns those results, then we know that our change has propagated properly. If you see something different, such as the authoritative DNS servers of your previous hosting company, then either the domain has not been transferred properly or the change is taking a while to propagate to the rest of the Internet. The reasons for delay vary, but a wait of several hours before a change completely works its way through the rest of the Internet is not unusual.

If the results of the authoritative nameserver check are unfamiliar, you might be able to glean more information about the nameserver in question by issuing the dig command without the "+short" flag.

Variants for testing authoritative nameservers

There are some variants of this test. They can give you different answers, but only if you have an unusually intricate DNS set-up.

You can issue the command:

dig @8.8.8.8 +nssearch domain.com

This is very similar to:

dig @8.8.8.8 +short SOA domain.com | cut -d' ' -f1

These two commands give you more data about the domain's refresh settings (for DNS cache management) while revealing whose DNS servers are the authorities for the domain. They can be useful for troubleshooting.

The second command queries the "SOA" for the domain's zone file. SOA stands for "Start of Authority", and this record stores the domain's authoritative nameservers and the defined minimum time-to-live (TTL) on other servers. Depending on a DNS server's configuration the SOA may contain additional information, like a domain administrator's email address.

Causes of DNS problems

It is possible to omit the destination DNS server (the "@8.8.8.8" part) when issuing a dig command. With no server specified, dig will query the DNS server configured on the system where you are running the command. On a slice, that will be whatever was set up in the default configuration for the image the slice was built from. On your home computer, you would most likely query your ISP's DNS servers. It helps to be aware of which DNS server is being queried when troubleshooting a DNS issue in case the problem is related to DNS caching.

If you find your default DNS server returns a different IP address from the one you configured with Slicehost's DNS tool, this is almost always for one of two reasons.

The first possibility is that your registrar has not yet made the authoritative DNS server change or expects you to make the change using the registrar's tools.

The second possibility is the infamous "DNS propagation delay", in which some stragglers — most often mail servers — catch up on the change over a week or so.

Some advanced techniques can be employed to reduce propagation delay but they are beyond the scope of this article.

Which DNS server is responding to my queries?

We can see which DNS server is resolving the client's requests by issuing the "dig" command with no arguments. The client's default DNS server is listed on the "SERVER" line close to the end of the output.

dig

; <<>> DiG 9.5.1-P2 <<>>
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20196
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       366821  IN      NS      H.ROOT-SERVERS.NET.
.                       366821  IN      NS      I.ROOT-SERVERS.NET.
.                       366821  IN      NS      J.ROOT-SERVERS.NET.
.                       366821  IN      NS      K.ROOT-SERVERS.NET.
.                       366821  IN      NS      L.ROOT-SERVERS.NET.
.                       366821  IN      NS      M.ROOT-SERVERS.NET.
.                       366821  IN      NS      A.ROOT-SERVERS.NET.
.                       366821  IN      NS      B.ROOT-SERVERS.NET.
.                       366821  IN      NS      C.ROOT-SERVERS.NET.
.                       366821  IN      NS      D.ROOT-SERVERS.NET.
.                       366821  IN      NS      E.ROOT-SERVERS.NET.
.                       366821  IN      NS      F.ROOT-SERVERS.NET.
.                       366821  IN      NS      G.ROOT-SERVERS.NET.

;; Query time: 4 msec
;; SERVER: 192.168.1.79#53(192.168.1.79)
;; WHEN: Wed Oct  7 13:45:30 2009
;; MSG SIZE  rcvd: 228

Summary

In this article we discussed how to check the authoritative nameservers for a domain. We've also seen how we can verify record propagation by querying external DNS servers.

In the final article in this series we will take a closer look at the results when we omit the +short option (like we did in that last example), and answer some common questions about using dig.

Article Comments:

sysadmin commented Tue Oct 02 15:00:32 UTC 2012:

I'd like to mention the very useful "+trace" option of dig. It shows the full chain of resolving process starting from the root servers, including intermediate ones for your domain's TLD and finishing with the authoritative name servers actually holding the zone.

Want to comment?


(not made public)

(optional)

(use plain text or Markdown syntax)