How to Tell If a Domain's DNS Is Poisoned: Differing Regional Resolutions Alone Aren't Conclusive

Use a multi-region DNS lookup tool to check a domain, and you may find that China Telecom Beijing returns one IP, China Mobile Guangdong returns another, and an overseas node returns a third set of addresses. Seeing this, many people conclude outright: “The domain’s DNS has been poisoned.”

That conclusion is usually premature.

Different IPs in different regions are exactly how CDN, GeoDNS, and intelligent routing normally work. Recursive DNS cache duration, query source, carrier routes, EDNS Client Subnet, and IPv4/IPv6 records can also cause different nodes to receive different answers.

To determine whether a domain’s DNS is actually poisoned, you cannot just look at whether the IPs match. You need to answer three more important questions:

• Does the returned result come from the authoritative DNS chain permitted by the domain configuration?

• Can the answers obtained by different resolvers be explained by CDN scheduling, caching, or routing policies?

• Can the anomalous IP serve the expected website with the correct domain, Host, and TLS SNI?

Only after discovering that resolution results have been replaced, forged, or intercepted without authorization—and after ruling out CDN scheduling, caching, configuration errors, and local network issues—is there sufficient basis to classify the problem as DNS poisoning or DNS hijacking.

First, distinguish DNS poisoning, DNS hijacking, and configuration errors

In everyday discussion, “DNS poisoning” is often used to describe all abnormal resolution. For technical troubleshooting, it is better to distinguish among them, because different problems have different points of responsibility and remediation methods.

From the user’s perspective, all these situations can look like “the domain resolves to the wrong IP.” But without first determining which layer the anomaly occurs at, changing the CDN, modifying the origin, or deleting DNS records often does not solve the problem.

Why different multi-region resolution results usually do not prove DNS poisoning

CDNs already return different nodes by region and carrier

CDNs want users to access edge nodes that are closer, better routed, or less loaded, so they may return different IPs based on recursive DNS source, user network, region, and real-time health status.

For example, if Beijing Unicom, Shanghai Telecom, and Guangdong Mobile resolve to three different addresses, as long as those addresses all belong to the CDN service and can return the correct certificate and website content, this is more likely normal scheduling than DNS poisoning.

This is alsothe main reason different regions see different CDN node IPsWhen assessing, check whether the IP, CNAME chain, provider network, and actual HTTP response corroborate one another.

EDNS Client Subnet affects authoritative DNS responses

Some public recursive DNS services include truncated client subnet information in queries, enabling authoritative DNS or CDN scheduling systems to return a node closer to the user.

RFC 7871’s description of EDNS Client Subnetnotes that many authoritative DNS servers return different answers based on the user network location they perceive. Therefore, even when querying two public DNS services from the same computer, different ECS policies can produce different IPs.

Different addresses are not inherently anomalous. What really needs checking is whether those addresses belong to the expected service and whether the different results show a stable, reasonable distribution by region or carrier.

Recursive DNS caches may retain old records that have not yet expired

DNS records have TTLs. After authoritative DNS records are changed, different recursive resolvers will not all update at the same second. One resolver may have just re-queried, while another is still using an unexpired cache, so the two temporarily return different results.

If the website has just migrated CDN, changed CNAME, switched origin, or adjusted routing policies, old and new records coexisting for a period is not unusual. In this case, compare the TTL, SOA serial, and configuration change time; do not immediately conclude poisoning.

The same domain may contain multiple valid records at the same time

Authoritative DNS may return multiple A or AAAA records at once for load balancing, failover, or multi-CDN scheduling. The order of records returned for different queries may also change.

If only the record order differs, or if some IPs are selected from a legitimate address pool each time, this is usually normal behavior. Assess by comparing the address set, not just the first IP.

Which symptoms are more suspicious of DNS anomalies?

The following symptoms are more diagnostically useful than “IPs differ across regions,” but they still require cross-verification:

