It’s not the Network, It’s DNS

One of the common denominators I find is that when our existing or new customers call us is because, according to them, the network is not working. It does not matter if it’s an ISP problem, and server issue, application problem, user problem, or anything else, to them the problem is the network.  Understandably so, I dissect the message they are conveying and do my work to understand and analyze the root cause of the problem, after all the reason why they brought me over in the first place is to fix whatever is broken and not to correct their technical lingo.

Let’s start by covering the basics of DNS.  

One of the functions of Dynamic Name Systems (DNS) is to translate or convert host names to IP addresses. For example, when you do a search for a host name such as www.precisetek.com DNS goes through a process to find out what IP address is associated with the host name, in our case the IP is 216.185.153.136. Other functions of DNS include the transfer of Zones between servers, translate IP to host names, look up other resources such as MX, CNAME, SRV, records, etc.

DNS is an industry standard, there are many versions of DNS configurations such as Microsoft DNS, Bind, CNR, DNS Blast, etc. In most corporate environments running Windows Server OS run Microsoft DNS servers as it integrates with Active directory. Even though there are many DNS solutions available they all work under the same principle and process. 

Basic DNS Overview: 

As stated earlier DNS is in charge of managing name to IP conversion. From the technical perspective DNS runs over UDP on port 53, however when the payload is over 512 bytes the flag bit is sent in the response which forces the resolver to resend the query using TCP.  You can reference RFC 1035 for details. The example below depicts normal DNS communication between a server and a host. The DNS server is responding to a query, you see the DNS server communicating on UDP port 53.

Improvement to DNS were made by Extension Mechanisms for DNS (EDNS0)  allowing greater packet size over UDP  (RFC 2671) and by Multicast DNS (mDNS) which allows name resolutions for networks without a DNS server ending in the .local suffix by sending the request to the multicast address of 224.0.0.251. For details about mDNS visit http://www.ietf.org/rfc/rfc6762.txt.

Microsoft Windows desktop systems also use an improved name resolution process called Link-Local Multicast Name Resolution (LLMNR) sending request address to 224.0.0.252 multicast address. Incorporated in the Windows Vista version, LLMNR allows local Windows host to perform name resolution to the same local network. 


The basic function of DNS is simple, provide the host with the IP address that represents the host name.  As simple as it sounds many application rely on DNS functionality to operate as intended, for instance, if you experience DNS while browsing the you will experience errors that will lead you to believe that the network is not working, thus the title of the article. Just to mention a few more applications relying on DNS: Emails, Web browsing, Network Applications, Network Access, Directory Services, VoIP, etc., rely on one form or another on DNS to reach their destination IP address.

The basic overview is what we need to troubleshoot DNS issues on a flat network as the communication is straight forward between the client and the server. The process is simple, the client queries the server for a host name, if the server has an answer it sends it back to the client, if not it forwards the request to anther DNS server.

Let's go over a couple technical issues to illustrate the point:

The Page cannot be found message:

In the example below you can notice the client’s browser response to a web search when DNS becomes unavailable. At the bottom left corner the resolver displays the Resolving Host message as it attempts to find contact other query the server again for an answer. 

In this case the computer has network and internet access but is unable to access certain network resources that rely on DNS, such as web sites.

There are many reason why this would happen, the most common being DNS server issues, either the client communicating with the DNS server, the server, or DNS itself.

At this point you may try pinging the DNS server IP address to verify that the server is up or contact the administrator of the server. Remember, DNS is a network service running on top the Operating System. You may have a perfectly functional Server and still have DNS issues so getting ping replies it’s just troubleshooting step, it does not indicate DNS functionality. 


You may want to do an nslookup to check if you can connect to the DNS server and resolve a host name. If your attempt is unsuccessful running the nslookup but successful pinging the server then It is not a network problem and everything is pointing to be a DNS issue – or not. 


Before we blame DNS we have to cover the basics, let’s not be so fast in pointing fingers at it yet, there are many more variables that need to be checked before putting fault on DNS.

