bitplumber.net

Troubleshooting DNS can sometimes seem like black magic, but once you understand some of the fundamentals, and learn to use a good tool (such as DIG), it becomes much easier.

Let’s say you just made a DNS change for www.bitplumber.net to move the server from one IP to another, but you now find that requests are still going to the old IP.  You pull out your trusty friend “dig” and take a look.

C:\Users\eric.rosenberry>dig www.bitplumber.net

; <<>> DiG 9.6.0-P1 <<>> www.bitplumber.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1318
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.bitplumber.net.            IN      A

;; ANSWER SECTION:
www.bitplumber.net.     10651   IN      A       67.136.229.212

;; Query time: 27 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sun Mar 15 00:15:25 2009
;; MSG SIZE  rcvd: 52
C:\Users\eric.rosenberry>

You can see here that by simply running “dig www.bitplumber.net” it went out to your default DNS server (in my case the crummy consumer grade nat/switch/access point my Verizon FiOS came with) which is running on 192.168.1.1.  It did a standard lookup, which looks for “CNAME” or “A” records.  In my case it determined that there was an A record pointing at 67.136.229.212.

Note that “10651″ number in between www.bitplumber.net and the IP address.  That is the amount of time in seconds that this record is valid for.  The fact that it is not some convenient round number is a good indication to me that this DNS server is not “authoritative” for the domain and is just serving out a cached entry (that it recursively found during some previous query).  If you run the same command a few seconds later the number should decrement to 10648 as the server is always tracking how long it’s cached entries remain valid for.

Since 67.136.229.212 is the old IP address for www.bitplumber.net we need to go take a look at what the “authoritative” DNS servers for the domain are serving out to make sure the correct IP will be provided to users once the old IP times out of caches.  To do this we are going to tell dig which server we want it to ask the question of.  Since I own the domain I know the authoritative servers are ns1.dreamhost.com, ns2.dreamhost.com, and nd3.dreamhost.com.  I run dig with the @ns1.dreamhost.com parameter to get it to query nd1.dreamhost.com instead of 192.168.1.1.

C:\Users\eric.rosenberry>dig www.bitplumber.net @ns1.dreamhost.com

; <<>> DiG 9.6.0-P1 <<>> www.bitplumber.net@ns1.dreamhost.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 643
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.bitplumber.net.            IN      A

;; ANSWER SECTION:
www.bitplumber.net.     14400   IN      A       75.119.216.176

;; Query time: 48 msec
;; SERVER: 66.33.206.206#53(66.33.206.206)
;; WHEN: Sun Mar 15 00:34:46 2009
;; MSG SIZE  rcvd: 52
C:\Users\eric.rosenberry>

Note that you do have to be careful specifying a DNS server by name rather than IP as you could get unexpected results if the name does not resolve to the server you intended.

You can see that ns1.dreamhost.com is serving out 75.119.216.176 as the IP for www.bitplumber.net and that each time you query it, the answer always comes back with a validity period of 14400 seconds.  To ensure my DNS change propagated to all three servers I will run the command against each of the three dreamhost servers that are designated authoritative to make sure they are in synch as to what IP they are serving out.

To actually troubleshoot domain lookup issues, you should really start at the root of the Internet DNS heierchy, rather than skipping ahead as I did in the example above.  To check the entire resolving path first try querying one of the root servers (i.e. a.root-servers.net):

C:\Users\eric.rosenberry>dig www.bitplumber.net @a.root-servers.net

; <<>> DiG 9.6.0-P1 <<>> www.bitplumber.net @a.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1831
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.bitplumber.net.            IN      A

;; AUTHORITY SECTION:
net.                    172800  IN      NS      D.GTLD-SERVERS.net.
net.                    172800  IN      NS      G.GTLD-SERVERS.net.
net.                    172800  IN      NS      C.GTLD-SERVERS.net.
net.                    172800  IN      NS      H.GTLD-SERVERS.net.
net.                    172800  IN      NS      F.GTLD-SERVERS.net.
net.                    172800  IN      NS      E.GTLD-SERVERS.net.
net.                    172800  IN      NS      I.GTLD-SERVERS.net.
net.                    172800  IN      NS      A.GTLD-SERVERS.net.
net.                    172800  IN      NS      L.GTLD-SERVERS.net.
net.                    172800  IN      NS      B.GTLD-SERVERS.net.
net.                    172800  IN      NS      M.GTLD-SERVERS.net.
net.                    172800  IN      NS      J.GTLD-SERVERS.net.
net.                    172800  IN      NS      K.GTLD-SERVERS.net.

