A Guide to DNS Troubleshooting

A Domain Name System (DNS) query is the first step in most network interactions, whether it’s across the Internet or within an office network. DNS acts as a control plane, directing traffic to servers for web, email, or API services. However, if DNS malfunctions, it can block network traffic until resolved. This is where you may find yourself in need of a guide to DNS troubleshooting.

DNS configurations can be prone to errors due to various advanced uses of DNS like load-balancing and integration with Microsoft Active Directory. In fact, there’s an Internet meme haiku that humorously captures this frustration: “It’s not DNS. There’s no way it’s DNS. It was DNS.”

But don’t worry, there’s still hope! You can troubleshoot and resolve DNS issues by breaking down the components of the Domain Name System, examining each one for problems, and addressing the root cause. In this blog post, we’ll guide you on how to troubleshoot DNS issues effectively so you can analyze and resolve them promptly.

Authoritative v/s recursive v/s forwarder DNS servers

The DNS consists of two main types that work together: authoritative and recursive. The authoritative side holds answers, while the recursive side receives queries and searches for answers from the authoritative side.

Authoritative DNS is a distributed database organized in a hierarchy or tree structure. It stores resource records for domains, subdomains, top-level domains, and the root of the hierarchy. 

Each tier, called a “zone”, in the tree points to the next lower tier. For example, the authoritative servers for the root point to the authoritative servers for the top-level domain, which then point to the authoritative servers for the specific domain, and so on.

On the other hand, recursive DNS servers, often referred to as “domain controllers”, “resolvers”, or “DNS servers”, receive queries from computers on the network and navigate through the hierarchy of authoritative servers to find answers. Once they obtain an answer, they provide it to the querying computer. A specific type of recursive server called a forwarder receives queries and forwards them to a recursive server.

Recursive-side servers typically cache answers to improve performance. Each DNS answer has a Time-To-Live (TTL) value, specified in seconds, which determines how long a recursive-side server can store the answer.

Sometimes DNS isn’t DNS: Introducing multicast DNS

Many desktop operating systems and network devices support a feature called Multicast DNS (mDNS), known by various names such as Bonjour, Zeroconf, Avahi, DNS Services Discovery (DNS-SD), or Link-Local Multicast Name Resolution (LLMNR). mDNS functions as a broadcast form of DNS, where computers on a local network use broadcast messages to search for a computer or service.

mDNS is typically enabled by default and proves useful in home networks or small offices with limited devices. However, in larger environments or outside corporate networks, using mDNS can pose a security risk, as any computer on the network can impersonate another.

It’s important to note when you are troubleshooting your DNS, mDNS operates alongside the two-part DNS system of authoritative and recursive servers. This can result in a wide variety of “incorrect” query answers, which may give the impression of DNS behaving inconsistently.

Introducing Dig: The DNS Swiss army knife

Unix and compatible operating systems such as Linux, BSD, and MacOS have a DNS query tool called dig. Dig is also available in Microsoft Windows through the Windows Subsystem for Linux. 

It provides various options, including query types and remote recursive servers that can be explored using the online manual accessed with the command “man dig”. However, we usually rely on only a few essential options.

@servername: send the query to a specific recursive server (example: dig @64.6.64.6 vercara.com)

-t: send a specific query type (example: dig -t NS vercara.com).

+short: display just the answer instead of the full reply (example: dig +short vercara.com).

+trace: display the full recursion path and answers, starting from the root servers.

The output of the dig command may take some time to become familiar with, but with practice, it becomes more understandable and user-friendly. For example, if we run the following query: 

$ dig -t NS vercara.com

The first thing we see is the header section.

This tells us which version of Dig we used, the command line that we used, and that we sent a query that gave us 6 answers.

Next is the question section

;; QUESTION SECTION:

;vercara.com. IN NS

We’re looking for the NS record for Internet Protocol for Vercara.com.
After that is the Answer Section which lists the answers that were received from full or partial recursion.

86400 is the TTL. The query type was Internet Protocol and a nameserver and we received 6 answers.

And finally, we get the timing results.

The important thing to note is the Server line, which gives us the IP address and port that we sent the query to.

And the full reply looks like the following:

Now that we have all of the background on how DNS works and a command-line tool to make queries, let’s look at scenarios.

But first, flush your DNS cache

A lot of the time, what seems to be network or DNS errors are really just old data being cached on your operating system, especially if the answers recently changed. A good flush of the local DNS cache will clear up these problems and force the computer to query a recursive server to get a new query answer.

In Microsoft Windows from the command line:

ipconfig /flushdns

In MacOS from the command line:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux is a bit more complex, depending on what system you use, but the command will be one of the following:

sudo resolvectl flush-caches

sudo killall -USR2 systemd-resolved

Test your local resolver