For starters let’s cover the basics again and make sure that the DNS server address is correct. I have seen this issue firsthand many times, someone mistypes the server’s IP address in the IP settings and then things don’t work. When the business brings me in for troubleshooting the first thing they tell me is “The network is not working”. Not so fast I tell them, knowing what I know.

Let’s go over a packet capture to illustrate my point. 

In example below the DNS server IP address of 10.2.2.2 is not a valid IP address for the network.

The top section of the capture reveals how the system attempts to ping the DNS server’s IP address after the resolver was unsuccessful to reach the server. Remember the previous picture showing the “Resolving host” message and the “This web page is not available” message? Well as a last resource the system sends an ICMP packet to the DNS’ server IP address in hopes of establishing communication.  The system, desperate to find the server, contacted the ISP default gateway (130.81.170.160) in hopes of finding a route to the 10.2.2.2 DNS server.

The middle section shows that my local host was unsuccessful finding a route to the DNS network, In this case the IP address of the server was invalid, thus getting an ICMP code 0 of Network Unreachable reply message.  ICMP Code 0 Network unreachable means exactly what is says, a route to that network of 10.2.2.0 does not exist in any of the routers’ routing table.
The last section shows the DNS traffic and ports used when trying to establish the connection, it’s just standard communication of DNS over UDP port 53.

So what happens if you are using valid network IP for DNS but you still don’t get a response? Well, packets don’t lie and they will tell you what’s going on.  If the IP is valid but you still can’t resolve then it could be that the port is blocked.

Let’s go over that example in the following capture.

Notice how in capture shows ICMP returns a Code 3 message (Port Unreachable) message. There are many reason why this would happen, you may want to check that the IP address is valid for a DNS server and if there’s any firewall (either on the server or between hosts) blocking UDP port 53.

Does it really happen? Yes it does, and I deal with it all the time. On a similar note, one of the most interesting thing I’ve seen regarding not reaching UDP port 53 was a faulty firewall. All the rules were correctly in place, traffic was allowed but the client still experienced intermittent DNS disconnects that made many applications fail. After hours of troubleshooting it turned out to be something with the firewall’s firmware causing DNS inconsistencies by dropping UDP port 53 traffic. 

All network and IP settings are correct but still unable to resolve a host name.

Finally we have proven that it’s not the network but the problem still persists. If all the network settings are correct and still unable to resolve host names then you have to start looking into DNS itself, to properly troubleshoot DNS you have to understand how it works. The most common issue I’ve seen, especially in Microsoft environments is that the DNS process stops working, sometimes restarting the process or the server does the trick. 

Another common mistake is that the record you are looking for is not registered in the DNS server, there may be times when a manual DNS entry must be created for the host. You may be required to create an A, CNAME, MX, or any other type of record because the host itself is not able to update the DNS zone.

The Host name changed, it may be necessary to change the host name on a server or pc, depending on the Operating System it will update the DNS settings on the server but there could be a situation when the update needs to be manually entered but if you are doing a search for a host no longer has the name you are searching you will get a host cannot be found message.

Zone Replication issues. It takes time for DNS servers holding the same Zone to update the information, it does not matter if you accessing resources locally or the Internet there’s an update process that needs to take place for all servers to hold the most up to date information.

When troubleshooting network issues is important to understand the components and services that are involved in the communication.  Networks have evolved and now more services are dependent on others than before, as it is the case for DNS. DNS is one of the most important network applications, it "binds many services together" as it helps other applications locate resources. If it does not function correctly other applications running on the network will suffer as well, functions such as: web browsing, VoIP calls, Directory Services, File access, etc., will be affected as they rely heavily on name resolution to carry out their functions. 

__________________________________________________________________________________________________________________________________

Thank you for reading my article, please leave valuable feedback.  If you liked this article and would like to see more, please click the Yes button near the: Was this article helpful?  at the bottom of this article just below and to the right of this information.  Jorge D. (Linkedin)