DNS spoofing, or DNS cache poisoning, is a type of phishing and cyber attack where false Domain Name System (DNS) information is introduced into a DNS resolver's cache. This causes DNS queries to return an incorrect response, which commonly redirects users from a legitimate website to a malicious website designed to steal sensitive information or install malware.
There are a number of reasons why DNS spoofing is possible, but the principle problem is DNS was built in the 1980s when the Internet was much smaller and security was not a primary concern. As such, there is no in-built way for DNS resolvers to verify the validity of the data they store, and incorrect DNS information can remain until the time to live (TTL) expires or is manually updated.
Before we dive into the underlying mechanics of DNS spoofing, as well as how to prevent it, it's important to get a deeper understanding of how the DNS and DNS resolvers work.
What is the Domain Name System (DNS)?
The Domain Name System (DNS) is a hierarchical and decentralized naming system for computers, services, and other resources that connect to the Internet. In short, it assigns and maps human-readable domains (such as mac.com) to their underlying IP addresses that machines use to communicate. DNS also defines the DNS protocol, which is a specification of data structures and data exchanges used in the DNS.
In practice, the DNS delegates this responsibility to the authoritative nameservers of each domain, creating a distributed, fault-tolerant system that isn't centrally hosted.
The Internet as you know it depends on the DNS functioning correctly. Every web page, email sent, and picture received relies on DNS to translate its human-friendly domain name to an IP address used by servers, routers, and other networked devices.
DNS records are also used to configure email security settings. See our full guide on email security for more information.
What Do DNS Resolvers Do?
When you type in a domain, such as example.com, your web browser will use your operating systems stub resolver to translate the site's domain name into an IP address. If the stub resolver doesn't know the translation, it will relay the request for DNS data to more complicated recursive resolvers, which are often operated by Internet service providers (ISPs), governments, and organizations such as Google, OpenDNS, and Quad9.
Once the recursive resolver has your request, it then sends its own DNS requests to multiple authoritative name servers until it can find a definitive answer.
Domain name servers are the Internet's equivalent to a phone book, maintaining a directory of domain names and translating them to IP addresses, just as a regular phone book translates names to phone numbers.
Some organizations even run their own, but most will outsource this function to a third-party like a registrar, Internet service provider or web hosting company.
How Does DNS Caching Work?
To improve performance, the stub resolver and recursive resolvers will cache (remember) the domain name to IP address translation so that next time you ask to go the website it doesn't need to query the nameservers for a certain amount of time known as the time to live (TTL). When the TTL expires, the process is repeated.
In general, this is a good thing as it saves time and speeds up the Internet. However, when successful DNS attacks change DNS settings and provide a DNS resolver with an incorrect IP address the traffic can go to the wrong place until the TTL expires or the cached information is manually corrected.
When a resolver receives false information, it is known as a DNS cache poisoning attack and the resolver is said to have a poisoned DNS cache.
In this type of attack, the resolver may return an incorrect IP address diverting traffic from the real website to a fake website.
How Do Attackers Poison DNS Caches?
DNS poisoning or DNS spoofing attacks work by impersonating DNS nameservers, making a request to a DNS resolver, and then forging the reply when the DNS resolver queries a nameserver.
This is possible because DNS uses UDP, an unencrypted protocol, which makes it easy to intercept traffic with spoofing and DNS servers do not validate the IP addresses that they are directing traffic to.
There are two common methods for poisoning DNS caches:
- Man in the middle attack: The interception of communication between users and a DNS server in order to route users to a different or malicious IP address. In this situation, the attacker sits between the computer's stub resolver and the recursive resolver, sending back a fake DNS result. Read our full guide on man in the middle attacks for more information.
- DNS server compromise: This type of attack occurs when an attacker gains direct access to the DNS server of a domain, generally through spear phishing or whaling, and updates the DNS entries to point to a malicious website. This type of attack is also known as DNS hijacking.
The reason this works is that unlike TCP, which relies on both communicating parties performing a 'handshake' to initiate communication and verify the identity of devices, DNS requests and response rely on UDP or User Datagram Protocol.
With UDP there is no guarantee that a connection is open, that the recipient is ready to receive, or that the sender is who they say they are. This leaves UDP communications vulnerable to MITM attacks, an attacker can send a message via UDP pretending that it is a legitimate nameserver by forging header data.
If the receiving DNS resolver accepts the fake response and caches, which can happen as there is no way to verify if the information is accurate and comes from a legitimate source.
With that said, DNS spoofing attacks are not easy to pull off as the DNS resolver does actually query the authoritative nameserver giving attackers only a few milliseconds to fake the response before the real response arrives.
When are DNS Spoofing Attacks Successful?
For a DNS spoofing attack to be successful, attackers either need to know or guess:
- Which DNS queries are not cached by the targeted DNS resolver, so that the resolver will query the authoritative nameserver
- What port the DNS resolver uses, which was easy in the past but has since become much more difficult as DNS resolvers rotate their open ports to mitigate DNS spoofing
- The request ID number
- Which authoritative nameserver the DNS resolver will query
Alternatively, attackers could gain access to the DNS resolver in another way such as by gaining physical access or operating a malicious resolver. Some government, such as China and its Great Firewall, intentionally spoof DNS caches to censor what their citizens can access through the Internet.
Once an attacker has successfully launched a DNS spoofing attack, DNS requests often result in users being sent to a compromised or altered web server or web page that resembles the expected result. This can result in an extremely hard to detect phishing scam where users log in to what they believe to the real website, giving the attacker the opportunity to steal login credentials, credit card numbers, and other sensitive data like PII and PHI depending on the website.
Furthermore, these malicious websites are often used to install computer worms, ransomware, and spyware on the user’s computer, giving the perpetrator long-term access.
How to Mitigate DNS Spoofing
The Domain Name System Security Extensions (DNSSEC or DNS Security Extensions) is a set of Internet Engineering Task Force (IETF) specifications that are designed to secure certain kinds of information provided by the DNS. DNSSEC provides DNS resolvers origin authentication of DNS data, authenticated denial of existence and data integrity but not availability or confidentiality.
Much like TLS/SSL, DNSSEC uses public-key cryptography to verify and authenticate DNS data.
When DNSSEC is used, each answer to a DNS request contains an RRSIG DNS record, in addition to the record type that was requested. The RRSIG record is a digital signature of the requested DNS data. The digital signature is verified by locating the correct public key that is found in the DNSKEY. The NSEC and NSEC3 records are used to provide cryptographic evidence of the non-existence of any request. This is also known as authenticated denial of existence.
The delegation signer (DS) is used in the authentication of DNSKEYs by using what is called a chain of trust. NSEC and NSEC3 also serve the purpose of providing robust resistance against spoofing.
The chain of trust starts with a set of verified public keys for the DNS root zone which is the trusted third-party. Domain owners generate their own public key/private key pair and upload them using their DNS control panel at their domain-name registrar, which in term pushes the keys via secDNS to the zone operator (for example Verisign for the com zone) who signs and publishes them in the DNS.
This prevents resolvers from caching forged or manipulated DNS data and prevents cache poisoning.
In short, DNSSEC provides two security features to DNS:
- Data origin authentication: Allows a resolver to cryptographically verify data came from the zone requested.
- Data integrity protection: Allows a resolver to know that the data hasn't been modified in transit and was originally signed by the zone owner's private key.
These two security features all any recursive resolver to look up data in the zone and retrieve the zone's public key which is then used to validate the authenticity of provided DNS data. Resolvers then confirm the digital signature received matches what they expect and return it to the end-user. If the signature is not valid, the resolver assumes a cyber attack, discards the data and returns an error.
While the primary concern of DNSSEC is to prevent the cyber threat of DNS spoofing, resulting in users being directed to the wrong place, DNSSEC provides the additional benefit of protecting text records (TXT) and mail records (MX). DNSSEC has also been used to bootstrap other cyber security systems that publish cryptographic certificates stored in DNS such as Certificate records, SSH fingerprints, IPSec public keys and TLS Trust Anchors.
That said, DNSSEC, unlike SSL certificates, does not provide confidentiality of data. DNSSEC responses are authenticated but not encrypted. Nor does DNSSEC protect against cyber attacks like distributed denial of service attacks (DDoS attacks).
DNSSEC also has a number of potential downsides including:
- Lack of data confidentiality: While DNSSEC authenticates, it does. not encode DNS responses. This means that perpetrators are still able to listen in on traffic and use this data for more sophisticated attacks, this is why SSL certificates are such an important part of Internet security.
- Deployment complexity: DNSSEC is easily misconfigured which can cause servers to lose its security benefits or even deny access to the website altogether.
- No widespread adoption: While DNSSEC was published in 2005, it has not yet become mainstream which leaves any DNS records vulnerable to attacks.
Read our complete guide on DNSSEC here.
Beyond DNSSEC there are other ways you can prevent DNS spoofing:
- Active monitoring: DNS data should be continuously monitored for changes, such as the appearance of a new external host, that could be an indicator of compromise.
- Patching: Like anything, DNS servers and DNS software can be vulnerable to exploits and zero-day vulnerabilities. Ensure whoever is hosting your DNS records is meticulous about vulnerability management and attack surface management.
- DNS updates: Newer versions of DNS use port randomization and cryptographically secure transaction IDs to prevent against DNS attackers, ensure your servers are up-to-date.
- Password policies: Ensure that you are using strong passwords and ideally two-factor authentication for the account that manages your DNS records. And don't forget about changing default passwords on network equipment, such as routers, which can put every device and user in danger if compromised. Read our guides on password security and network security for more information.
- Invest in cybersecurity awareness training: Remember that many DNS spoofing attacks are either the result of, or aim to initiate, some sort of phishing attack. Educate your staff about what to look for in phishing campaigns.
