How to Test GeoDNS Consistency Across Proxy Markets

A proxy can provide the requested country while DNS still sends the request toward infrastructure selected for another region. The result may be extra latency, a different CDN edge, a different catalog, or inconsistent failure behavior. This is common when the client resolves a hostname locally, a SOCKS client switches between local and remote name resolution, or a shared recursive resolver represents a geography different from the proxy exit.

GeoDNS testing is not about forcing every market to receive the same address. Regional differences may be intentional. The goal is to prove that each resolution path is predictable, appropriate for the requested market, and stable for the workload's required window.

Only test domains, proxy capacity and endpoints you are authorized to use.

Separate the four locations

Record four independent locations for every sample:

1. Client location: where the application and local resolver run.
2. Recursive resolver location: the network that asks the authoritative server.
3. Proxy exit location: the public egress observed by the destination.
4. Serving edge location: the CDN or origin address returned by DNS and actually reached.

These values can differ without any component being defective. Authoritative DNS may tailor answers to the recursive resolver, and EDNS Client Subnet may provide a partial network hint. Network topology is also not the same as geographic distance.

Use the residential proxy location validation guide to establish the exit market separately from DNS behavior.

Define the resolution modes

Create distinct cohorts rather than mixing client defaults:

• Local resolution: the client resolves the hostname, then asks the proxy to connect to the resulting address.
• Proxy-side resolution: the client passes the hostname to the proxy, which resolves it from its own path.
• Managed resolver: the client deliberately uses a specified recursive or encrypted DNS service.
• Application/browser default: the runtime may use its own DNS cache, secure DNS setting or connection pool.

For curl-style SOCKS testing, socks5:// and socks5h:// are not equivalent: the latter asks the SOCKS proxy to resolve the hostname. Confirm the effective mode in the client library instead of inferring it from a provider label.

Before testing regional answers, run the proxy DNS leak validation so an unexpected local query is not mistaken for a GeoDNS decision.

Build a controlled test matrix

Choose several authorized hostnames with documented or observable regional delivery. Include one stable control hostname that should not vary. Test at least two proxy markets and two resolution modes.

Keep constant:

• hostname, record type and request path;
• proxy provider, plan and session policy;
• client version and DNS configuration;
• test concurrency and retry policy;
• observation window.

Vary only one factor at a time: market, resolver, local versus remote resolution, IPv4 versus IPv6, or fresh versus warm cache.

Capture DNS evidence correctly

For each query, save:

• UTC timestamp, query name and A/AAAA record type;
• resolution mode and recursive resolver identity when visible;
• complete answer set, canonical names and TTLs;
• response code and DNSSEC status if available;
• proxy exit country, region and ASN class;
• selected destination address, connect time and TLS server name;
• HTTP status and a bounded business-output signature.

Do not record proxy credentials, full cookies or personal data. Hash large response samples if the content itself does not need to be retained.

Control caches and TTLs

A clean comparison requires separate cold and warm runs.

1. Start a fresh client or browser context.
2. clear only the test resolver and application caches you control;
3. issue one query and record the answer plus TTL;
4. repeat inside the TTL window without forcing refresh;
5. repeat after TTL expiry;
6. move to the next proxy market with a new session.

Do not repeatedly flush public resolvers or send high-rate queries. A zero or very short TTL is not permission to stress authoritative infrastructure.

Use the proxy DNS TTL failover test when the buying question is specifically about recovery after an address change.

Compare answers as sets

CDNs often return multiple valid addresses in changing order. Compare normalized sets rather than raw line order. Track:

• exact set equality;
• address-family equality;
• network prefix and ASN overlap;
• canonical-name chain;
• TTL range;
• reached edge and business outcome.

Two markets returning different addresses can be correct. Two markets returning the same anycast address can also be correct. The finding becomes actionable when the answer produces the wrong market outcome, excessive latency, an unreachable address family or unstable behavior outside the documented policy.

Detect false comparisons

Exclude these common confounders:

• the browser reused an existing connection and performed no new DNS query;
• the client sent an IP literal while preserving a hostname in TLS or HTTP;
• a service worker or application cache returned content without a network fetch;
• NO_PROXY bypassed the proxy for one hostname;
• IPv6 was preferred in one cohort and unavailable in another;
• cookies, language headers or account settings overrode IP-based localization;
• retries crossed TTL boundaries or switched exits.

Close connection pools between cold cohorts and attach a unique, non-sensitive request marker to correlate DNS, connection and response evidence.

Use acceptance thresholds

Define thresholds by business requirement. A practical report includes:

• correct-market business outcome rate;
• DNS success rate by market and record type;
• p50 and p95 resolution plus connection time;
• unexpected local-resolution rate;
• stale-answer rate after TTL expiry;
• IPv4/IPv6 reachability gap;
• answer-set churn outside expected TTL boundaries;
• cost per valid completed request.

An example market-sensitive acceptance rule could require zero local DNS queries in remote-resolution mode, at least 99% successful answers, no stale addresses after two TTL intervals, and 99% correct regional output. These are examples, not universal guarantees.

Troubleshooting sequence

When the destination looks wrong:

1. verify the proxy exit independently;
2. prove whether the client or proxy resolved the hostname;
3. record the recursive resolver and answer set;
4. close pooled connections and repeat with a fresh context;
5. compare A and AAAA behavior separately;
6. wait for the recorded TTL before declaring an answer stale;
7. compare business output without cookies or saved locale state;
8. escalate with timestamps, anonymized session IDs and normalized evidence.

Do not call a provider fraudulent because two public databases or resolvers disagree. Classify the layer and reproduce the behavior first.

Release checklist

• [ ] Local and proxy-side resolution modes are explicitly configured.
• [ ] Client, resolver, exit and serving-edge locations are stored separately.
• [ ] Cold and warm cache runs respect TTLs.
• [ ] A and AAAA records are tested independently.
• [ ] Connection reuse is disabled between cold cohorts.
• [ ] Answer sets are normalized before comparison.
• [ ] Regional business output is validated in addition to IPs.
• [ ] Credentials, cookies and personal data are excluded from logs.
• [ ] Query volume stays within authorized and reasonable limits.

FAQ

Should all proxy markets resolve a hostname to different addresses?

No. Anycast and globally shared infrastructure may return the same address. The important question is whether the reached service and business output meet the market requirement.

Does remote DNS guarantee a market-local answer?

No. It changes where resolution occurs, but the proxy may use a centralized recursive resolver. Measure the resolver path and outcome.

Is a different TTL evidence of a problem?

Not by itself. Authoritative systems can return different TTLs by answer, policy or migration state. Investigate only when the variation violates the expected policy or causes stale and failed requests.

Can I compare only one query per market?

No. Sample across multiple exits and time windows. One query proves only one resolver and cache state at one moment.

Compliance note

Use DNS and proxy testing only for lawful, authorized quality assurance. Respect destination terms, DNS query limits, privacy obligations and regional data rules. Do not use resolver manipulation to bypass access controls or conceal prohibited activity.