In one sentence: DNS spoofing tricks a computer into believing a forged answer about where a website or mail server lives, so people are sent to the attacker’s address instead of the real one.
What it is
The Domain Name System (DNS) turns names into addresses. Before a browser can load a website it asks a resolver, a server that looks up the answer, such as one run by your provider or your office.
DNS spoofing means getting that resolver, or the user’s device, to accept a forged answer. If the forged answer is stored (cached), everyone who uses that resolver is affected until it expires. That is why it is also called cache poisoning.
RFC 3833 notes that DNS usually sends a whole query or response in a single unsigned, unencrypted UDP packet, which makes these attacks easier.
How it works
- A resolver sends a question to the authoritative server for a domain and waits for the reply.
- The reply is matched to the question by details such as the query ID, the names, and the port. RFC 3833 says the ID is only a 16-bit field and that the combination of ID and client port gives too few possibilities to resist a brute force search, particularly when they can be predicted.
- The attacker sends forged replies that match, and one arrives before the real one.
- The resolver accepts it and stores it. Users asking for the name now receive the attacker’s address.
- The attacker can host a lookalike site to collect passwords, or intercept traffic. RFC 3833 describes the result as the attacker being able to tell the resolver whatever it wants it to believe.
Who it affects and how badly
- Sole trader to 10 staff: you rely on your provider’s resolver and an unprotected website could be copied. Worst case: customers log in to a fake version of your site.
- 10 to 50 staff: accountancy, legal and estate agency firms whose staff use online banking and client portals.
- 50 to 250 staff: MSPs and councils that run their own resolvers carry the risk for all their users.
- Regulated businesses (fintech, insurance, telecoms): a poisoned resolver can redirect many customers at once.
Real examples
- CVE-2008-1447. The US National Vulnerability Database (NVD) records that the DNS protocol as implemented in BIND 8 and 9 before specific versions, Microsoft DNS in several Windows versions and other implementations allowed remote attackers to spoof DNS traffic through a birthday attack that used in-bailiwick referrals to poison the cache of recursive resolvers. The cause was insufficient randomness in DNS transaction IDs and source ports. It was published on 8 July 2008.
How to detect it
- Compare answers for the same name from two different resolvers. A mismatch needs explaining.
- Treat browser certificate warnings on a site you know as a red flag, and train staff not to click through.
- Review resolver logs for answers that suddenly change for important names.
- Check that your router and devices still point to the resolvers you chose.
How to fix or prevent it
- Keep resolver software updated, which is what closed CVE-2008-1447.
- Use resolvers that follow RFC 5452: match every response to the query’s addresses, ports, ID, name and type, and use an unpredictable source port.
- Turn on DNSSEC validation on resolvers, and sign your own domains. RFC 4033 says DNSSEC adds data origin authentication and data integrity.
- Use HTTPS on every site. The certificate lets the browser see that the destination is wrong.
- Limit which devices may query your resolver, and keep it on the internal network.
- Protect router and DNS admin accounts with strong passwords and MFA.
Related terms
Frequently asked questions
What is the difference between DNS spoofing and DNS cache poisoning?
Spoofing is the forged answer. Cache poisoning is when a resolver stores that forged answer so that it is served to many users.
Does HTTPS stop DNS spoofing?
It does not stop the forged answer, but the browser checks the site’s certificate and warns if the destination is wrong.
What does DNSSEC add?
RFC 4033 says it adds data origin authentication and data integrity to DNS.
Sources
- RFC 3833, Threat Analysis of the Domain Name System: https://www.rfc-editor.org/rfc/rfc3833.txt
- RFC 5452, Measures for Making DNS More Resilient against Forged Answers: https://www.rfc-editor.org/rfc/rfc5452.txt
- RFC 4033, DNS Security Introduction and Requirements: https://www.rfc-editor.org/rfc/rfc4033.txt
- NVD record for CVE-2008-1447: https://nvd.nist.gov/vuln/detail/CVE-2008-1447
How Wolfcore helps
A Wolfcore penetration test finds this the way an attacker would, by hand, not with a scanner. Start with the free web vulnerability scan.