• The CNAME or IP returned by the local recursive DNS is not in the chain allowed by authoritative DNS;

• Within the same network, ordinary UDP queries and encrypted DNS queries return completely different results over a sustained period;

• The domain resolves to an ad page, notice page, or unknown host unrelated to the business;

• The HTTPS certificate of the returned IP clearly does not match the target domain;

• The returned page content is completely unrelated to the target website;

• Non-existent subdomains all resolve to the same address;

• Querying a domain returns multiple conflicting DNS responses;

• A specified public DNS is used, but the actual response comes from the local gateway or another server;

• A DNSSEC-signed domain fails validation on a validating resolver;

• The anomaly occurs only on a certain router, Wi-Fi network, carrier, or specific network egress.

Among these, certificate mismatches and abnormal page content are valuable supporting evidence. If a suspicious IP still cannot serve the target website while the correct Host and TLS SNI are preserved, continue to determine why it appears in the DNS answer.

Complete inspection sequence for determining whether a domain’s DNS is poisoned

Step 1: Identify the authoritative DNS actually used by the domain

First query the NS records:

dig example.com NS

Then query the IP addresses of the authoritative servers:

dig ns1.example-dns.com A
dig ns1.example-dns.com AAAA

Then query the target record directly from one of the authoritative DNS servers:

dig @203.0.113.53 www.example.com A +norecurse
dig @203.0.113.53 www.example.com AAAA +norecurse
dig @203.0.113.53 www.example.com CNAME +norecurse

In the example,203.0.113.53needs to be replaced with the actual authoritative DNS address.+norecurseThis tells the server to answer directly from its authoritative data rather than perform recursive resolution on your behalf.

According tothe DNS message and resource record mechanisms specified in RFC 1035, when querying, pay attention to ANSWER, AUTHORITY, status code, TTL, and responding server at the same time, instead of simply copying the final IP.

If multiple authoritative DNS servers return different results, it is not necessarily poisoning; it may also be zone resolution or configuration not synchronized. At this point, check the DNS console, routing policies, and SOA serial.

Step 2: Compare local, carrier, and public recursive DNS

dig www.example.com A
dig @1.1.1.1 www.example.com A
dig @8.8.8.8 www.example.com A
dig @223.5.5.5 www.example.com A

The first command uses the recursive DNS currently configured on the system, and the following commands specify different public resolvers. When comparing, record:

• whether the response status is NOERROR, NXDOMAIN, or SERVFAIL;

• whether A, AAAA, or CNAME is returned;

• whether the CNAME chain matches the authoritative DNS configuration;

• whether the response IPs belong to the expected CDN or cloud provider;

• whether the TTL is reasonable;

• which DNS server actually answered the request.

Different IPs returned by public DNS services may still be normal scheduling. More noteworthy is when a resolver returns a CNAME that cannot be explained by the authoritative chain, an error-page IP, or an unrelated network address.

Google Public DNS troubleshooting documentationalso specifically notes that stale caches, differing authoritative server data, CDN ECS configuration, and local network hijacking can all cause “wrong answers,” which should be ruled out item by item based on domain configuration.

Step 3: Compare UDP and TCP query results

DNS typically uses UDP first but also supports TCP. You can test the same resolver separately:

dig @8.8.8.8 www.example.com A
dig @8.8.8.8 www.example.com A +tcp

If UDP consistently returns a suspicious IP while TCP returns the result expected from authoritative DNS, this may indicate response injection, a caching device, or an intermediary on the UDP path.

However, this alone is still not conclusive. Some networks restrict external TCP port 53, and some recursive DNS servers may differ due to caching, ECS, or query paths. Continue to verify with encrypted DNS and actual HTTP access.

Step 4: Use encrypted DNS for comparison

You can query through a public DNS HTTPS interface:

curl -sS \
  -H 'accept: application/dns-json' \
  'https://dns.google/resolve?name=www.example.com&type=A'

