What is DNS?

Domain Name System (DNS) has been a core functionality for communications over the internet and LAN for decades, and yet, a lot of new developers, systems administrators, and technicians have a hard time grasping some fundamental concepts surrounding DNS. I'm hoping this article can take you from knowing little to nothing about DNS to being able to troubleshoot or implement your own DNS records or servers.

What happens when you navigate to your favorite web browser, type in https://google.com in the address bar, and hit enter? To some older computer wizards, this is a famed interview question—but strictly relating to DNS, your computer has no idea where "google.com" is (in a sense) when you're asking for it. Websites and services don't understand our written language and are unfortunately not named this way on the backend. On a network level, the server running the website you are attempting to access is assigned an IP address (172.217.1.132) by that specific host's gateway/router or Internet Service Provider (ISP). That IP address, which is just a collection of numbers, translates to a specific address (and sometimes port) on the host that is running the web server or service. For a short primer, most web servers listen for basic HTTP responses on port 80 (alt. 8080), and HTTPS responses on port 443 or (alt. 8443). DNS, on the other hand, has a specific port of 53 (or 853 in some cases, I'll discuss this more in my next article about DNS security) that will listen for DNS queries, but when we break it down, what is DNS and why do our computers need it?

DNS is the equivalent of a GPS for your network that maps your requested website's Fully Qualified Domain Name (FQDN) from your browser to an IP address connected to a device on the other side of the world. While it's important to understand which ports DNS servers listen on, DNS does not inherently deal with or even care about destination port numbers. DNS only directly maps a specified domain name to the root IP address. While not covered in this article, if you require assistance with translating DNS names from one IP address that respond on various ports, please have a look into proxies in general—more specifically, reverse proxies.

It is a way for computers and humans to easily talk to other systems without having to remember the long, convoluted IP addresses by instead using their DNS names to communicate with one another. It's easier to remember https://google.com rather than 172.217.1.132, each time you wanted to Google something. This is also helpful for services that have sub-domains, (e.g. https://maps.google.com) to also lead them to the right location when attempting to navigate to it. We'll discuss CNAME records in the next section as well for identifying subdomains.

DNS also gives us the ability to be flexible and scale systems to meet needs. Since most IP addresses aren't static and tend to change somewhat frequently, DNS ensures consistent service accessibility regardless of these shifts. Even when the IP address behind a service changes, its DNS name remains constant, offering uninterrupted access.

DNS Records

Before we get into the lifecycle of a DNS query, how DNS fundamentally works, and the resolution process, we first need to understand how the data regarding DNS names or information gets processed and returned by any system needing to access that data.

By default, DNS queries are not considered 'secret' or 'confidential' information when being transported over the network. You should take into consideration to always secure your DNS queries from potentially unwanted monitoring (or redirection), but the protocol does not call for that, and so will transmit and store your DNS requests in plain text.

Let's delve deeper into the essential aspects of DNS—DNS Records. These are essentially entries in a DNS database that pair domain names with IP addresses, enabling the DNS server to correctly respond to a request for a particular domain. These records are usually found on the final Authoritative Nameserver in the process. Here are the most significant types:

1. A Record (Address Record) - The most fundamental type, mapping a hostname to an IPv4 address. It’s akin to a phone book that links domain names to IP addresses.

2. AAAA Record - Much like an A Record, but it maps a hostname to an IPv6 address, accounting for the newer IP protocol with a broader address range.

3. CNAME Record (Canonical Name Record) - This type maps one domain name onto another. It's useful when you wish to point a subdomain, like blog.example.com, to another domain, like exampleblog.com.

4. MX Record (Mail Exchange Record) - These records guide a domain's email to the servers hosting the domain's user accounts, orchestrating email delivery to the right location. (imagine having to email IP addresses!)

5. NS Record (Name Server Record) - NS records delegate a subdomain to a set of name servers. They're pivotal when you assign a domain to another DNS server.

6. TXT Record (Text Record) - TXT records cater to various text-based information. They can hold arbitrary text and also carry machine-readable data, often used for email sender validation and other services.

7. SRV Record (Service Record) - SRV records offer information about available services within a domain, defining the hostname and port number for those specific services. (VoIP, XMPP, or LDAP related services that need port info)