;; ADDITIONAL SECTION:
A.GTLD-SERVERS.net.     172800  IN      A       192.5.6.30
A.GTLD-SERVERS.net.     172800  IN      AAAA    2001:503:a83e::2:30
B.GTLD-SERVERS.net.     172800  IN      A       192.33.14.30
B.GTLD-SERVERS.net.     172800  IN      AAAA    2001:503:231d::2:30
C.GTLD-SERVERS.net.     172800  IN      A       192.26.92.30
D.GTLD-SERVERS.net.     172800  IN      A       192.31.80.30
E.GTLD-SERVERS.net.     172800  IN      A       192.12.94.30
F.GTLD-SERVERS.net.     172800  IN      A       192.35.51.30
G.GTLD-SERVERS.net.     172800  IN      A       192.42.93.30
H.GTLD-SERVERS.net.     172800  IN      A       192.54.112.30
I.GTLD-SERVERS.net.     172800  IN      A       192.43.172.30
J.GTLD-SERVERS.net.     172800  IN      A       192.48.79.30
K.GTLD-SERVERS.net.     172800  IN      A       192.52.178.30
L.GTLD-SERVERS.net.     172800  IN      A       192.41.162.30

;; Query time: 58 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Sun Mar 15 00:41:47 2009
;; MSG SIZE  rcvd: 505
C:\Users\eric.rosenberry>

The response from the root servers almost never changes since all they are doing these days is directing you to the DNS servers responsible for your top level domain.  .com and .net are controlled by the “GTLD” servers (run by VeriSign).  So the root servers just tell you to go ask one of the “GTLD” servers.

C:\Users\eric.rosenberry>dig www.bitplumber.net @a.gtld-servers.net

; <<>> DiG 9.6.0-P1 <<>> www.bitplumber.net @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1585
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.bitplumber.net.            IN      A

;; AUTHORITY SECTION:
bitplumber.net.         172800  IN      NS      ns1.dreamhost.com.
bitplumber.net.         172800  IN      NS      ns2.dreamhost.com.
bitplumber.net.         172800  IN      NS      ns3.dreamhost.com.

;; ADDITIONAL SECTION:
ns1.dreamhost.com.      172800  IN      A       66.33.206.206
ns2.dreamhost.com.      172800  IN      A       208.96.10.221
ns3.dreamhost.com.      172800  IN      A       66.33.216.216

;; Query time: 220 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Sun Mar 15 00:51:06 2009
;; MSG SIZE  rcvd: 151
C:\Users\eric.rosenberry>

The GTLD servers tell me that ns1.dreamhost.com, ns2, and ns3 are who I must then go ask to get the actual answer for www.bitplumber.net.  At this point you would continue as described above.

Another important command in DIG is to tell it what type of record you are looking for.  By default it looks for CNAME’s and A records, but another extremely common lookup is for MX records.  That can be accomplished as follows:

C:\Users\eric.rosenberry>dig mx rosenberry.org

; <<>> DiG 9.6.0-P1 <<>> mx rosenberry.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 492
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 7

;; QUESTION SECTION:
;rosenberry.org.                        IN      MX

;; ANSWER SECTION:
rosenberry.org.         1800    IN      MX      30 aspmx3.googlemail.com.
rosenberry.org.         1800    IN      MX      30 aspmx5.googlemail.com.
rosenberry.org.         1800    IN      MX      30 aspmx4.googlemail.com.
rosenberry.org.         1800    IN      MX      30 aspmx2.googlemail.com.
rosenberry.org.         1800    IN      MX      20 alt2.aspmx.l.google.com.
rosenberry.org.         1800    IN      MX      10 aspmx.l.google.com.
rosenberry.org.         1800    IN      MX      20 alt1.aspmx.l.google.com.

;; ADDITIONAL SECTION:
aspmx5.googlemail.com.  247     IN      A       74.125.45.27
aspmx4.googlemail.com.  3462    IN      A       66.249.93.27
aspmx2.googlemail.com.  3540    IN      A       209.85.135.27
alt2.aspmx.l.google.com. 180    IN      A       74.125.79.114
aspmx.l.google.com.     91      IN      A       209.85.199.27
alt1.aspmx.l.google.com. 127    IN      A       216.239.59.27
aspmx3.googlemail.com.  3530    IN      A       209.85.199.27

;; Query time: 87 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sun Mar 15 00:54:50 2009
;; MSG SIZE  rcvd: 323
C:\Users\eric.rosenberry> 

You can see that I use Google to host my rosenberry.org email.

There are many more things that DIG can do, but the ones described above are the most common options I use.  Hopefully this will come in handy the next time you run into DNS troubles!

-Eric

eprosenx Network