The Domain Name System (DNS) is the Internet's phonebook. Without DNS, we would have to remember that to visit traingrc.com, we would need to navigate to 184.108.40.206 or search for something on google.com we would have to go to 220.127.116.11.
Invented in 1984, DNS is one of the core foundational technologies of the Internet. While the DNS specification has been consistently updated over the years to accommodate the increasing complexity of the Internet, its core functionality has largely remained unchanged. That is looking up domain names for their corresponding IP addresses.
While still serving its core functionality, DNS has expanded its role on the Internet. DNS is now a critical underlying technology in:
- Global service load balancing
- Content Delivery Network (CDN) routing
- Email Security
- Encryption and privacy
- Resource Ownership Validation
DNS is arguably the most pervasive technology on the Internet. Everyone uses it hundreds of times per day, many without even knowing it exists. Google's public DNS resolver (18.104.22.168) in 2018 received over 1 trillion (1,000,000,000,000) DNS queries each day!
The reliance of the Internet on DNS has made it an attractive target for attacks. According to the 2021 IDC Global DNS Threat Report, almost 90% of organizations surveyed have experienced a DNS attack, with about half of those companies suffering an outage due to the Attack.
These figures illustrate why as security professionals, we need to understand this vitally important technology, the threats that exist against it, and how we can protect our systems and networks.
This blog post will cover the basics of DNS, common DNS-related vulnerabilities, and what we can do to mitigate these issues as security professionals.
What is DNS?
At the most basic of descriptions, DNS translates domain names (e.g., traingrc.com) to IP addresses (22.214.171.124) so that web browsers can load the requested resources from the remote server.
Using the phone book analogy, you typically remember a name over trying to remember a phone number when you want to call a friend. Luckily we have a directory (the phone book) where you can look up a friend's name to find the number you need to dial to reach them. This is essentially what your browser does with DNS.
The DNS Process
To understand what DNS is, let's walk through what your browser does when your try to navigate to a URL (don't worry about the specific DNS technologies, we will go through them soon):
- You open a web browser and enter traingrc.com into the address bar.
- The web browser sends a query request to a DNS Resolver.
- The DNS Resolver queries a Root Name Server for the .com Top Level Domain (TLD) Nameserver.
- The Root Name Server responds to the DNS Resolver with the address of the relevant (.com) TLD Nameserver.
- The DNS Resolver queries the TLD Name Server for the traingrc.com Nameserver.
- The TLD Name Server responds to the DNS Resolver with the address of the traingrc.com Authoritative Nameserver.
- The DNS Resolver queries the traingrc.com Authoritative Nameserver.
- The Authoritative Nameserver responds with the IP address for traingrc.com
- The DNS Resolver finally responds to the web browser with the IP address it located for traingrc.com.
- The web browser makes an HTTP request to the IP address
- The server at that IP address returns the webpage for traingrc.com.
NOTE: Insert diagram
DNS Concepts & Technologies
And what are some of these DNS concepts and technologies?
A Domain Name is a human-friendly name associated with an IP address. For example traingrc.com
Domain Names registrations are purchased through Domain Registrars who have been delegated the right from a TLD Registry to "sell" unique domains under that TLD.
TLD Registries maintain a database of registrant information associated with all the domains under their TLD. These databases are known as WHOIS services. ICANN maintains the WHOIS database for the Generic Top-Level Domains (gTLDs).
When registering a Domain Name, you need to be careful. Your Personally Identifiable Information (PII) can easily end up in these public databases. Many Domain Registrars offer Domain Purchases the option to obfuscate their personal information in the WHOIS record. However, this may be an optional extra on purchase, so be careful.
DNS Resource Records (RRs) are the information elements about a domain name's associated hosts. RRs are stored on a DNS Server in Zone Files. There are many different RRs, each loosely associated with different internet technology. Some of the most common RRs are:
- A Record (Address Mapping record)
- links a domain to an IPv4 address hosting that domains services
- hosts with IPv6 addresses use the associated AAAA Record.
- CNAME Record (Canonical Name Record)
- an alias name to another true or canonical domain name.
- MX Record (Mail Exchange Record)
- Directs a domain's emails to a server hosting the email server.
- NS Record (Nameserver Record)
- identifies which servers will communicate DNS information for the domain
- TXT Record (Text Record)
- provides text information for many arbitrary purposes
- CERT Record (Certificate Record)
- stores encryption certificates and keys
- suchs as SPKI, PGP, PKIX, etc...
- SRV Record (Service Record)
- like MX Records but for newer protocols
Each RR Also has an :
- TTL (Time to Live)
- A value that determines how many seconds before a record should be queried for change.
- Caching is an essential concept in DNS, and TTLs inform the Caches on how long they should serve a cached response.
The DNS protocol is simple, consisting of two types of messages - queries and replies. Both queries and replies consist of a header, questions, and answers.
- The header section contains an ID (used to match queries with replies), Flags, and the number of questions, answers, authority RR, and additional RRs.
- The question section contains the domain name and type of record (A, AAAA, MX, TXT, etc.) being resolved.
- The answer section has the resource records of the queried name.
DNS primarily uses the User Datagram Protocol (UDP) on port number 53 to serve requests. DNS queries consist of a single UDP request from the client followed by a single UDP reply from the server.
The Transmission Control Protocol (TCP) is used when the response data size exceeds 512 bytes or for zone transfers. Some DNS resolvers use TCP for all communication.
A DNS Resolver (also known as a Recursive Resolver) is a server that receives DNS queries from clients (such as web browsers). It is responsible for making additional requests to different Nameservers to find the correct response to the client's request.
The Root Nameserver is at the very top of the DNS hierarchy. The Root Nameserver maintains the Zone file for the TLD Nameservers.
There are 13 Root Nameservers on the Internet (in reality, there are more, but only 13 IP addresses associated with them), assigned the letters' A' through 'M'. ICANN is responsible for the Root Nameservers; however, they are maintained by different institutions worldwide (predominantly located in the US or Europe). All must contain identical Zone files.
TLD Nameservers are the next branch down in the DNS hierarchy after the Root Nameservers. TLD Nameservers handle the DNS queries for Domains under the TLDs they manage, for example, .com, .net, or .org.
TLD Nameserver stores the location of all Authoritative Nameservers for the domains under its TLD. For example, the. COM TLD Nameserver provides "NS-1081.AWSDNS-07.ORG" as the Nameserver for traingrs.com, one of the "Amazon Route 53" Nameservers.
The final Nameserver in the DNS hierarchy. A domain's Authoritative Nameserver stores the domain's Resource Records.
The Resource Records within a Domain's Authoritative Nameserver are maintained by a Domain Administrator, usually within the organization's IT team.
The Authoritative Nameserver must be strictly controlled with limited access and strong authentication. Unauthorized access to an organization's Authoritative Nameserver can have severe consequences. It controls how a user can find your domains on the Internet.
DNS Caching significantly improves response times and reduces DNS traffic on the network and the load on Nameservers. DNS caching is possible because DNS Resource Records are generally infrequently changed.
Caching temporarily stores DNS Resource Records closer to the requesting client to avoid full DNS hierarchy lookups. The following locations are used to store DNS Caches:
- Browser DNS Cache:
- Browsers by default cache DNS Resource Records for a certain amount of time.
- The browser cache is the first location checked with a DNS query.
- Operating System DNS Cache:
- Most Operating Systems have a built-in DNS Cache called stub resolvers that handle queries before sending them to an external DNS Resolvers.
- The Stub Resolver is usually queried after the browser or other querying application.
- Resolver Cache:
- DNS Resolvers will usually cache all previous query results for a specific time
- A DNS Resolver will usually cache a Domain's Authoritative Nameserver to query it directly rather than recursively via the Root Nameserver and TLD Nameserver.
A Cached Resource Record will become stale when its TTL has expired. Any DNS cache will be expected to retrieve a fresh copy of the Resource Record whenever a stale resource has been queried.
DNS over TLS & DNS over HTTPS
Standard DNS queries and responses are sent in plaintext, which means anyone who can sniff your network traffic can read them. Depending on your situation and privacy risks, this may be an issue.
DNS over TLS (DoT) and DNS over HTTPS (DoH) provide data confidentiality for DNS traffic through encryption in transit technologies. However, solve this problem slightly differently, with different pros and cons:
- DNS queries are encrypted and sent via the HTTPS Protocol (TCP port 443)
- DoH essentially looks like HTTPS traffic.
- High level of privacy as the DNS queries are hidden in a large amount of regular HTTPS traffic.
- DNS queries are encrypted using the TLS Protocol but still sent using UDP on port 853
- preferred by network administrators as it still allows for the ability to monitor the use of DNS (however, not the query itself), identify and block malicious traffic
Many of the major public DNS providers (such as Google and Amazon) encourage the use of DoH.
The DNS Security Extension (DNSSEC), introduced by ICANN in 2018, is an effort to improve DNS integrity.
Without DNSSEC, an attacker may be able to perform a Man-in-the-Middle attack and hijack lookups between 2nd and 3rd-level nameservers. This Attack would allow the attacker to modify the requests and redirect users to malicious web servers.
DNS Servers that implement DNSSEC digitally sign all requests to guarantee the authenticity of the lookup chain. For example, in the case of a google.com lookup, a root DNS server would sign a key for the .COM nameserver, and the .COM nameserver would then sign a key for google.com's authoritative Nameserver.
Unfortunately, DNSSEC is still not widely adopted, with adoption in 2021 at around 5%. The primary reason for this slow adoption is its implementation and maintenance complexity.
DNS Threats & Mitigations
Now that we understand DNS, we can look into some of the risks associated with its use.
When initially created in 1984, DNS, like many internet protocols, did not have to consider the modern threat landscape that is the Internet. Because of this, DNS has certain design flaws that introduce vulnerability to the technology. These limitations, combined with technological advancements over the past 40 years, make DNS vulnerable to a broad spectrum of attacks.
When reviewed against the CIA triad (Confidentiality, Integrity, and Availability), DNS in its original format was significantly lacking in confidentiality and integrity security controls. Over the years, additional features have been added to DNS to mitigate some of these issues. In this section, we will look at some of the vulnerabilities related to DNS that have been exploited by attackers over the years and then discuss what security controls exist to mitigate the threats.
Common DNS Threats
DNS Cache Poisoning
A DNS cache poisoning attack aims to divert users away from their intended legitimate target and have their requests sent to a malicious target. This objective is achieved by an attacker causing a DNS Resolver's Cache to be "poisoned" with illegitimate Resource Records for a specific domain.
A DNS Cache Poisoning attack is usually performed by:
- An attacker requests an IP address from a DNS Resolver.
- If the Resolver has not already cached this record, it will query the Authoritative Nameserver for the answer.
- Being an unauthenticated protocol, the attacker floods the DNS Resolver with malicious responses, essentially "racing" the Authoritative server to answer the request.
- If the attacker succeeds, then the DNS Resolver will assume the malicious response is the legitimate record and store that in its cache.
- Any user that then requests the same resources will be provided the poisoned cached result from the DNS Resolver cache, thus directing the user to the attacker-controlled server.
In 2018 the online cryptocurrency wallet provider MyEtherWallet was the victim of a supposed DNS cache poisoning attack. The Google public DNS server had cached a poisoned record for myEtherWallet.com that redirected users to a phishing website for a few hours. According to CoinDesk, users of the service lost around 215 Etherium, valued today at around $400,000.
Over the years, enhancements have been made that attempt to mitigate DNS Cache Poisoning; these include:
- Transaction ID randomisation
- Source port randomisation
These enhancements did not eliminate the vulnerability. They only reduced the likelihood of compromise by increasing the response keyspace (the response must have both the correct transaction ID and the correct source port).
DNSSEC eliminates this vulnerability as requests are now digitally signed and validated. However, as discussed previously, we cannot rely upon it to be implemented due to its slow adoption.
When a Domain Name is purchased from a Domain Registrar, the Registrar commonly becomes the Authoritative Nameserver for the domain.
Attackers are known to attack Domain Registrar user accounts, generally through compromising weak credentials. Suppose an attacker can compromise your account with the Registrar. In that case, they can take control of the domain, transfer ownership, or redirect requests to malicious servers under their control.
In 2019 Talos and GCHQ reported on a large-scale DNS Hijacking campaign (dubbed the "DNSpinage Campaign") targeting government and large organizations. This campaign used Phishing Attacks to steal valid credentials from Registrar users to allow the attackers to redirect legitimate domain traffic to their malicious servers.
To reduce the risk of a DNS Hijacking attack, users must enforce strong authentication (preferably with Multi Factor authentication) on their domain registrar accounts.
Many Registrars also 'lock' services (sometimes at a cost) that implement additional security steps before allowing nameserver records to be changed. The Registrar must carry out identity verification for the domain owner to unlock a record.
Typosquatting occurs when an attacker registers a fake domain name almost identical to the target's domain name (e.g., train-grc.com compared to traingrc.com). Through a phishing attacker (or hoping that a user mistypes a domain name), attackers will attempt to direct a user to the malicious typosquatting domain hoping that the user will not recognize the subtle difference in the domain name.
In 2011 security researchers registered several domains similar to those of the Fortune 500 companies. Over 6 months, the security researchers' typosquatting domains received more than 120,000 misaddressed emails and 20GB of sensitive data meant for the legitimate domains. Consider the impact if these researchers were malicious attackers and what they could’ve done with all that stolen sensitive information.
Typosquatting is a difficult threat to defend against as it is a threat largely outside of the organization's control.
The only practical mitigations for typosquatting are:
- purchase domains that are likely to be used for typosquatting
- monitoring for the registration of typosquatting domains
- monitor for phishing or watering hole websites related to your organization.
DNS Amplification DDoS Attack
DNS amplification is a technique attackers use to significantly increase the amount of Distributed Denial of Service (DDoS) traffic being sent to their target.
The Attack is caused by the insecure configuration of a public DNS server that permits recursions. An attacker can send a request to the vulnerable DNS server with the Source address set to be their intended victim. The DNS Server will attempt to respond to the request, sending the response, which will be many times larger than the initial request, to the attacker's intended victim. The traffic sent to the victim will be "amplified", resulting in what the attacker hopes will be a successful DDoS attack.
In 2021 Cloudflare reportedly successfully blocked a massive DNS Amplification DDoS attack that peaked at just under 2 Terabits per second of traffic.
The primary mitigation strategy against DNS Amplification DDoS attacks is the responsibility of the owners and maintainers of public DNS resolvers. Current versions of DNS servers deny by default the use of DNS reflection. They also limit the size of the DNS response based on the size of the request to reduce the amplification.
Companies can purchase DDoS protection services from companies such as Cloudflare, F5, Amazon, or Microsoft to protect their infrastructure from such DDoS attacks.
Data Exfiltration via DNS Tunneling
As DNS is a critical service to the Internet, its protocol is commonly allowed through firewalls to enable users to access resources on the Internet. This fact is frequently exploited by attackers.
DNS Tunneling encodes messages in DNS queries and answers to evade detection and traverse network boundaries.
The most effective strategy in mitigating data exfiltration via DNS Tunneling is to implement effective DNS traffic monitoring and monitor for suspicious DNS requests and responses.
However, with DNS over TLS providing encrypted DNS messages, DNS Tunneling is becoming harder to detect and mitigate as we can no longer easily inspect the DN traffic.
Historically DNS queries have not been encrypted. This has resulted in the threat to the users' privacy requesting domain name resolution. Anyone who can intercept the request can see which domains the users were querying.
This lack of privacy within DNS has enabled human rights violations in many oppressive countries, through tracking or censorship.
Many of the recent improvements made to DNS have improved the confidentiality of DNS queries and responses. Some of these features include:
- DNS over TLS
- DNS over HTTP
- QNAME Minimisation
The first step of most cyber attacks is to perform reconnaissance of the intended victim. DNS Records are designed for public consumption, making them an ideal resource for an attacker to learn more about the target environment.
DNS based reconnaissance can be gathered using various techniques:
- WHOIS records
- may reveal information about system owner or IT administrators, including names, email addresses, and phone numbers
- DNS Resource Records
- RRs can reveal technologies and cloud services used by an organization.
- DNS Zone Transfer
- An organization's misconfigured DNS server may allow an attacker to request a copy of the server's zone file, revealing hidden records.
- DNS Brute Force
- Using a common domain world list, an attacker may attempt to resolve all A and CNAME records for a particular domain.
Details obtained through DNS Reconnaissance provide an attacker with the information needed to perform further attacks against specific systems or technologies controlled by their victim.
DNS Reconnaissance can be minimized by limiting the amount of publicly shared information as part of the organization's DNS infrastructure. for example:
- don't allow WHOIS records to contain sensitive information
- understand what information is revealed in your organization's DNS records
- secure DNS configuration to deny zone transfer requests
- monitor for and block brute force attacks against DNS infrastructure.
A subdomain takeover occurs when an attacker gains control over a subdomain of a victim's domain. This usually happens when the organization has created a CNAME record for a subdomain. Still, the CNAME target may not exist or be deprovisioned.
Suppose an Attacker can identify an orphaned CNAME record that they can register (or configure a virtual host for). In that case, they can take control of the traffic being sent to that specific subdomain or the organization without their knowledge.
Detectify identified a 20% increase in subdomain takeover attacks since 2022.
There are 2 primary methods of mitigating Subdomain Takeover attacks:
- Strict DNS Records change controls
- Organizations must have strict controls around how and when DNS records can be changed. when new services are provisioned or old ones decommissioned, their associated DNS records must be promptly updated
- Attack Surface Monitoring
- With many organizations moving to cloud services, Attack surface monitoring is becoming more critical.
- Attack surface monitoring is a service provided to organizations by companies such as Detectify that continuously monitors external digital assets that contain, transmit, or process sensitive data.
Auditing DNS Secure Implementation
Now that we understand some of the threats against and mitigation strategies for DNS, as Security Professionals, we need to be able to review a DNS implementation against industry best practices to ensure our clients are secure.
Two high-quality resources exist that provide us with the information and controls needed to validate an organization's effective strategy and implementation of its DNS technologies. These are:
NIST SP 800-81-2, "Secure Domain Name System (DNS) Deployment Guide," provides extensive guidance on maintaining data integrity, performing source authentication, and configuring DNS deployments to prevent many denial-of-service attacks.
The guide identifies three security concerns:
- The DNS hosting environment
- The DNS transactions themselves
- The security administration of the DNS and DNS Security Extensions (DNSSEC) implementations
CIS DNS Bind Benchmark
The CIS DNS BIND Benchmark includes recommendations and steps for securing a BIND 9 server. Additionally, it discusses possible attacks to illustrate why specific security controls are necessary.
By reviewing a DNS implementation against either or both of these guidelines, we, as security professionals, should be able to provide some level of assurance to our clients that their DNS implementation meets industry best practice and mitigate common DNS threats.