8. PTR Record (Pointer Record) - PTR records handle reverse DNS lookups, mapping an IP address back to a domain name, unlike an A record which does the reverse.

Together, these common DNS record types facilitate the seamless operation of the DNS system, enabling the DNS server to route traffic accurately, be it website requests, emails, or other types of network queries. There are other important records, such as DS, SOA, or CAA records, but the ones listed above are the most used across the internet in day-to-day activities.

DNS Zones

DNS Zones are integral components in the DNS structure. A DNS zone represents a specific administrative space within the DNS hierarchy. It houses the DNS records for a particular domain and can be thought of as the "folder" containing all relevant mappings between domain names and IP addresses for that domain. In essence, a DNS zone is a portion of the DNS namespace delegated to a legal entity or organization, and its administration is handled by the same. Every domain has at least one DNS zone, and each DNS zone can contain one or more DNS records, which are essentially instructions that guide the DNS server.

Managing DNS zones is important for any DNS server administrator to understand what falls under their realm of domains. Most simple services will only utilize one or two zones, depending on how complex the DNS naming scheme for your network is. Sometimes a "Zone Transfer" has to be initiated when attempting to migrate domain names to another registrar.

DNS Resolution & DNS Caching

Behind the scenes on a high level, the DNS resolution process happens extremely quickly and has a couple of steps. When you type in that web address into the browser, after looking through your machine's local DNS cache, it will quickly contact your host's preferred DNS server (or will reach out to your gateway if one is not provided) and will request if they know how to translate your website's FQDN into an IP address that you can connect to.

The host will attempt to search its local DNS cache first to verify the domain is not cached before reaching out to any upstream DNS servers. If the website's FQDN cannot be found locally, in cases such as connecting to a website you've never been to before, or potentially the hostname or IP address has changed since your last visit, the host will then reach out to its preferred (primary upstream) DNS server and retrieve that newly modified information, storing the newly updated information in its cache.

When it receives a valid response, your computer will acknowledge that you have successfully connected to that IP address and will store that information locally on your machine to make connecting to that website faster in the future. This information is stored in your DNS Cache, and can sometimes prove to be a headache for troubleshooting DNS issues if you find yourself troubleshooting connectivity issues when attempting to connect via the domain name and not the IP address.

This is what that process looks like:

1. First, the device making the DNS request will check its local DNS cache first (client) to make sure it doesn't even need to ask anyone if the server itself can tell you where you need to go.

2. If the required information isn't in the local DNS cache, the device then turns to its configured DNS server, which is often run by your ISP (router's DNS) or could be a third-party provider like Google (8.8.8.8) or Cloudflare (1.1.1.1). This server also maintains a cache from previous requests.

   1. This can either point to an upstream DNS server, multiple DNS servers, or a single recursive server.

3. If the data isn't in its cache, the ISP's DNS server begins to query the root DNS servers. This can either be an Iterative or Recursive DNS query*. The root servers respond with a delegation, essentially saying "I don't know the IP address you're looking for, but I know who does."

4. The next stop is the Top Level Domain (TLD) DNS servers. In our case for 'google.com', it's a '.com' TLD server. These TLD servers don't have the IP address mapping either, but they can point you in the right direction. Each TLD (.com, .net, .gov, .edu, .co, .uk, .au) have their own respective TLD server that will be queried to cut down search times.

5. The TLD servers direct the query to the Authoritative DNS servers* for the specific domain, in this case, 'google.com'. These servers hold the actual DNS records (including 'A' and 'AAAA' records), which map domain names to IP addresses.

6. The IP address associated with the domain name is then returned to the ISP's DNS server or resolver and cached here. This server then sends the IP address to your device.

7. Your device stores the IP address in its local DNS cache for future reference and then connects to the desired web server using this IP address.

8. The browser communicates with the web server, sending an HTTP(S) request to the IP address returned by the DNS process.

9. Finally, the website content is delivered to the user, and are able to browse the page until another DNS request comes in.

   \ = see below for corresponding sections*

