DNS Spoofing

In both settings the result is the same: the victim believes a name maps to the attacker's address and connects there.

What the attacker gains, and the same crucial limit

Once the victim connects to the attacker's server believing it is the real one, the attacker can present a fake version of the site, to capture credentials, serve malicious content, or relay to the real site while reading the traffic.

But the same limit as ARP poisoning applies, and it is the reason the block converges on one conclusion:

• Sending the victim to the wrong server does not give the attacker the real server's certificate. When the victim's browser connects to what it thinks is the bank, it checks the certificate presented against the name it asked for, and the attacker cannot present a valid certificate for the real name, because they do not hold the real site's private key and no trusted authority will issue them one for a name they do not control. So the browser raises a certificate warning, and a user who heeds it is protected.
• For unencrypted connections, or where a user clicks through the warning, the redirection succeeds fully.

So DNS spoofing, like ARP poisoning, is defeated in practice by encryption with certificate checking: the redirection works, but the impersonation fails at the certificate. The attacker can send you to their server; they cannot make their server prove it is the bank.

The countermeasures

Three layers, the first two from the DNS-hardening chapter and the third the block's universal control.

DNSSEC signs DNS records cryptographically, so that a resolver which validates can detect a forged answer: a spoofed record lacks a valid signature from the zone's owner and is rejected. It addresses the authentication gap at its root, for the integrity of DNS answers, and is the direct defence against cache poisoning. Its limits, from the hardening chapter, are that it must be deployed by the zone owner and validated by the resolver, neither of which is universal, and that it protects integrity, not confidentiality.

Encrypted DNS (DNS over TLS or over HTTPS) protects the query and answer in transit, so a local attacker cannot see the query or inject a forged reply on the path, which defeats the local man-in-the-middle form of the attack. It complements DNSSEC: DNSSEC authenticates the data, encrypted DNS protects the channel.

Transport encryption with certificate checking, the block's decisive control. Even if a victim is given a false address, the connection to the attacker's server fails the certificate check for the real name, so the impersonation is caught. This is why the countermeasures chapter concludes that encrypting end to end and heeding certificate warnings is the defence that survives any redirection.

Supporting measures: resolvers that randomise source ports and transaction identifiers (raising the difficulty of the local injection), and, for the local-network form, the ARP-poisoning countermeasures of the previous chapter, since a local DNS spoof usually requires a man-in-the-middle position that Dynamic ARP Inspection would prevent.

A worked example, run as a defender

An assessor evaluates a client's exposure to DNS-based redirection, reasoning from configuration.

• Internal services use TLS with the organisation's own certificate authority, so a victim redirected to a fake internal server would receive a certificate that fails the check for the real name, and the browser would warn. The exposure to impersonation is therefore small for these services.
• The organisation's resolvers do not use DNSSEC validation and do not use encrypted DNS. Finding: cache poisoning and local injection are not prevented at the DNS layer, though the certificate check limits the impact.
• One internal tool is accessed over plain HTTP. Serious finding: a successful DNS spoof to this tool would fully succeed, since there is no certificate to fail.
• Users have historically been trained to click through certificate warnings for a legacy self-signed service. Finding, and an important one: this habit discards the very control that defeats impersonation, so it must be corrected and the legacy service given a proper certificate.

Recommendations: enable DNSSEC validation on the resolvers and consider encrypted DNS (close the DNS-layer gap); move the plain-HTTP tool to HTTPS (remove the one service with no certificate defence); fix the legacy service's certificate and retrain users never to click through warnings (restore the decisive control); and ensure the ARP-poisoning countermeasures are in place, since a local DNS spoof usually needs that position. The last recommendation is the one users least expect: the habit of dismissing certificate warnings is itself a serious weakness, because it defeats the control the whole block relies on.

What beginners get wrong

• Thinking DNS spoofing lets the attacker impersonate any site fully. It sends the victim to the attacker's server, but the attacker cannot present a valid certificate for the real name, so an encrypted site's browser raises a warning.
• Confusing the two forms. Local injection targets one victim on the path; cache poisoning corrupts a resolver and affects all its users until the time to live expires.
• Believing DNSSEC encrypts DNS. It authenticates records (integrity) and does not provide confidentiality; encrypted DNS is the separate control for the channel.
• Overlooking the certificate warning as the key defence. It is what defeats impersonation; training users to click through it discards the protection.
• Forgetting the time-to-live consequence. A poisoned cache entry is served for its full duration, so the harm of a cache poisoning is multiplied by the number of the resolver's users and the length of the time to live.
• Treating the local form as independent of ARP. A local DNS spoof usually requires a man-in-the-middle position, so the ARP-poisoning countermeasures also apply.

Quick revision

• DNS spoofing gives a false name-to-address answer, so the victim connects to the attacker's server believing it is the real one. It exploits the DNS's lack of authentication (a client accepts the first plausible reply).
• Two forms: local injection (answer a victim's query on the path, one victim) and cache poisoning (corrupt a resolver, all its users, for the entry's time to live). Modern resolvers randomise source port and transaction identifier to resist injection.
• Same crucial limit as ARP poisoning: redirection succeeds, but the attacker cannot present a valid certificate for the real name, so an encrypted site's certificate check fails and the browser warns; unencrypted connections, or clicked-through warnings, are fully exposed.
• Countermeasures: DNSSEC (signs records, defeats cache poisoning, integrity not confidentiality), encrypted DNS (protects the channel, defeats local injection), and decisively transport encryption with certificate checking; plus resolver randomisation and the ARP-poisoning controls for the local form.

Test yourself

1. What does DNS spoofing achieve, and which protocol property does it exploit?

It causes a victim to receive a false name-to-address mapping, so that connecting to a name sends them to an address the attacker chose, typically the attacker's own server presenting a fake version of the intended site. It exploits the absence of authentication in the base DNS protocol, under which a client accepts the first plausible reply matching the expected source, port and transaction identifier, without verifying its authenticity.

1. Distinguish the local-injection and cache-poisoning forms of the attack.

In local injection the attacker, usually already in a man-in-the-middle position, answers a specific victim's DNS queries with forged replies that arrive before the real answer, affecting that one victim. In cache poisoning the attacker gets a resolver to accept and cache a false mapping, which is then served to every user of that resolver until the entry's time to live expires, affecting many victims from one success.

1. Why does DNS spoofing fail against an encrypted site even when the redirection succeeds?

Because sending the victim to the attacker's server does not give the attacker a valid certificate for the real site's name; when the victim's browser connects, it checks the presented certificate against the name it asked for, and the attacker cannot present one that a trusted authority has issued for a name they do not control, so the browser raises a certificate warning and a user who heeds it is protected.

1. What do DNSSEC and encrypted DNS each defend against, and why are both needed?

DNSSEC cryptographically signs DNS records so a validating resolver can reject forged answers, defending the integrity of the data and particularly against cache poisoning; it does not provide confidentiality. Encrypted DNS protects the query and answer in transit, so a local attacker cannot read or inject on the path, defending against the local-injection form. They are complementary: one authenticates the data, the other protects the channel.

1. Why is training users to click through certificate warnings described as a serious weakness in this context?

Because the certificate check is the control that defeats impersonation after a successful redirection, whether by DNS spoofing or ARP poisoning: it is what catches the attacker's server failing to prove it is the real site. Habitually dismissing the warning discards that protection, so a user conditioned to click through will connect to the attacker's fake server despite the browser having correctly detected the impersonation.