How it works
Recursive resolvers, run by ISPs, companies or public services like Google Public DNS, cache answers for as long as the TTL allows. When a resolver asks an authoritative name server, it accepts the first answer that matches the query ID, port and question.
The attacker floods the resolver with forged answers at exactly that moment, hoping to hit the right combination before the real name server replies. The Kaminsky attack, published in 2008, showed that by querying random subdomains an attacker could take over the delegation of an entire domain this way. Resolvers have used random source ports ever since, yet later attacks such as SAD DNS (2020) found ways to defeat that randomness.
Once the forged answer is in the cache, the resolver serves it until the entry expires, and the attacker gets a say in that TTL, limited only by the resolver's maximum. The only reliable fix is DNSSEC: for signed zones, a validating resolver rejects any answer without a valid signature.
Why it matters
Unlike an attack on a local network, a poisoned answer hits every user of that resolver, which at a large ISP means a lot of people at once. They land on a fake website, or their mail servers deliver to the wrong MX, without anyone touching your zone.
That makes it especially nasty for site owners: your own lookups return the right values, your server logs stay quiet, and the redirect only disappears when the entry expires in the affected resolver.
How to prevent it
- Enable DNSSEC for your domains; it is the one defense you control as the domain owner.
- Keep your own resolvers (office network, servers) patched, turn on DNSSEC validation and never expose them as open resolvers.
- Use HTTPS with HSTS, and MTA-STS or DANE for mail, so redirected connections fail on the certificate.
- If you suspect poisoning, compare answers from several public resolvers with the authoritative ones, for example with the free DNS propagation tool.
How DomainWarn detects it
DomainWarn does not check for a poisoned answer in a third-party resolver's cache directly; it is only visible from that resolver's network. Instead, the DNSSEC check verifies the protection that actually works: whether the domain has a DS record, whether the chain validates at a validating resolver, whether signatures expire soon and whether deprecated algorithms are in use.
The DNS check queries the authoritative name servers where possible, so it catches changes to the zone itself, not poisoned copies elsewhere. For a spot check across several public resolvers, use the free DNS propagation tool on the website.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.