DNS over HTTPS encapsulates queries within HTTPS connections, reducing opportunities for local networks to directly read and modify plaintext DNS messages. If ordinary DNS and DoH results conflict over a sustained period, while DoH results match authoritative DNS, focus on checking the local router, carrier recursive DNS, and network path.

However, DoH results may also return different CDN nodes because of query egress location and ECS policy. The key is still not that the IPs must be identical, but whether the answers can be explained by authoritative DNS and CDN scheduling logic.

Step 5: Check the CNAME chain, not just the final IP

dig www.example.com CNAME
dig cdn-target.example.net CNAME
dig cdn-target.example.net A
dig cdn-target.example.net AAAA

After a domain is connected to a CDN, it usually goes through one or more CNAME layers. Even when the final IP changes significantly, the CNAME chain may remain stable and clearly point to a domain controlled by the CDN provider.

If you need to further determine whether multiple response IPs belong to the same service, you can combine this withthe method for identifying response IPs and CDN providers, cross-checking the CNAME, IP network ownership, HTTP response headers, and TLS certificate. Looking only at IP location is usually insufficient to prove a resolution anomaly.

Step 6: Verify each suspicious IP with the correct domain

Do not open the HTTPS IP directly in a browser. This loses the target domain and the correct TLS SNI, and you may get a default certificate or the wrong site.

Use curl to specify the resolution address:

curl --resolve www.example.com:443:203.0.113.10 \
  -sS -D - -o /dev/null \
  https://www.example.com/

This command connects to203.0.113.10while preservingwww.example.comas the request domain and TLS SNI. Check:

• whether the TLS certificate covers the target domain;

• whether the HTTP status code is normal;

• whether the expected response headers are returned;

• whether it redirects to an unrelated domain;

• whether it returns an ad page, block page, or error site.

If multiple different IPs can all return the correct certificate and website content, they are more likely normal CDN nodes. If an IP returns an unrelated certificate and a completely different page, and this cannot be explained by authoritative DNS or the CDN chain, its level of suspicion rises significantly.

Step 7: Check DNSSEC, but do not misread the results

dig @8.8.8.8 www.example.com A +dnssec
dig @1.1.1.1 www.example.com A +dnssec

If the domain has DNSSEC deployed, you can check the RRSIG records and theadflag in the response.DNSSEC validation mechanism defined in RFC 4035can help verify the origin and signature integrity of resource records.

Note:

• The absence of theadflag does not mean DNS poisoning has occurred;

• If the domain has not deployed DNSSEC, there is no verifiable signature in the first place;

• DNSSEC configuration errors can also cause validating resolvers to return SERVFAIL;

• DNSSEC can verify record authenticity, but cannot determine whether a CDN node performs well.

Step 8: Check whether multi-region resolution corresponds to actual access

A command run on a single machine only represents the current network. To determine whether the anomaly is concentrated in a region or carrier, you can useCdnChart multi-region website speed test, focusing on the response IPs, IP locations, status codes, resolution time, connection time, and failed nodes obtained by different test nodes.

CdnChart provides cross-region observational clues here, not an automatic declaration that “the domain has been poisoned.” A more reasonable approach is:

• first identify which response IPs are returned in different regions;

• determine whether these IPs show a reasonable distribution by region or carrier;

• observe whether anomalous IPs are accompanied by HTTP failures or error status codes;

• then verify each one using authoritative DNS, public resolvers, and curl.

If only the IPs differ, but status codes are normal, certificates are correct, and page content is consistent across nodes, this is usually closer to normal CDN scheduling. If a particular carrier consistently resolves to unrelated IPs and access fails, further investigate that network’s recursive DNS and query path.

Which results can support a judgment of “suspected DNS poisoning”?

Five inspection methods that easily lead to misjudgment

Comparing only the final IP without checking the CNAME chain

CDN node IPs can change frequently, but the CNAME chain may still belong to the same provider. Skipping CNAME and provider network ownership makes it easy to mistake normal node scheduling for poisoning.

Treating IP geolocation as absolute evidence

