DNS poisoning: how to tell if your domain is being hijacked at the ISP

What DNS poisoning actually is

A resolver that's been "poisoned" returns the wrong answer on purpose. Your domain still exists, your authoritative nameservers still work, your hosting is fine — but when someone on a particular ISP asks where your site is, they get pointed somewhere else. Usually that's a regulator's warning page, sometimes just a dead IP, and occasionally NXDOMAIN that makes the browser pretend the domain doesn't exist.

The thing to notice: there's nothing wrong on your side. Which is exactly why traditional uptime monitoring, which tends to run from clean datacenter networks, will happily report everything is green while users in one country have been locked out for days.

Poisoning vs. hijacking vs. spoofing

These get thrown around interchangeably and shouldn't. They have different attackers, different attack surfaces, and different responses.

The one that matters most for blocking discussions is poisoning, because it's the tool of choice for ISP-level censorship. Nothing at your registrar changes. No one is on the user's local network. It's just the resolver doing what it was told.

Signs something is off

Poisoning is designed to be invisible to the domain owner. A few things, though, tend to leak:

• Sudden traffic drops from one country: Analytics shows an obvious cliff for visitors from a single country while everywhere else is normal. That's the shape of an ISP-level block.
• Support tickets saying "I see a warning page": Users in one region describe a government block page; users elsewhere see your real site. Hard to explain any other way.
• Conflicting DNS answers: Authoritative nameservers return the correct IP. ISP resolvers return something different. That disagreement is the smoking gun.
• Weirdly high bounce rate from specific ISPs: When a single ISP's users bounce in under a second, that's often because they never got past the block page.
• NXDOMAIN where it shouldn't exist: Some ISPs prefer NXDOMAIN over warning pages because it's harder to distinguish from a real outage. If your site "doesn't exist" for one country only, that's the tell.

How ISPs use poisoning for blocking

Most state-mandated blocking in the world is some flavor of DNS poisoning. The regulator publishes a list, the ISPs configure their resolvers to lie about it. The variations mostly come down to style:

Transparent proxying is worth calling out because it breaks the first piece of advice users get when they hit a block ("just use Google DNS"). On networks that do this, switching resolvers has no effect at all.

How to detect it

The recipe is always the same: ask DNS from different vantage points, compare the answers, and know what a bad answer looks like in each country. The specific techniques:

1. 1
   Compare resolvers

   Query the ISP resolver and the authoritative nameservers. If the IPs differ, and the ISP resolver is pointing at a known regulator block page, that's a confirmed poisoning event.

2. 2
   Maintain a block-page IP database

   Regulators use a finite set of IPs for their warning pages. Keeping those per-country means you can classify a weird response immediately.

3. 3
   Verify NXDOMAIN against authoritative

   An NXDOMAIN from an ISP resolver is only suspicious once you've confirmed the authoritative nameservers still return a valid record. Otherwise it might be a real domain issue.

4. 4
   Look at TTLs

   Poisoned answers sometimes have clearly abnormal TTLs. Not a smoking gun on its own, but a useful signal in combination with the rest.

5. 5
   DNSSEC where it's deployed

   A signed record that fails validation was tampered with. The catch: most ISPs doing poisoning just strip DNSSEC responses entirely instead of forging them, so DNSSEC-aware resolvers may just see nothing.

How we handle this

domainreach.io runs DNS checks from real ISP connections in 50+ countries. The short version of the pipeline:

Because we're on real ISP networks and not datacenter proxies, we catch things most monitoring tools can't see — including the transparent-proxy flavor, which is invisible unless you're actually on the affected network.