Why do we need caching? Nowadays with modern internet speeds, you attempt to navigate to a website you've never been before and your DNS servers can more than likely locate it in under a couple of milliseconds. Back in the day, this wasn't the case, and even in some instances today, some services or websites may be in far corners of the internet, which would require multiple long hops just to query a remote DNS server. Instead of having to make that request every single time we need to navigate to that website, it is pulled almost instantly from the local cache. Given the process breakdown above as well, you can see the points it is cached along the way.

Iterative & Recursive Queries

Understanding the difference between Iterative and Recursive DNS queries is fundamental to grasping or even troubleshooting your own DNS services.

In the world of networking, being the device to make every request down the potentially long line of DNS servers until you reach the last authoritative server which will return the query can be taxing and waste valuable time and system resources for every request your computer could not locate internally. There are two ways DNS is usually resolved:

• Iterative DNS Query: The device which made the initial DNS query will be the one to ask the next DNS server if they have the records they are looking for.

  This means the host will always be the first to receive the correct address, alleviating collective server load since they are not held responsible for the entirety of the query resolution process. Instead, the querying device [host] is actively engaged in the search, directly contacting each DNS server in the chain until the needed information is found. Iterative queries are inherently slower than recursive queries as it is up to the client to find and ask each server individually.

• Recursive DNS Query: The client sends a request to a DNS server, which then takes on the sole task of resolving the query from start to finish.

  The DNS server may have to contact other DNS servers to find the requested information. However, from the client's perspective, it simply submits the query and patiently waits for a response. This can simplify the client side processing and potentially enhance response times, especially if the queried information is already cached on the DNS server. However, it can also place a larger load on the DNS server as it has the responsibility of resolving the entire query for each connected host. Recursive queries also reduce latency by contacting other servers nearby with potentially newer cached results.

Authoritative DNS Servers

Authoritative DNS servers are the trusted sources in the DNS architecture—they're the ultimate authority that holds the IP mapping for specific domain names and the last stop on the ride. When you register a domain name with a domain registrar and set up your DNS, the DNS servers you designate become the authoritative servers for your domain. In other words, they're the "keepers of truth" for your domains. They're the final say in the mapping from domain name to IP address and will return the information directly to the requestor.

Authoritative servers have two types: Primary (Master) and Secondary (Slave). The primary DNS server holds the original copy of all zone records, while the secondary server has a copy that can be used as a backup or to balance the load. These servers don't use recursion; they'll provide the answer if they have it, or they'll give a reference to another server that may have it. When DNS Resolvers (which we'll talk about next) need to find the IP address associated with a domain name, they'll eventually be directed to these authoritative DNS servers to get the definitive answer.

Recursive DNS Servers

While authoritative DNS servers are the record keepers, recursive DNS servers (or DNS Resolvers) are the seekers—they do the heavy lifting when a DNS query is made. These servers take a domain name query and venture out into the vast internet, communicating with multiple DNS servers to find the corresponding IP address. They do not own any DNS record but act as an intermediary between the client (which could be your computer or device) and the DNS infrastructure.

Upon receiving a query, a recursive server checks its cache for a valid DNS record. If it's not available, the recursive server then performs a series of queries (often using iterative queries) on other DNS servers until it finds the answer or determines that the domain doesn't exist. Once the recursive server has an answer, it returns the IP address to the client and caches the record for future queries. This caching can significantly improve response times for subsequent queries.

In essence, recursive servers bear the responsibility of providing the convenience of a "one-stop-shop" for DNS queries, sparing the client the need to contact multiple DNS servers. However, this also means that recursive servers often bear a heavier load than other servers in the DNS infrastructure, particularly if they serve a large number of clients.

DNS Troubleshooting

From disrupted web browsing to inaccessible network services, DNS-related issues can spawn a variety of symptoms that hamper network functionality. With the right knowledge and tools, you can diagnose and address these hiccups effectively.

DNS Propagation

Configuring and managing DNS records, whether it involves the initial setup or subsequent modifications, necessitates careful coordination and synchronization among servers. These DNS records need to be accurately stored on your primary DNS server and subsequently disseminated (propagated) to the rest of the DNS servers globally.