Local Area Networks (LANs) usually have a recursive-side server, called a resolver, that is either part of the Dynamic Host Control Protocol (DHCP) offer or entered manually in the network settings on computers.

You can identify your local resolver through your computer’s network settings or through the command line.

In Microsoft Windows, you find your local resolver in Settings => Network and Internet => Status => Properties:

From the command line:

ipconfig /all

In MacOS, you can get your resolver from System Settings => Network.

From the command line:

$cat /etc/resolv.conf

nameserver 192.168.2.1 

In Ubuntu Linux, you can find your resolver in Settings => Network.

From the command line:

$ cat /etc/resolv.conf

nameserver 192.168.2.1

The next thing to do is to verify that your network works and that you can reach your recursive DNS server. You can do this on all operating systems with the ping command.

If you can get to your recursive server, you can use dig to query it for several known FQDNs.

$dig +short @192.168.2.1 vercara.com

$dig +short @192.168.2.1 google.com

$dig +short @192.168.2.1 microsoft.com

How to tell if something is wrong:

If you get no answer from your local recursive, it could be a network error or the recursive is not functioning. Try to bypass the local recursive.

If you can get an answer for other domains on the Internet but can’t get an answer for a specific domain, it could be that the authoritative DNS or the “glue record” from a higher tier in the authoritative hierarchy is misconfigured.

Testing for mDNS

Testing for mDNS should be a lot more direct than it is. Using the ping command on a FQDN forces a DNS query which can be compared to the answer provided by a recursive server.

How to tell if something is wrong:

mDNS provides a different answer than your recursive server.

Check Your Hosts File

In the early days of computer networks, operating systems had a hosts file that contained computer names and their IP addresses. That function still exists, and we use it to bypass DNS resolution for installing new networks and servers, or for testing in a lab. If there is an entry inside the hosts file, that will override anything that is provided by a recursive DNS server.

Inside Microsoft Windows, the hosts file is located at C:\Windows\System32\drivers\etc\hosts

You can read it with the more command in the command prompt, or edit it with Wordpad/Notepad.

more C:\Windows\System32\drivers\etc\hosts

MacOS and Linux, from the command line:

$ cat /etc/hosts$ cat /etc/hosts

127.0.0.1 localhost

156.154.120.112 www.vercara.com vercara.com cdn.vercara.com

How to tell if something is wrong:

There is an entry in the hosts file corresponding to the FQDN that you are trying to reach. You can edit the hosts file to comment out that entry with a “#”.

Bypass your local recursive.

There are numerous open recursive DNS servers on the Internet. These allow you to use them for queries for zones on the Internet and compare query answers with what is being provided by the recursive that your network uses.

Vercara has an UltraDNS Public open recursive DNS server that you can use at 64.6.64.6 and 64.6.65.6. You can find other information here. https://vercara.com/ultra-dns-public.

$ dig @64.6.64.6 +short vercara.com

156.154.120.112

How to tell if something is wrong:

If your local recursive gives a much different answer than a public open recursive, it could be a misconfiguration on your recursive, a stale cached answer on your recursive, or an attack such as a cache poisoning or route hijacking upstream of your recursive.

If your local recursive gives you no answer and a public open recursive server gives you an answer, then most likely you have a network or software problem with your local recursive. It could also be that your recursive server needs its “root hints” file updated so that it can find the root authoritative servers.

Query the authoritative servers for a domain.

If you’re experiencing issues with a local resolver or recursion, it can be useful to directly query the authoritative DNS servers for the domain. This allows you to bypass any recursion and caching that may exist between your computer and the authoritative server. To start, use the “-t ns” option in dig to find the authoritative nameservers for the domain or zone.

Next, you can query each authoritative DNS server for that domain one by one to find any servers that may be giving incorrect answers.

Cheat mode: Just trace it.

Luckily, dig also offers a useful option called “trace” that provides all the recursion answers from a local or remote recursive server. To run it, simply use the “+trace” command line option.

DNS may seem simple at first, like finding a phone number in a phonebook. But due to its long service history, various network protocols, and advanced usage, DNS errors can and do occur. Effectively troubleshooting DNS issues is key to keeping the packets flowing smoothly.

Skip the worries of DNS troubleshooting. Work with Vercara

Join the ranks of the world’s most successful brands that rely on Vercara for comprehensive cloud security solutions. Our industry-leading services are meticulously designed to offer expansive global coverage, ensuring your critical assets are protected around the clock.

• Benefit from Vercara’s purpose-built solutions that deliver unparalleled protection.
• Experience peace of mind with our 24/7/365 expert-driven security, ready to defend your assets at any moment.
• Trust in a team that prioritizes your needs, with a proven track record of putting customers first and understanding the vital importance of online security.
• Rest assured with a partner that’s renowned for safeguarding the digital presence of the world’s most respected and successful brands.

Contact us today.