An introduction to DNS troubleshooting

The Domain Name System (DNS) is conceived of as a sort of tree. At the very top are about a dozen root servers, which are the ultimate authority for all the various other DNS units of organization of the Internet, starting with the Top Level Domains (TLDs): .com, .org, .net, and so on. Each TLD has a set of zones for which it is the authoritative source of information on the next level down. This structure continues down to the millions of individual DNS servers on the Internet. DNS servers in your own organization eventually identify how to find any named device on the Internet by using this hierarchy. Each part of the address (or URL) for a website represents a level of the DNS hierarchy.

DNS and web browsing

DNS is used when you type a name into your browser to go to a website. For example, let's look at the address:

https://www.redhat.com/sysadmin/osi-model-bean-dip

1. Your local DNS client, called a resolver, looks in its local list of addresses it knows. If you've browsed to that article on Enable Sysadmin recently, you have the address cached on your computer, and can get the page.
2. If your local resolver doesn't have the address cached, it checks with a DNS server that it's been told is the next level up in the DNS hierarchy. This may be another caching resolver or a DNS server somewhere on the network.
3. The request gets sent further up the DNS tree — usually to a root or authoritative server — and works its way back down until it finds the specific entry that points to the server you requested. In this case, it knows where www is, and then it goes to the redhat.com DNS servers, which can tell it where sysadmin lives in the hierarchy, which then directs us to the page we want.

DNS troubleshooting

Let's look at some basic tools for troubleshooting when we think DNS might not be working correctly.

When we are trying to open a web page and can't, the first thing we want to do is ping the address and see if it's reachable, and see if we're able to resolve the address.

[root@showme1 ~]# ping -c 3 redhat.com
PING redhat.com (209.132.183.105) 56(84) bytes of data.
64 bytes from redirect.redhat.com (209.132.183.105): icmp_seq=1 ttl=239 time=59.1 ms

We can see that in this case, we can resolve redhat.com to an address (209.132.183.105), and it's reachable. So assuming that is the correct address, it shouldn't be a problem. If that is not the address we are expecting to see, we need to start by checking our local configuration (/etc/resolv.conf and /etc/hosts) to make sure there isn't a local reason for the misdirection.

Let's try another: behemoth is a host in my lab that does processing for Folding at Home.

[root@showme1 ~]# ping -c 3 behemoth
ping: behemoth: Name or service not known

Let's use the host command to see if we can get some more info on what the problem might be. The host command is similar to the nslookup command, but it's slightly more succinct:

[root@showme1 ~]# host behemoth
Host behemoth not found: 3(NXDOMAIN)

That (NXDOMAIN) is an error code that means the resolver has no idea where to even look for the behemoth hostname. I'm going to try and get some more info using the dig command.

[root@showme1 ~]# dig behemoth

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> behemoth
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61042
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

This is the header, which is a summary of what the dig command is doing. We see the opcode: QUERY, meaning this is the answer to a query, then we see that NXDOMAIN reply again. Next, it tells us there was one query, with no answer, and the query was presented to one authoritative (AUTHORITY) and one other type of DNS resolver (ADDITIONAL). What this adds up to is, sure enough, nobody knows who this server is or where to find it.

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;behemoth. IN A

Here we have some more information, which includes the detail that we asked for the A record, or the main record for the server (this is the default if we don't specify a record type). We could also have been looking for an MX (mail) or CNAME (a name that points to another name) record, for example.

;; AUTHORITY SECTION:
. 223 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020040601 1800 900 604800 86400

This output displays the name of the server that received and responded to our recursive request. SOA stands for Start Of Authority, and that address is one of the root servers that we can reach from where we are (there's some other info there, including the date and time). There's another hint in this, too. The first recursive server went all the way to a root server because it was looking for more info in the name, like a domain name or a TLD (.com, .net, .org, etc.). Since we gave it neither, the root server couldn't help us. Here's what that answer looks like if we ask for behemoth.COM:

;; ANSWER SECTION:
behemoth.com. 1200 IN A 64.98.145.30

The A record for behemoth.com is 64.98.145.30, which is definitely not in my lab. So it's obvious this is not the server we're looking for.

Let's try this again after we add the local domain suffix of forest:

[root@showme1 ~]# host behemoth.forest
behemoth.forest has address 192.168.0.225

Aha! Now let’s dig:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24667
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

Note the NOERROR status, and it looks like we were able to get an answer from the local DNS server.

;; ANSWER SECTION:
behemoth.forest. 9061 IN A 192.168.0.225

This output displays the A record for behemoth, along with the contents of that record.

Let's take a look at the forest domain:

[root@showme1 ~]# dig forest

;; QUESTION SECTION:
;forest. IN A

;; AUTHORITY SECTION:
forest. 2193 IN SOA io.forest. root.io.forest. 2020012002 86400 3600 604800 10800

Here we can see that the Start of Authority for the forest domain is a server called io, so if for some reason we need to change or confirm the information in the forest domain, that's where we would do it.

Wrapping up

That's a little bit about understanding DNS and a start on learning to use the dig and host commands for troubleshooting. We'll have a more advanced tutorial, and also some advice for setting your own local DNS server, soon!

[ Want more for your network? Download a free ebook on network automation with Ansible. ]