It’s not the Network, It’s DNS.

Share This Post

One of the common denominators I find is that when our existing or new customers call us is because, according to them, the network When we get calls to troubleshoot network problems, one of the common denominators is that customers always tell us the network is not working or the network is down. To them, the network is one single item, but in reality, it’s made up of many different components that play unique parts in the communication and data flow. The many parts that make a corporate network include routers, switches, firewalls, access points, authentication servers, to name a few, and they have their unique configuration settings.  We start asking specific questions that will point us in the right direction; we ask them to show us the issue by replicating what they’ve been trying to do. Once we have enough information, we start the troubleshooting, remediation, and verification process.

One of the essential components in any network is the Dynamic Name System (DNS) service. Without it, it is impossible to perform functions such as web browsing or accessing some network resources. DNS is a service – or application – running on top of an Operating System. It requires initial configuration and ongoing administration depending on the environment. It rarely fails on its own, as most of the failures are OS-related, but when it fails, everyone notices it.

Let’s start by covering the basics of DNS.

One of the fuOne of the functions of Dynamic Name Systems (DNS) is to translate or convert hostnames to IP addresses. For example, when you want to access a website, you usually type the domain name in your web browser. If you’re going to visit NPR’s website to check on the latest news, you type www.npr.org in your web browser, and miraculously NPR’s website shows up on your screen. That makes things seem miraculous is in the case the work of DNS, unlike humans, computers use IP addresses to locate network resources, and every time you want to access network resources on the world wide web (even your LAN), that request is translated from a domain name to an IP address by DNS. The function is DNS is analogous to the old phone book by managing the mapping between names (hostnames) and numbers (IP addresses).

DNS can be categorized as Authoritative and Recursive.

Authoritative DNS provides an update mechanism that manages other DNS servers. It has the final authority over a domain name and is responsible for answering to recursive DNS requests.

Recursive DNS is the DNS server that answers to clients’ requests. Every network accessing the internet has a recursive DNS server in the form of a firewall service or as a dedicated server. Recursive DNS can also be authoritative to their own DNZ Zone, and send requests to authoritative servers for external resources.

Other DNS functions include the transfer of DNS Zones between servers, and the lookup of MX, CNAME, SRV, A, PTR records.

Basic DNS Overview:

DNS is an industry standard, and as such, there are many versions of DNS configurations running on different platforms, some of the best-known DNS servers include  Microsoft DNS, Bind, CNR, and DNS Blast. Most corporate environments running Windows Server OS run Microsoft DNS servers as it integrates with Active directory. However, it is not unusual to have Windows DNS and Bind running in the same network. DNS works the same way and under the technical principles regardless of the version.

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.

The Wireshark capture below shows the DNS request of a host, and how it UDP manages the request on port 53.

DNS was not perfect, as and such it needed improvement to address name resolution problems as technology evolved. Two DNS improvements include Extension Mechanisms for DNS (EDNS0), which allows bigger packet size over UDP (RFC 2671), and Multicast DNS (mDNS), which provides 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), which sends request addresses to 224.0.0.252 multicast addresses. Incorporated in the Windows Vista version, LLMNR allows local Windows host to perform name resolution to the same local network.

The following Wireshark capture shows Microsoft’s LLMRN in action by sending the request to 224.0.0.252.

The primary function of DNS is simple, provide the host with the IP address that represents the hostname. As simple as it sounds, many applications rely on DNS functionality for them to work, some examples of applications relying on DNS are email, directory services, VoIP calls, network resource locator, etc. If DNS fails while using any application relying on it, you will see all kinds of connection errors that can be misinterpreted as network errors.

Let’s go over a couple of technical issues to illustrate the point.

The Page cannot be found message.

In the example below, you notice the client’s browser attempting to access websites. Because DNS is failing it takes longer than usual to get a response, and after some time, the request times out.

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

There are many reasons why DNS fails, the most common are problems with the server on which DNS runs on or a that the client cannot reach a DNS server in its local subnet.

There are many things you can do to help you find the root cause of the problem if you can’t access any website. First, you may try pinging the DNS server IP address to verify that the server is up. Remember, DNS is a network service running on top of an Operating System. You may have a perfectly functional Server and still, have DNS issues so getting ping replies it’s just a troubleshooting step, it does not indicate DNS functionality.

You may want to do a nslookup to check if you can connect to the DNS server. If your attempt is unsuccessful, but you get ping replies, 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 ( when using static IP, or in the DHCP configuration).

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

In the 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 ping requests sent to the DNS 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 my localhost was unsuccessful in 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 it says, a route to that network of 10.2.2.0 does not exist in any of the route’s 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 DNS server is active, but you still don’t get a DNS query 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:

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

Does it really happen? Yes, it does, and we 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 hostname.

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 hostnames 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, there may be times when a manual DNS entry needs to be created for the host in the DNS zone.

The Hostname changed.

Sometimes you need to change the hostname on a server or PC. Most systems automatically update the DNS records to reflect the changes, but because we don’t live in a perfect world, it may be that the automatic change does not take place and you need to update the record manually. In situations like this, you need to me make sure you enter the correct host information in the DNS zone.

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 on the Internet. The update process needs to take place for all servers to hold the most up-to-date zone information.

When troubleshooting network issues, it is important to understand the components and services involved in the communication. Networks have evolved, and more services are dependent on others to function properly. 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. Web browsing, VoIP calls, Directory Services, File access, etc. depend to carry out their functions.

We are Network Experts providing highly efficient Network, Security, and WiFi Services to businesses and organizations in New Jersey. With a deep understanding of network architecture and solutions, we design, plan, implement, administer, and troubleshoot network configurations.

For details about our services and solutions, contact us at 888-580-4450 or [email protected] for more details.

Subscribe To Our Newsletter

Get updates and learn from the best

More To Explore

Meraki packet capture
Blog

Performing Simple Meraki Packet Capture.

Meraki packet capture is an essential part of troubleshooting a network running Meraki. Whether it is Access Points, firewalls, switches, cameras, or any other Meraki device, learning how to capture data and read it in a protocol analyzer is an essential part of Meraki network administration.