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:
- 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.
- 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.
- 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
wwwis, and then it goes to the
redhat.comDNS servers, which can tell it where
sysadminlives in the hierarchy, which then directs us to the page we want.
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 (126.96.36.199) 56(84) bytes of data. 64 bytes from redirect.redhat.com (188.8.131.52): icmp_seq=1 ttl=239 time=59.1 ms
We can see that in this case, we can resolve
redhat.com to an address
(184.108.40.206), 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/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)
(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
[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
;; ANSWER SECTION: behemoth.com. 1200 IN A 220.127.116.11
A record for
18.104.22.168, 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
[root@showme1 ~]# host behemoth.forest behemoth.forest has address 192.168.0.225
Aha! Now let’s
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24667 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
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
[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.
That's a little bit about understanding DNS and a start on learning to use the
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. ]