The Comprehensive Guide to DNS Monitoring

The comprehensive guide to DNS monitoring

DNS, or Domain Name System, is a service that translates human-readable web addresses (e.g., app.example.com) into computer-readable IP addresses (e.g., 192.1.1.1) and stores them in a hierarchical address database. The result of this process is called a namespace and enables users to consistently find, remember, and search for web destinations. 

In our example hostname, “.com” is the top-level domain, “example” is the second-level domain, and “app” is a subdomain in this domain hierarchy. Putting it all together defines the full namespace structure that the TCP/IP network uses to connect to the correct destination. 

Think of the DNS service like a postal service: mail requires an address that includes the street number, street name, unit or apartment number, city, state, and a zip code. Even more information is needed to forward mail outside of the United States. Every domain name must be associated with an IP address. As of the first quarter of 2020, 366.8 million domains were registered, representing an increase of 4.5 million new domain name registrations (1.2 percent increase from the previous quarter). This results in a large number of records stored on DNS servers distributed across the globe that require resolution to IP addresses.

The components of DNS

The individual records of a DNS are called Resource Records (RR), and the individual parts of a DNS database are called zones. Within these zones are several server and record types. To successfully monitor DNS, it’s important to be familiar with what each component does within the larger system.

DNS Monitoring requires advanced tools capable of effectively tracing queries through a complex hierarchy of servers, network links, and services.

DNS server types

When a user inputs a hostname (e.g., www.example.com), the act of processing that hostname into an IP address to deliver it to their chosen destination is called resolving. Resolving a hostname requires four types of DNS servers.

1. DNS recursor

The recursor server receives queries from client machines through applications like web browsers and checks its cache for the resolving IP address. They are also responsible for making any additional requests to satisfy the client’s DNS query. Recursor servers have no authority over record information.

2. Root name server

The root server is contacted when a DNS Recursor can’t find the relevant address in its cache. It exists at the top of the DNS hierarchy in a space known as the root zone. Queries reaching the root zone are redirected to the correct zone by responding to the recursor with the IP address of the Top-Level Domain (TLD) nameserver that should handle the query. The Internet consists of 13 root zone servers.

3. TLD nameserver

The top-level domain server (TLD) handles the next step in the search for a specific IP address. It catalogs domain names that share the same top-level domain (e.g., .com) and provides the recursor server with the IP address of the relevant authoritative nameserver to check.

4. Authoritative nameserver

The authoritative nameserver possesses information for specific hostnames, such as example.com. It resolves the hostname to its corresponding IP address and sends that address back to the recursor server, where it is then passed to the client’s browser. The browser then accesses the site using the IP address.

There are three types of authoritative nameservers: primary, secondary, and stub. The primary authoritative nameserver keeps read-write copies of DNS records and is the server where changes are made. Secondary and stub servers are read-only, with stub servers maintaining specific records (such as SOA records or glued A records).

DNS record types

DNS record types give instructions for forwarding, filtering, and contextualizing requests. The data within them can contain refresh rates, expirations, ownership information, certificates, routing preferences, and more.

A records

A (Address) records map a website’s domain or subdomain to an IPv4 address. Typically, websites have only one A record, though larger sites that require round-robin load balancing may have many A records.

CERT records

CERT (Certification) records verify a site’s authenticity and provide encrypted data. CERT records are required for sites that use logins or process payments.

CNAME records

CNAME (Canonical) records provide an alias that allows you to use title variations, which direct users to the same part of your website. For example, help.mystore.com versus support.mystore.com.

MX records

MX (Mail Exchanger) records help send and receive emails by defining which servers to deliver mail to and which are preferred for handling delivery. This record converts [email protected] into an IP address, similar to A records.

NAPTR records

NAPTR (Name Authority Pointer) records link telephone numbers and e-mail addresses to VOIP and SIP services and are less commonly used.

NS records

NS is an acronym for “nameserver.” The NS record points to the DNS server responsible for a specific domain. The NS record tells the client where to go to find out a particular domain’s IP address.

PTR records

PTR (Pointer) records direct IP traffic to domains or hostnames. This is the opposite of an A record. These records are often used to verify spam for some email programs.

TXT records

TXT (Text) records contain data for the Sender Policy Framework (SPF), which verifies domain ownership. This record is important for holding domain owners accountable for how they use domains. It’s also one way to protect your domain from being used to send spam.

The DNS in action

Although resolving hostnames is an extensive process, it is usually near-instantaneous. And because a webpage typically contains content (images, videos, links) sourced from other locations, a single query often requires multiple DNS lookups.

As you can see, many components and queries are involved in making your applications accessible to your users. If there’s a problem within the DNS, you may not even realize that users in certain locations can’t reach you. This is why DNS monitoring is so important (which we’ll come back to later).

DNS providers

DNS providers offer either managed or unmanaged services. Managed DNS providers provide customers with computing power to facilitate traffic across websites, applications, and networks. They also enable domain registration. Customers of managed DNS services typically use web consoles or desktop applications to control DNS traffic, manage DNS data, and authenticate users.

The benefits of using a Managed DNS Provider include:

• Large global DNS network to support resiliency
• Intelligent traffic routing (geo-location, policy)
• Global load balancing, cloud migration
• DNS failover for service continuity
• Secondary DNS
• Distributed denial of service (DDoS) protection
• Web application firewall (WAF)
• Anti-malware
• DNS analytics (log generation, traffic analysis, usage & downtime trends)
• Availability and disaster recovery
• DNS propagation and change management

Unmanaged DNS providers are essentially domain registrars that enable customers to purchase or reserve a domain.

The importance of DNS monitoring

DNS is an essential component of routing users to their destinations. And because most businesses rely on external DNS providers, there is often very limited insight into the service’s overall reachability, performance, and real-time record security. 

In this section, we’ll look at some of the issues that DNS monitoring can help resolve. The covered sections are:

1. Micro-Outages
2. Misconfigurations
3. DNS Poisoning
4. Denial of Service (DoS) Attacks

1. Micro-outages

Micro-outages briefly prevent users from resolving your domain and accessing your service. These outages can last from minutes up to an hour and have varying impacts depending on the services involved. The cause of micro-outages is often masked by Anycast systems used by many DNS providers. Anycast systems help ensure low DNS resolution latency by sending queries to multiple servers instead of just one, making it challenging to identify the underlying issue. Common causes of micro-outages include: physical resource (e.g., datacenter) unavailability, routing and connectivity issues, server performance problems, or network capacity limitations.

2. Misconfigurations

Misconfigured DNS servers can significantly impact your user experience. Let’s take a look at some examples.

CNAME as apex

Although CNAME records are often used to provide aliases for an existing A record, known as the CNAME’s owner record, they should never be configured as the apex domain name. This is because of the relationship between CNAME records, their owners, and their target records. CNAME records rewrite all DNS records belonging to their owner, sending those of the target record instead. Having both an A record and a CNAME record as the apex causes problems in the zone; the apex A record cannot be the CNAME owner and its target. This ultimately results in resolution failures.

For example, www.ggle.com can be a CNAME for google.com, but google.com should never be a CNAME, as it is the apex domain.

Missing glued records

Glue records are simply A records with an associated NS record. This provides the NS record with an IP address, allowing the server to resolve its own fully qualified domain name. Without glued records, resolutions, and dynamic update tasks may experience problems with delegation, DDNS updates, and query resolution failures.

Incorrect TTL values

DNS TTLs determine the lifespan of an answer within the DNS cache. Because caching plays a critical role in resolving queries, having incorrect TTL Values could mean the difference between a 1ms cached response and potentially thousands of milliseconds spent fetching an answer from the internet. Deciding how long to cache answers depends on the environment. Highly dynamic environments would experience issues with a 24-hour TTL lifespan, since changes occur much more frequently. More static environments, however, may not need a 5-minute TTL lifespan — and could even experience performance gains by increasing the value.

Lame delegation

Domain names must have at least two nameservers. When a query is made, the nameserver that answers can either be authoritative or “lame,” meaning that although it was designated as authoritative, it has no authoritative zone information for the domain name. Make sure you configure all nameservers correctly to be authoritative within the appropriate zone for their associated domain names.

3. DNS poisoning

Incorrect configurations can create opportunities for bad actors to infiltrate a service and direct traffic to malicious websites in an attack called DNS Poisoning. Massive hacking efforts that span the world have occurred using vulnerabilities discovered in DNS settings. The following diagram is an example of how even one A or NS record can compromise your traffic:

What’s worse, DNS Poisoning can spread if the affected server is a resource for ISPs. The ISPs then forward the compromised records to home routers and personal computer DNS caches.

4. Denial of Service (DoS) attacks

Hackers may attempt to render your web resources unavailable to users by flooding a specific URL with an overwhelming amount of requests. This is referred to as a Denial of Service (DoS) attack, which essentially crowds out real traffic, either slowing or completely interrupting all use.

Similarly, a Distributed Denial of Service (DDoS) attack applies the same concept but recruits thousands of maliciously infected machines (known as “botnets”) across the internet to take down the service. More recently, however, memcaching has become a popular DDoS technique.

Amplification DDoS attacks

Amplification attacks leverage simple requests, such as a short search, that require much larger responses. After finding such a request, the attacker then floods the server with these requests, forcing the DNS to respond with much heavier replies.

Reflection DDoS attacks

Attackers often try to send large, masked queries that appear to have come from their victim’s IP address. The victim then receives the answer and is overwhelmed by the traffic from the response to their network. This is done by querying a recursive nameserver with the spoofed IP address, potentially triggering two attacks: one against the authoritative nameserver being queried (via amplification) and one against the victim who receives the response. This can often make the victim appear to be the attacker on the nameserver, causing even more issues.

How to monitor for DNS performance

In this section, we will explore specific monitoring tests designed to detect breaches in DNS integrity or performance. The monitoring tests are grouped in the following sections:

1. DNS Mapping (based on end-user proximity)
2. DNS Records (evaluating the integrity of the records)
3. DNS Performance (measuring the resolution latency)

1. DNS mapping

The best way to reduce the latency of resolving a domain name is to use a DNS server that is geographically closest to the end user. Avoid using DNS servers located on a different coast or continent.

