> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/diagnose/is-my-dns-hijacked.md).
# Is My DNS Hijacked or Polluted?
Every time you open a site, something translates the name into an address. If that answer is changed on the way, you end up somewhere you did not ask for — and the browser shows no obvious sign.
{% hint style="success" %}
**Quick answer.** Look up the same domain through several independent resolvers using **Advanced Tools → DNS Resolution**. Well-known, stable domains should get the same answer from everyone. When your ISP's resolver returns something different from every public resolver, that is the red flag.
{% endhint %}
## What "hijacked" and "polluted" mean
Both terms describe the same outcome — a wrong answer to a name lookup — from two different sources.
* **Hijacking** usually means your resolver, your router, or malware on your device deliberately returns an address of its own choosing. Often for advertising, search redirection, or a captive portal.
* **Pollution** (or poisoning) usually means something on the network path injects forged answers before the real one arrives. This is how national-level filtering commonly works.
You do not need to tell them apart to detect either. The test is the same: **compare independent sources.**
Background: [How DNS Works](/knowledge-base/concepts/how-dns-works.md)
## Symptoms worth investigating
| What you notice | How suspicious |
| ------------------------------------------------------------------- | ------------------------------------------------------ |
| Mistyped domains land on a search or ad page run by your ISP | Mild — common ISP behaviour, but it is still tampering |
| A site you know loads a completely unrelated page full of ads | High |
| Certificate warnings on sites that normally work | High — the address you reached is not the real server |
| One domain resolves to an odd address while everything else is fine | High |
| A site works over a VPN but not without one | Medium — could be DNS, could be blocking |
| Ads appear injected into pages that never had them | High |
{% hint style="warning" %}
**Never click through a certificate warning to reach a site you care about.** That warning is the one signal that survives DNS tampering. It means the server answering you cannot prove it is the real one.
{% endhint %}
## The comparison test
{% stepper %}
{% step %}
#### Pick a stable domain
Choose something big and boring whose addresses do not change every few minutes. A large, well-known site works well. Avoid testing with a heavily CDN-distributed service first — those legitimately return different addresses to different resolvers, which muddies the picture.
{% endstep %}
{% step %}
#### Run it through DNS Resolution
Open **Advanced Tools → DNS Resolution**, enter the domain, choose record type **A**, and run it.
MyIP queries a set of well-known providers around the world — some over plain DNS, some over encrypted DoH, marked with a lock in the results table — and shows every answer side by side.
{% endstep %}
{% step %}
#### Read the pattern, not the individual rows
| Pattern | Verdict |
| ----------------------------------------------------------------------------------------- | --------------------------------------------- |
| Everyone returns the same address | Clean |
| Answers differ slightly, all within the same provider's range | Normal CDN behaviour, not tampering |
| Most resolvers agree; **one region's resolvers return something else** | Interference along that region's network path |
| A resolver returns a private address (`10.x`, `192.168.x`, `127.0.0.1`) for a public site | Hijacking, almost certainly |
| A resolver returns an address in a completely unrelated country or network | Strong sign of tampering |
{% hint style="info" %}
The tool deliberately includes some resolvers based in China, whose answers for certain domains are commonly affected by filtering. Seeing them disagree with the rest of the world for a blocked domain is expected, not a bug — it is the comparison working.
{% endhint %}
{% endstep %}
{% step %}
#### Compare with your own resolver
The tool queries public providers, not the resolver your device actually uses. To include yours, check what your machine returns for the same domain:
{% tabs %}
{% tab title="macOS / Linux" %}
```bash
dig example.com +short
```
{% endtab %}
{% tab title="Windows" %}
```
nslookup example.com
```
{% endtab %}
{% endtabs %}
If your own answer matches the public consensus, your resolver is behaving. If it stands alone, that is your culprit.
{% endstep %}
{% endstepper %}
## Confirm with encrypted DNS
Plain DNS travels unencrypted and unauthenticated, which is exactly what makes tampering easy. Encrypted DNS — DNS over HTTPS (DoH) or DNS over TLS (DoT) — wraps the query so nothing on the path can read or rewrite it.
This gives you a clean second opinion:
1. Turn on encrypted DNS in your browser. Most modern browsers have a "Secure DNS" or "DNS over HTTPS" setting.
2. Reload the site that was misbehaving.
3. If it now works correctly, the answer was being changed somewhere between you and the resolver.
In MyIP's DNS Resolution results, rows marked **DoH** are already answered over an encrypted channel. When the DoH rows agree with each other and the plain-DNS rows do not, you have your evidence.
On the official site, **Advanced Tools → In-depth DNS Leak Test** goes further: it captures the resolvers actually serving you and shows whether DNSSEC signatures were requested and validated. A resolver asking to skip validation is worth a second look. This tool is only available on ipcheck.ing.
## What switching resolver does and does not fix
Switching to a public resolver is the usual first move. Be clear about what it buys you.
| It fixes | It does not fix |
| ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| A misbehaving or ad-injecting ISP resolver | Injected forged answers on the network path — those arrive regardless of which resolver you asked, unless the query is encrypted |
| A router quietly overriding your DNS settings — if you set it on the device instead | Blocking that happens after DNS, at the IP or TLS level |
| Wrong answers cached by your ISP | Malware on your own machine, which can override DNS locally |
| Mistyped-domain redirection to ad pages | A site that is genuinely down |
{% hint style="info" %}
If plain DNS to a public resolver still returns the wrong answer, use **encrypted** DNS. Encryption is what defeats on-path injection; changing which resolver you ask is not enough on its own.
{% endhint %}
How do I check my router is not the problem?
Set a public resolver directly on one device, bypassing whatever the router hands out, then repeat the lookup. If that device is now correct while others are still wrong, the router was the source. Some routers intercept all DNS traffic regardless of client settings; in that case only encrypted DNS will get past it.
Different answers for a big service — is that really fine?
Usually yes. Content delivery networks answer with whichever edge server is nearest to whoever asked, so a resolver in Frankfurt and a resolver in Singapore legitimately return different addresses. The tell is whether the addresses still belong to the same operator. Look them up with the search button, or with [Whois Search](/knowledge-base/lookup-privacy/whois-search.md), and check the ASN.
Could malware on my computer be doing this?
Yes. Local malware can change your DNS settings, edit the hosts file, or install a root certificate that hides the certificate warnings you would otherwise see. If the tampering follows your laptop onto a different network, suspect the machine rather than the network, and run a reputable malware scan. The [Security Checklist](/knowledge-base/lookup-privacy/security-checklist.md) covers the wider hygiene.
## Still stuck?
* [DNS Resolver](/knowledge-base/lookup-privacy/dns-resolver.md) — the tool in full
* [Can't Open a Website?](/knowledge-base/diagnose/cant-open-a-website.md) — the wider decision tree
* [DNS Leak Test](/knowledge-base/connection-tools/dns-leak-test.md) — which resolvers you are actually using
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.ipcheck.ing/knowledge-base/diagnose/is-my-dns-hijacked.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.