This propagation ensures that all servers have the most up-to-date and correct information. However, due to natural latency in electronic communications, not to mention the potential bottleneck issues related to server load, this update process can experience delays. Some servers might be preoccupied managing their own requests and may not immediately process the incoming updates.

This is where the concept of DNS propagation comes into play. It's a process that ensures all DNS servers across the internet are updated with the most recent DNS record information. This propagation can take anywhere from a few hours to 48 hours, depending on a variety of factors such as network latency, server load, and even the configuration of the TTL (Time To Live) value for DNS records, which is the amount of time a DNS record is considered valid and not "stale". A stale record indicates the record is no longer in sync and may not contain the most accurate information.

Therefore, it's crucial to account for these factors when planning DNS changes and to anticipate possible delays in DNS record propagation. Patience and meticulous planning are key during this process, ensuring that your domain's name resolution functions smoothly and accurately across the global internet landscape.

Common DNS Issues and How to Identify Them

Several DNS issues commonly plague networks, leading to problematic outcomes. The symptoms often manifest as inaccessible websites or services, slower browsing experiences, or an inability to send or receive emails.

1. DNS Server Unavailable: One of the most common issues is when the DNS server goes offline or becomes unreachable. This could be due to a network outage or a problem with the DNS server itself.

   Resolution

   If the DNS server is unavailable, and you have verified the gateway is still up, one quick fix could be to switch to a different DNS server, such as Google's public DNS (8.8.8.8 and 8.8.4.4).

2. DNS Record Issues: Incorrect, outdated, or missing DNS records can cause all sorts of problems. An incorrect A record, for instance, can cause a website to point to the wrong IP address.

   Resolution

   Incorrect DNS records will need to be corrected on the DNS server. This usually involves logging in to the DNS control panel and making the necessary changes.

3. DNS Propagation Delays: When DNS records are updated, the changes need to propagate across all DNS servers worldwide. This process can take up to 48 hours, causing temporary accessibility issues.

   Resolution

   For propagation-related issues, patience is key. You can use an online DNS checker to monitor the status of DNS propagation.

4. DNS Cache Poisoning: This occurs when DNS queries are directed to a rogue DNS server, usually as a result of a malicious attack. The rogue server then provides false IP addresses, redirecting traffic to illegitimate destinations.

   Resolution

   If DNS cache poisoning is suspected, the DNS cache should be flushed. The procedure varies between operating systems. For instance, on a Windows machine, the command ipconfig /flushdns is used, while on a Unix-based system, the nscd service needs to be restarted.

   I go into detail about DNS Cache Poisoning in my upcoming article about DNS security.

Tools and Techniques for Troubleshooting DNS

A toolbox of reliable utilities in diagnosing DNS issues.

1. dig: primarily used in Unix-based systems, fetches and displays DNS information.

2. nslookup: queries DNS servers to obtain domain name or IP address mappings, along with other DNS records.

3. ping: The 'ping' command can check if a specific IP address (of a DNS server) is reachable, assisting in identifying connectivity issues.

4. DNS Checkers: Online DNS checkers can be used to verify if a DNS record has propagated, is online, or is secure. I highly recommend, https://dnscheck.tools. (includes DNSSEC verification!)

Remember, DNS troubleshooting is a systematic process. Identify the symptoms, narrow down the possible causes, use the appropriate tools for diagnosis, and apply the fitting solution.

I'm sure you now have a better and perhaps deeper understanding of DNS and how the resolution process plays out. This is a core pillar of how users and customers connect to your services!

If you want more in-depth information about how DNS functions on a low level, I highly recommend reading the RFC's tied to the proposal of the DNS protocol that delve into great detail about how DNS functions.

• RFC 1034: Domain Names - Concepts and Facilities

• RFC 1035: Domain Names - Implementation and Specification

Please stick around for my related DNS Security article labeled, "DNS Security Gospel: Securing Your DNS Queries", to keep your queries safe (DNSSEC), encrypted (DoT/DoH), and away from unwanted or prying eyes. I'll be releasing it sometime soon, so please subscribe to my newsletter to be updated when that publishes. As well, please keep an eye out for my various upcoming articles about configuring my own homelab/networking environment with Proxmox, pfSense, Docker, and more!