An IP database location may be a registered address, network ownership location, or estimated location, and does not necessarily equal the physical node location. When judgingthe difference between a CDN node address and an origin address, combine ASN, routing, response headers, and actual connection results; do not rely on a city label alone.

Querying public DNS only once

A single query may hit a cache or show only part of the address pool. Keep the time, resolver, TTL, and full answer, and repeat tests on different networks.

Directly accessing the HTTPS IP to judge whether the page is correct

Accessing the IP directly changes the Host and SNI and may return a default certificate or another virtual host. Usecurl --resolveto preserve the original domain.

Concluding that DNS is poisoned as soon as SERVFAIL appears

SERVFAIL can also come from DNSSEC validation failure, unreachable authoritative DNS, delegation errors, oversized responses, or temporary resolver failures. Continue querying authoritative servers and other validating resolvers.

What should be done after a DNS anomaly is found?

If the anomaly comes from domain configuration, first check whether the authoritative DNS records, CNAME, routing policies, TTL, DNSSEC, and multiple authoritative servers are synchronized.

If the problem occurs only on a single router or LAN, check the router DNS settings, proxy software, malware, public Wi-Fi login page, and endpoint cache. Do not change the website origin configuration before the cause is confirmed.

If a recursive DNS server continues to return wrong answers, you can save the completedigoutput, query time, network carrier, anomalous IPs, and normal comparison results, then report them to the DNS service provider or network carrier.

If on-path response injection is suspected, retain UDP, TCP, and DoH query results as well as necessary packet capture evidence. Only when a clear anomalous relationship between query and response is observed is it appropriate to further determine where responsibility lies.

If the website is already using a CDN, also confirm whether the anomalous address is truly an unrelated IP or a legitimate edge node that has not yet been cataloged or is inaccurately geolocated. CdnChart can help collect multi-region response IPs and access results, but the final conclusion should still be supported by authoritative DNS data, CDN configuration, TLS certificates, HTTP content, and network evidence.

Frequently asked questions

Does resolving to different IPs in different provinces mean DNS is poisoned?

No. CDNs, GeoDNS, and intelligent resolution already return different IPs based on region, carrier, or recursive DNS. As long as these addresses belong to the expected service and can return the correct certificate and website content, this is usually normal scheduling.

Public DNS and carrier DNS return different results. Which one should I trust?

Do not decide which is correct based only on the resolver’s name. First query authoritative DNS, then check both sides’ CNAME chains, TTLs, ECS policies, and actual HTTP responses. Public DNS may also return different CDN nodes because of caching or egress location.

If access is restored after changing the local DNS, does that prove the carrier DNS is poisoned?

It only shows that the problem may be related to the original recursive DNS or its network path; it still does not directly prove poisoning. The original resolver may have cached old records, experienced a DNSSEC validation failure, or had a temporary anomaly. Save the complete query results before and after the change for further verification.

Is it normal for a domain to resolve to multiple overseas IPs?

Judge based on the business and CDN architecture. It may be normal when using Anycast, a global CDN, or overseas acceleration. If the business has only configured a fixed origin but completely unrelated overseas addresses appear, check authoritative records, account security, and the local resolution path.

Can DNSSEC completely prevent DNS poisoning?

DNSSEC can help verify the origin and integrity of DNS records, but only if the domain is correctly deployed, the resolver performs validation, and the client can correctly handle the validation result. It cannot solve all blocking, routing, and application-layer failures, nor can it guarantee CDN node speed.

Can CdnChart directly detect and confirm DNS poisoning?

CdnChart can display response IPs, resolution time, status codes, and access results across regions and carriers, making it suitable for identifying anomalous distributions and narrowing the troubleshooting scope. However, DNS poisoning requires cross-verification using authoritative DNS, recursive resolvers, DNSSEC, TLS certificates, HTTP content, and, where necessary, network packet capture. You cannot draw a conclusion based solely on multi-region IP differences from one platform.