If you’re looking to learn about DNS, you’ve come to the right place. This article will cover What DNS is, Why it’s important, How it works, and How to fix it when it’s not working. Whether you’re a sysadmin preparing for an exam or you simply mistyped DND looking for your dungeons and dragons fix and ended up here by mistake, we’re glad you’re here. Everyone should know what DNS is because almost everyone uses it. In fact, you used DNS just to get here.
What is DNS
DNS stands for Domain Name System. DNS is designed to translate or resolve device names and domain names to IP addresses. Devices such as computers, cell phones, and nowadays, just about any device labeled as “smart” are designed to communicate with one another using IP addresses. IP addresses are unique numbers given to devices to differentiate one from another. Just like how you have your own unique street address to make sure your mail doesn’t end up at your neighbor’s house, devices with networking capabilities have their own unique address to ensure that information like emails gets sent to the right device.
A common analogy to describe DNS is to compare it to a phonebook, you know, those books that weighed about 10lbs and were mainly used as step stools for kids and magician’s props. Since this is 2020 and I haven’t seen a phone book since I saw a magician rip one in half over 10 years ago, let’s compare it to something more modern, like the contacts list in our cell phones. It’s difficult to remember each of your contact’s phone numbers by heart, but it is pretty easy to remember their name. Knowing their name allows you to look up their phone number. Similarly, DNS allows you to look up websites and network devices by their name instead of their IP address. My grandma can’t remember 194.1.147.20, but she can remember knitlikegranny.com.
A brief DNS history lesson
DNS has been around almost 40 years. Initially, one HOSTS.TXT file handled all of these translation requests, and it was manually updated when new entries needed to be added. This approach was manageable while the internet still consisted of a small number of devices, but as time went on, more and more devices were added, and this was no longer feasible to maintain.
In 1983, Paul Mockapetris was given the task of finding a solution that would allow name resolution to scale as the internet grew and, as a result, created the Domain Name System. While DNS has seen many advancements over the years, the original design of a decentralized name resolution system remains intact. Now, DNS servers are located all over the world.
Why is DNS important?
Let’s look back at our contacts list analogy.
While some people may only have a few contacts in their contacts lists, others have contact lists a mile long. I get a thumb workout each time I need to scroll all the way down to the Z’s to look up my friend Zac Efron’s phone number. While it may be possible to remember 10 to 20 phone numbers, or in my case, 2 to 3, memorizing a massive contacts list worth of phone numbers would be incredibly difficult. Now let’s compare that to how people use the internet. While some people may only browse a few websites, others use the internet for everything from work and shopping to information and entertainment. As a result, these users can end up visiting hundreds if not thousands of different domains.
Without DNS, you would have to memorize each one of those different domain’s IP addresses. As with remembering phone numbers, remembering a few IP addresses isn’t too bad, but memorizing hundreds or even thousands becomes impossible. And that’s just IPv4 addresses, don’t get me started on IPv6 addresses. Simply put, the internet, as it is today simply, wouldn’t be possible without DNS.
Now you might be wondering, does this only apply to the web? The answer is no. While the internet heavily relies on DNS, company networks and some home networks will use local DNS servers to ensure local network traffic can be routed to local resources and external resources.
How does DNS work?
Now that we understand what DNS is and why it’s important let’s talk about how it actually works. To do that, we’ll analyze the steps of what happens when a user browses to a website like pdq.com.
Local hosts file and DNS cache
When you enter an address for a website in a browser, the browser will first ask the OS (operating system) for the IP address of the website. The OS will check 2 locations for this information, the hosts file and the local DNS cache.
The hosts file is a system file stored locally on your computer that maps hostnames to IP addresses. You can edit this file and add your own entries, similar to how name resolution was handled during the early days of the internet.
The local DNS cache is a database of recent DNS lookups that are stored locally. When you browse to a website, your computer will keep a local record of DNS resolutions. As you can imagine, this will reduce the time it takes to lookup this website in the future. This also reduces the strain of traffic on DNS servers. It’s important to note that these entries have a TTL or Time To Live value. This value determines how long a query will remain cached before it needs to be resolved again.
Recursive resolver server
If the OS doesn’t have a cached record of the website we are trying to resolve, or a record mapped on the hosts file, the request will be sent to a DNS recursive resolver. This server will act as the middleman between the client making the DNS query and the other DNS name servers in the DNS hierarchy. Before it sends the request to the rest of the DNS hierarchy, the resolver will attempt to resolve the query by checking its local DNS cache. If it has a cached entry for the request, it will send the results back to the client; if it does not, it will forward the query to one of the DNS root servers.
Root name servers
Root servers are the first step in resolving uncached DNS queries. Root servers are at the top of the DNS hierarchy structure, and they contain information regarding the top-level domain servers. There are 13 root servers, each with its own IP address. While there used to be literally only 13 servers, now there are hundreds of servers that serve the purpose of redundancy and load balancing. Anycast is used to ensure that DNS queries are sent to root servers that will resolve the request efficiently. The root server will look at the top-level domain portion of the DNS query and provide the address of the appropriate top-level domain server. For example, if the request were for pdq.com, the root server would look at the top-level domain, which in this case is “.com,” and it would provide the address to the .com top-level domain name server.
TLD (Top-Level Domain) name servers
TLD servers are the next level of the DNS hierarchy. These servers will contain the information for the domain’s authoritative nameserver. In our example, the .com TLD server would have the address of the authoritative name server for the domain “pdq,” and it would return this information to the recursive resolver server.
Authoritative name servers
Authoritative name servers are the last level of the DNS hierarchy and contain the actual DNS records for a group of domains. These servers can give authoritative responses to DNS queries. Continuing with our example, the authoritative name server for “pdq.com” would return the address to the recursive resolver server. The recursive resolver server would then return the address to the client machine completing the request.
Recursive vs. iterative DNS queries
It’s important to know the differences between recursive and iterative DNS queries. A recursive query requires the complete name resolution or a response that the resource can’t be found. A recursive server will query other servers on the client’s behalf, trying to resolve the query. An iterative query may either respond with a referral to another server or the name resolution if they have it. Name servers given an iterative query will not query other servers, only provide a response. As a side note, most recursive queries happen between the client and the recursive resolver server, while most iterative queries take place between the recursive resolver server and other DNS servers.
Office network environment
You might be wondering how this differs from DNS queries in an office or local network environment. For internal queries, the local DNS server will be the authoritative name server for the zone it owns. It may also act as a recursive resolver server for secondary zone files. External queries will be forwarded to an external DNS server for resolution. Using an external DNS server for external queries helps keep internal domains protected and reduces internal network traffic.
How to fix 3 common DNS issues
Everyone that uses the internet uses DNS, so there are bound to be issues now and again. Luckily, DNS is one of the more straightforward services to troubleshoot. Let’s look at a few common DNS issues users may experience and how to resolve them.
1. Site cannot be reached
This may sound too familiar to some. You know you’re in trouble when you can’t even get to google.com. Before you freak out, remember, you downloaded this helpful DNS guide prior to losing your connection to the source of all information, Google. I’ll assume you’ve already checked your physical connections, made sure your router is working correctly, and that your ISP is still in business and didn’t just go bankrupt overnight. First, let’s make sure it is, in fact, a DNS issue. One of the easiest ways to do this is to see if you can ping the website you’re trying to reach using the IP address instead of the domain name.
If you can ping a website by its IP address but not by its domain name, it’s a DNS issue. One of the quickest ways to try to fix this issue is by flushing your DNS cache. Flushing your DNS cache will remove all cached DNS entries. If you had any invalid or poisoned DNS entries prohibiting you from accessing certain sites, this will wipe those out and repopulate those entries from the DNS server the next time you try to access the site. This can be done with the command “ipconfig /flushdns”.
If that doesn’t work, let’s change the DNS server settings point to a new DNS server and see if that helps. Log into your router and find your DNS settings page; this may be under a WAN settings tab. You may need to disable your router from automatically connecting to your ISP’s DNS server. Once done, you should be able to add your own DNS server manually.
Here is a list of commonly used public DNS servers:
OpenDNS: 208.67.222.222 & 208.67.220.220
Cloudflare: 1.1.1.1 & 1.0.0.1
Google: 8.8.8.8 & 8.8.4.4
2. Oops, wrong computer
An issue more commonly found in an office network environment is when you try to connect to a network resource, only to discover you’ve reached the wrong device. This can happen when a stale record is present either on the DNS server, the local client cache, or the hosts file. A couple of tools that can help us diagnose these issues are nslookup and nbtstat. The command “nslookup hostname” will allow you to query DNS for a specific hostname, and the server will return its IP address assigned in DNS. The command “nbtstat -a IP address” will allow you to query an IP address and see the hostname that is currently using that address. With these two tools, you can determine if a DNS entry is correct or not. Be aware that nbtstat is a NetBIOS command and is non-routable.
To resolve these issues, first ensure you don’t have a record on your hosts file mapping the wrong address. The hosts file can be found at C:\Windows\System32\drivers\etc\hosts. If you don’t see a record on the hosts file that could be causing the issue, clear your local cache with the “ipconfig /flushdns” command we used earlier.
If the hosts file looks okay and clearing your local DNS cache didn’t resolve the issue, the stale record is probably located on the DNS server. The simplest way to resolve this issue is to run the command “ipconfig /registerdns” locally from the device you were trying to connect to. This should force the device to update its DNS entry on the DNS server. You should then check the DNS server to ensure the record is correct. If the record still isn’t accurate, review the results from the registerdns command located on the event logs. This log could take 15 minutes to show up in event viewer after running the command.
3. Oops, many wrong computers
Let’s say you’re trying to scan computers on your network to see which ones have the latest software packages. Maybe you’re using a super cool tool that sysadmins like to use called PDQ Inventory. As the scan runs, you start to see several of the scans fail with the error “Target computer name mismatch.”
This is an indication that your DNS records are in desperate need of some TLC. Luckily, most of these issues should resolve themselves once you have scavenging properly configured on your network. Scavenging basically deletes stale DNS records.There are a few steps to configuring scavenging, and every network is going to be unique, so you will need to evaluate the best scavenging periods for your network.
To configure scavenging on your DNS servers, first ensure that scavenging is enabled on the actual DNS record by ensuring “Delete this record when it becomes stale” is checked. Don’t worry; you only need to check this on one record, after which it will be applied to all your other records.
Next, check that scavenging is configured on the DNS zone. To do this, right-click on the DNS zone and select Properties > Aging. Ensure that “Scavenge stale resource records” is checked and then configure the No-refresh interval and Refresh interval that works best for your network. The no-refresh interval is the period of time that the DNS record and its time stamp won’t be updated as long as no changes to the device have been made, such as a name or IP address change. This setting will help decrease replication traffic by limiting these updates. The refresh interval is the period of time when a record can be updated the next time the device dynamically registers with DNS. The default 7 days for both is usually a good starting point and means that a DNS record won’t become stale for 14 days. These settings should be configured to best match your environment’s specific needs.
The last place to set scavenging is on the server itself. Right-click on the server name, then click Properties > Advanced Tab and check “Enable automatic scavenging of stale records.” Again, 7 days is a pretty good starting point for this setting, but it should be configured to match your environment's needs.
With the no-refresh and the refresh interval set to 7 days, the DNS records won’t become stale for 14 days. Once the record has reached 15 days old, it’s considered stale and is available to be scavenged. With scavenging set to occur every 7 days, the record will be scavenged between 15 to 20 days old if it’s not refreshed.
Now that your scavenging is configured, the cherry on top of this DNS masterpiece is configuring your Windows DHCP server to always dynamically update DNS records. Open your DCHP console and right-click on either the IPv4 or IPv6 level, click Properties > DNS tab, and then check “Always dynamically update DNS records.” If “Discard A and PTR records when lease is deleted” is not checked, check it as well.
You'll be crying tears of joy as you celebrate your happy, healthy DNS environment you have just configured.
Conclusion
DNS is a substantial topic and can be a real BIND. With so many people using DNS every day, most without realizing it, it becomes that much more critical to learn about it. Hopefully, this article has helped you better understand some core DNS concepts. If videos are more your thing, PDQ has several videos covering DNS on our YouTube channel, like this one here. If you’re more of a hands-on type of person, PDQ Inventory has been known as a great way to detect DNS issues. You can test it out for yourself with a 14-day free trial!