The process of mapping end-users to DNS servers based on geolocation varies depending on your managed DNS provider. Essentially, the managed DNS service provider compares the GPS location of the querying IP address to the location of each server configured within the DNS record. Sometimes, the edns-client-subnet (ECS) DNS extension is used to determine the subnet and use it to identify the physical location of the IP address.

This test, therefore, verifies that the closest DNS server is used when querying your domain from different locations around the world. A successful local DNS resolution should take less than 20 milliseconds.

2. DNS records

The series of tests documented in this section is intended to validate the integrity of the records that support domain resolution and to ensure they haven’t been misconfigured or maliciously tampered with by attackers.

Test DNS delegation

This is one of the first and most basic tests. DNS delegation verifies the name server (e.g., .com) matches the correct zone and returns the right answer.

Test NS records & root servers

After DNS Delegation is successful, the nameserver must be responsive to TCP requests. Nameservers that fail at this task may be misconfigured or blocked from responding by a firewall filter. Monitoring for successful responses ensures both your nameservers and your security measures are configured correctly to permit, receive, and respond to the appropriate traffic. It’s also important to validate your backup records. Though most providers usually pre-configure it, the root hints file is another important component worth verifying; it includes the names and IP addresses of all root servers.

Monitor SOA records

SOA (Start of Authority) records hold serial numbers and other important information on a zone’s cluster of DNS servers. Knowing when these records expire or change can shed light on performance anomalies and help contextualize them as either mundane or malicious. SOA records are typically updated whenever the Zone file is updated. If your environment is more static and its zone files are rarely updated, this can be a good indication to investigate the changes made.

Check MX & SRV records

Attackers may attempt to exploit MX records for “whaling,” essentially trapping large amounts of sensitive information in a single malicious transaction. It’s important to verify that your MX & SRV records are both resolving and also resolving to the correct exchange. Make sure these records use the correct server preference; many domains use MX records pointing to exchanges with nested levels of spam filtering. Attackers know this and often attempt to send mail to the MX record with the highest preference value, betting that it is the least protected.

Check zone transfers

The primary and secondary DNS servers must maintain identical records. This is accomplished by synchronizing the zone files that contain specific resolution information for specific domains. There are scenarios in which DNS zone transfers may not have been completed, or at least not equally across the primary and secondary DNS servers, thus preventing resolution. The zone transfers should be monitored for regular updates and completion.

Verify DNSSEC configurations

Security is important for every step of the DNS lookup process. DNSSEC provides optional security extensions to reduce vulnerabilities to DDoS attacks. You must monitor that they are 1) set up and 2) configured properly.

3. DNS performance

Track DNS propagation

DNS propagation is the time it takes for all relevant systems to update after changes to a DNS record, such as its hostname. If users are querying a system where DNS propagation has not yet occurred, they will receive the old address information. Sometimes it can take up to 72 hours for changes to propagate worldwide.

Use DNS experience tests

DNS Experience testing measures resolution time for a domain by running recursive DNS queries. Conducting these tests from servers on each level of a DNS route allows you to piece together a complete picture of how your DNS is resolved. You should use these tests to discover trends like: unusually high memory/CPU utilization or an increase in BIND query rates (DNS QPS). When internal zones are involved, you can also monitor the server’s disk I/O for simultaneous disk writes (indicating frequent zone transferring).

Monitor IP addresses

Monitor for mismatches between IPv4 A and IPv6 AAA records. This is done by comparing the cached IP address with the IP Address received.

Measure DNS latency

Several factors can impact the performance of recursive servers: their actual load, available network capacity, TLD latency to root, cache misses, and authoritative name servers, among other things. You should also measure latency from the user to the resolver.

Verify connectivity

Latency and packet loss can disrupt DNS connectivity between name servers and domains, resulting in your website being unavailable to end users. These issues can be discovered as failures during connectivity testing.

Monitor DNS servers

This would be only applicable to administrators managing all or part of their own DNS infrastructure. You can’t forget that DNS resolution performance also depends on the configuration of the hardware and software that host the DNS service. The workload on a DNS server cluster is measured in QPS (Queries Per Second). It’s important to monitor not only the servers’ CPU and memory but also disk I/O and network throughput across different QPS load levels.

Complexities of DNS monitoring

Because many solutions are cloud-hosted, picking the right synthetic monitoring tool to test your infrastructure can be tricky. For example, using an APM vendor like Dynatrace, New Relic, AppDynamics, or Datadog would mean you are using Amazon’s own data centers to monitor your DNS, resulting in near-zero latency and maximum availability. This is because your synthetic monitoring agent would not need to connect to the internet to test your infrastructure; it has a local connection via AWS. This does not reflect the behavior your users will experience.

Conclusion

DNS Monitoring requires advanced tools capable of effectively tracing queries through a complex hierarchy of servers, network links, and services. This process involves continuously querying DNS records to measure their resolution latency and comparing the results with expectations. The DNS is one of the most frequently attacked components because it provides access to a wealth of sensitive information. Rightly so, choosing the right DNS monitoring tool is crucial to ensure service availability, security, and application performance.