Different DNS answers inside and outside China are not, by themselves, a diagnosis. Name resolution, cache state and whether a website actually works are separate questions. Legitimate service routing can produce different addresses; a domain with an answer can still fail during connection, TLS or application use.
This guide helps site operators preserve useful evidence and choose the next check. It does not use address differences to classify DNS poisoning. For that question, read the result returned by the dedicated check.
1. DNS Resolve and DNS poisoning checks answer different questions
WeaveBit API v2’s DNS Resolve reports resolution status and A records observed from selected check networks. Success means that query obtained a resolution result. It does not establish website availability or complete a DNS poisoning assessment. The dedicated DNS poisoning check returns a separate normal, abnormal or indeterminate classification.
Do not translate “an IP was returned” into “no poisoning,” or “the addresses differ” into a confirmed platform finding. See the public result documentation. For an initial check of one domain, start with the DNS poisoning introduction.
2. Why legitimate services may return different addresses
A website may use CDN, load-balancing or geographic-routing configurations to direct traffic to different endpoints. For example, Cloudflare’s Geo steering documentation describes traffic pools assigned to countries or regions. This illustrates an available routing capability, not a claim that every CDN or domain uses it.
For your own site, review DNS/CDN configuration, CNAME targets, geographic policies and recent changes. Expected answers should follow the deployed service configuration; one overseas query is not a permanent, uniquely correct address. Ask an external provider about its configuration rather than diagnosing from an IP’s geographic label.
3. TTL is not a global propagation countdown
DNS caches records, and TTL describes their cache lifetime. RFC 1034 also explains that distributed DNS does not guarantee simultaneous updates of all copies. A TTL of 300 seconds is therefore not a promise that every user will see the same new address in five minutes.
Distinguish the current record’s TTL, the previous record’s TTL and the provider’s configuration rollout. Lowering TTL now does not retroactively shorten an already-cached old record. DNS caching, browser resource caching and CDN content caching are different layers; refreshing a page does not demonstrate refreshed resolution.
Plan migration TTLs and verification windows with your provider. Do not turn a fixed waiting period into a worldwide completion guarantee.
4. Preserve the baseline before changing settings
Keep enough context to explain later changes:
- The actual hostname and failed URL, distinguishing the main site,
www, API and resource hosts. - Time and time zone, user location, carrier and connection type, and whether the observation came from a device or check node.
- Query method, record type, returned status and addresses; record TTL and resolver when the tool provides them.
- DNS/CDN change times, previous and new configurations, and corresponding browser or application errors.
Capture the first failure on the affected network, then repeat under the same conditions. Do not initially ask everyone to change DNS, restart routers and clear all caches. That can remove the baseline while changing several variables at once.
5. Choose the next check based on the symptom
These are investigation directions, not DNS poisoning classification rules. Address differences and access failures can coexist without this table establishing a causal relationship.
| Observation | Next evidence |
|---|---|
| Different addresses; the service works | Review DNS/CDN routing and changes; preserve a baseline and run a dedicated check if poisoning is the concern |
| An answer exists; connection or secure connection fails | Save the error, run a full check of the actual hostname and ports, and review service logs |
| Resolution returns an error or times out | Check spelling, record configuration and query conditions; preserve the status and repeat on the original network |
A new address appearing does not prove a migration succeeded. An old address appearing does not establish poisoning. The chosen endpoint must also be ready to serve the site’s certificate, origin and application.
6. Use the appropriate check for each question
Enter a bare domain in the free DNS poisoning check and save the result and available result time. A normal result leads to investigating the stages relevant to the symptom; preserve an abnormal result and confirm impact. Do not replace an indeterminate result with “normal” or “blocked.” Repeated refreshes may reuse an existing result rather than create a new observation.
For several domains, regions or carriers, go directly to GFW Full if that matches the incident. A separate DNS check for every target is not required. It combines DNS poisoning, HTTP Host and TLS SNI dimensions. Select relevant networks from current node coverage and follow the full-check guide.
DNS Resolve query settings describe resolution observations, not the dedicated poisoning check’s internal assessment. Integrations should keep methods, inputs and outputs separate according to the public API contract, without converting addresses into their own platform classification.
7. Successful resolution still leaves the application to check
Browser access involves connections, TLS, HTTP, redirects and dependencies. A normal DNS result for the main hostname does not cover login APIs, scripts or images on other hosts. Identify the actual failed request before checking its target.
Align failure times with CDN, proxy and origin logs. A normal GFW Full result is not end-to-end browser acceptance; certificates and user actions still need validation. For failures limited to some networks, use the regional and carrier comparison guide.
8. Make evidence-based changes and verify the original problem
Adjust a record or service setting when evidence shows it does not match the intended configuration. Keep before-and-after settings and a rollback plan. Change one factor at a time and repeat the original network, hostname and user action. If cache clearing is justified, name the layer and label subsequent observations separately.
Conclude with resolution status, access results and coverage: what recovered, where failures remain and where evidence is missing. Different addresses are a clue, not a conclusion. Preserve evidence, understand service routing and caching, and use each check to answer its own question.