EDNS Client Subnet (ECS) Tester
Check whether a DNS name changes under EDNS Client Subnet hints with no-hint controls, echoed scope, resolver signals, and exports.{{ summaryHeading }}
| Section | Signal | Detail | Copy |
|---|---|---|---|
| Attribution reading | Interpretation | {{ interpretationLead }} | |
| Recommended next check | Step {{ index + 1 }} | {{ step }} | |
| Operational fact | Fact | {{ fact }} | |
| Evidence boundary | Supported | {{ item }} | |
| Evidence boundary | Not proven | {{ item }} |
| Answer | ECS seen | ECS TTL | No-ECS seen | No-ECS TTL | Interpretation | Copy |
|---|---|---|---|---|---|---|
| {{ row.answer }} | {{ row.ecsSeenLabel }} | {{ row.ecsTtl }} | {{ row.plainSeenLabel }} | {{ row.plainTtl }} | {{ row.deltaLabel }} | |
|
No answer records returned
Run an ECS probe before exporting the answer ledger.
|
||||||
| Resolver | Capability | ECS echo | Changed | TTL | Overlap | Verdict | Copy |
|---|---|---|---|---|---|---|---|
|
{{ row.resolver }}
{{ row.statusLabel }} · {{ row.latencyLabel }}
|
{{ row.capabilityText }} |
{{ row.echoScope }}
{{ row.scopeNote }}
|
{{ row.changed }} | {{ row.ttlOnly }} | {{ row.overlapLabel }} |
{{ row.verdict.badgeText }}
{{ row.note }}
|
|
|
No resolver matrix rows available
Run a resolver comparison before exporting the signal matrix.
|
|||||||
| Pair | Requested ECS | Echo scope | Scope verdict | Status | Copy |
|---|---|---|---|---|---|
| Scope assessment | {{ requestedEcsLabel }} | {{ echoSubnet || '-' }} | {{ scopeAssessment.longText }} | {{ scopeAssessment.shortLabel }} | |
| Scope highlight {{ index + 1 }} | — | — | {{ item }} | Highlight | |
| Resolver guardrail {{ index + 1 }} | — | — | {{ item }} | Guardrail | |
| {{ row.pairLabel }} | {{ row.requestedEcs }} | {{ row.echoScope }} | {{ row.scopeVerdict }} | {{ row.statusLabel }} | |
|
No scope ledger rows available
Run an ECS-capable comparison to collect scope evidence.
|
|||||
Introduction:
EDNS Client Subnet, usually called ECS, is a DNS extension that lets a recursive resolver attach a shortened client-network prefix to an upstream DNS query. The goal is practical routing rather than identity. A content delivery network, video platform, download mirror, or other latency-sensitive service can use the network hint to return an address that is closer to the likely user while avoiding disclosure of the full client IP address.
The tradeoff is that the DNS answer is no longer just a property of the hostname. It can also depend on the resolver, address family, requested prefix length, cache state, and whether the authoritative side chooses to vary responses by client network. Two users asking for the same A record may see different addresses because their resolver sent different ECS hints, while two very different networks may still see the same address if the hostname is not steered that way.
Several terms matter before interpreting a result. The source prefix is the client network sent with the query, such as 203.0.113.0/24 or 2001:db8::/56. The scope prefix is the cache boundary returned with the answer. A broad scope means a resolver may reuse the answer for a wider group of clients; a narrow scope means the answer is tied more tightly to the hinted network. A missing scope does not automatically mean the hostname ignores ECS, but it weakens the attribution trail.
ECS evidence is easiest to misread when it is treated as a single lookup. A useful investigation compares a hinted query with a no-hint control, then checks whether a privacy-first resolver shows the same behavior. Answer membership changes are stronger than TTL changes because they show different returned content. TTL-only movement can simply mean that one cached answer is older than another. Status-code differences, such as NOERROR versus NXDOMAIN, deserve even more attention because the resolver is returning a different class of response.
DNS evidence still has a hard limit. ECS can show that a resolver path returned different DNS data under a tested subnet, but it cannot prove which server an application request ultimately reached, whether an edge was healthy, or whether a CDN policy was intended. Treat the result as resolver evidence that should be paired with application telemetry, authoritative logs, traceroutes, or CDN diagnostics when the question affects production routing.
How to Use This Tool:
Start with a hostname whose address answers are likely to be routed by geography or network, such as a CDN-backed asset host. Paste a hostname or URL, choose A for IPv4 or AAAA for IPv6, and use Google Public DNS when you need a path that can return ECS scope evidence. Keep the cross-resolver mode enabled when the result matters, because the peer row helps distinguish resolver policy from hostname behavior.
The client subnet should describe the network you want to simulate, not an arbitrary single host. For IPv4, a /24 is a common practical starting point. For IPv6, a /56 is often more appropriate for residential or access-network testing. The public-IP shortcut asks a public address service for your outward-facing address, then trims it to a network base before using it. Avoid entering a full sensitive host address when a shorter prefix answers the routing question.
- Enter one domain or hostname. A pasted URL is reduced to the host before the lookup runs.
- Choose
AorAAAAfor an ECS steering check. Other record types run as resolver comparisons without a subnet hint. - Select the resolver lens. Google Public DNS is the ECS-capable path; Cloudflare 1.1.1.1 is the privacy baseline.
- Choose single or cross probe depth. Cross mode repeats the same comparison on the peer resolver.
- Enter the subnet base and prefix, or use your current public network as a starting point.
- Run the check, read the summary and runbook first, then use the ledgers, matrix, radar chart, and JSON only as deeply as the question requires.
The result tabs are organized by evidence type. Runbook Brief gives the operational reading and recommended follow-up. Answer Ledger shows which records appeared only with ECS, only without ECS, or on both sides with a TTL difference. Resolver Signal Matrix compares the primary resolver with the peer resolver when cross mode is enabled. Scope Ledger explains the requested and returned subnet scope. Resolver Evidence Radar turns answer drift, TTL drift, latency swing, scope proof, and resolver trust into a compact visual summary. The JSON view is best for saving the whole probe state.
Use the export buttons when you need to hand off evidence. The answer and matrix tables can be copied or downloaded as CSV, selected tables can be exported as DOCX, the radar can be downloaded as image formats or metrics CSV, and the complete payload can be copied or saved as JSON.
Interpreting Results:
Read the result from strongest evidence to weakest evidence. A DNS status change is the first thing to notice because the lookup class changed. An answer membership change is the clearest DNS signal that the subnet hint affected returned content. TTL-only drift is weaker because it can come from cache age rather than routing policy. Latency movement is useful context, but it should not be treated as proof of steering by itself.
| Observed pattern | Likely reading | Next check |
|---|---|---|
| Status pair differs | The hinted and control lookups returned different DNS response classes. | Repeat with the peer resolver and check authoritative or CDN-side logs if available. |
ECS-only or Control-only answers appear |
The answer set changed, which is the strongest resolver-side sign of content steering. | Confirm the subnet crosses a known policy boundary and test a nearby prefix. |
| Same answers, different TTL values | The destination list stayed the same while cache lifetime differed. | Run the same query again after the TTL window moves before escalating. |
| Echoed scope matches the request | The ECS-capable resolver returned a scope tied to the requested prefix. | Use this as supporting attribution, especially when answer membership also changed. |
| Echoed scope is broader than requested | The answer may be cacheable for a wider network than the exact prefix supplied. | Do not assume the answer is unique to the small subnet you tested. |
| Cloudflare row changes | The control resolver moved too, so the effect is not clean ECS proof by itself. | Compare with Google and with an authoritative or CDN-specific diagnostic. |
The signal score is a triage aid, not an Internet standard. It intentionally weights answer drift more heavily than TTL drift and latency swing, then adjusts the result by scope evidence and resolver trust. A high score on an ECS-capable resolver deserves attention. A high-looking difference on a privacy baseline should be read as resolver or cache context unless other evidence supports ECS attribution.
The safest production reading is comparative. If Google shows changed answers with a readable scope and Cloudflare stays flat, the DNS evidence points toward ECS-sensitive steering. If both resolvers change, the hostname or upstream DNS state may be changing independently of ECS. If neither resolver changes but Google returns a readable scope, the tested hostname probably did not vary for that subnet at that moment.
Technical Details:
RFC 7871 defines ECS as an EDNS option with an address family, source prefix length, scope prefix length, and truncated address. The source prefix is the number of significant address bits used for the lookup. The address is padded after the prefix, so the resolver or client should not send host bits beyond the chosen boundary. In a query, the scope prefix is set to zero; in a response, the scope prefix tells the recursive resolver how broadly it may reuse the answer in cache.
An ECS investigation compares two DNS observations: a hinted request and a control request. The meaningful comparison is not just the IP address list; DNS status, flags, answer membership, TTL values, elapsed time, and returned scope all affect confidence. Address records are the normal place to look for ECS-sensitive steering because CDNs and authoritative DNS platforms most often vary A and AAAA answers. CNAME, MX, NS, TXT, SOA, CAA, and SRV records can still differ between resolvers, but those differences do not by themselves show client-subnet routing.
The tested subnet is normalized to a network base before it becomes a hint. IPv4 prefixes are bounded from /0 to /32 and IPv6 prefixes from /0 to /128; host bits outside the prefix are zeroed, so 8.8.8.8/24 becomes 8.8.8.0/24. A missing or unparsable subnet turns the run into a control comparison. The public-address shortcut obtains the current outward-facing address and then reduces it to the selected network prefix instead of using host bits as the routing hint.
Resolver policy matters because ECS is not universal. Google Public DNS is treated as the positive ECS-capable path because its JSON DNS-over-HTTPS interface accepts a client subnet value and can return a top-level scope value in the response. Cloudflare 1.1.1.1 is treated as a privacy baseline because its public resolver says it does not send ECS information to authoritative servers for production domains. That contrast is why the same answer movement is interpreted differently depending on the resolver row.
Comparison Mechanics
| Measurement | How it is derived | Why it matters |
|---|---|---|
| Changed answers | Unique answer values present on one side of the hinted/control pair but not the other. | Shows whether returned content changed under the subnet hint. |
| TTL-only drift | Shared answer values whose TTL differs between the two sides. | Highlights cache timing differences without claiming destination change. |
| Overlap | Shared answer count divided by the union of unique answers. | Shows how much of the answer set stayed stable. |
| Scope proof | Resolver type, requested subnet, and returned ECS scope are compared. | Strengthens or weakens attribution to ECS-aware caching. |
| Resolver trust | ECS-capable resolver paths receive high trust; privacy baselines receive low trust. | Prevents control-resolver movement from being scored as clean ECS proof. |
Signal Score Formula
The score is deliberately conservative about attribution. Answer membership can contribute up to half of the raw evidence term, TTL drift contributes less, and latency swing is capped so a slow response does not dominate the result. Scope proof adds confidence when an ECS-capable resolver returns interpretable scope data. Resolver trust keeps the privacy baseline from looking like positive ECS support.
Privacy and transmission are part of the technical reading. The selected hostname, record type, and optional subnet hint are sent to the chosen public resolver over HTTPS. The browser also contacts a public IP service only when the public-network shortcut is used. The shortcut reduces the returned address to a network base before building the subnet hint, but the DNS lookup itself still leaves your browser for the selected resolver.
Because resolver caches and CDN policies change over time, a single run is a snapshot. For incident work, repeat the same hostname, record type, resolver, and subnet after the relevant TTL interval, then compare with authoritative-side evidence before making a policy change.
Advanced Tips:
- Test a known boundary, not just a random prefix. Adjacent
/24IPv4 or/56IPv6 prefixes are more useful when you are checking whether a CDN policy changes near an access-network edge. - Run
AandAAAAseparately. IPv4 and IPv6 steering policies can diverge, and one address family may have ECS variation while the other stays stable. - Use cross mode for evidence you plan to share. A stable privacy-baseline row makes an ECS-capable resolver change easier to attribute, while movement on both resolvers points to broader DNS or cache churn.
- Leave flag consistency enabled for resolver-policy audits. Status, DNSSEC, recursion, and truncation flag changes can matter even when the address list looks similar.
- Repeat the same query after the TTL window when the result is TTL-only. Fresh cache timing can look noisy without proving a different destination set.
Worked Examples:
A regional CDN answer changes under ECS
You test an A record with Google as the primary resolver and a /24 that should represent another access network. The hinted side returns two IP addresses that the control side does not return, the echoed scope is readable, and the Cloudflare peer row stays steady. That is strong DNS evidence that the hostname varies its address answer by client subnet.
The destination stays the same while TTLs move
The answer ledger shows every address on both sides, but several TTLs differ. The summary may still show activity because the cache state changed, but the result does not show different returned content. Repeat the lookup after the TTLs age or use a different subnet before calling it routing drift.
A non-address record is only a resolver comparison
You choose TXT while checking a domain's policy records. The tool can still compare status, answers, and TTLs across resolver paths, but it does not attach a client subnet hint for that run. Treat the output as DNS resolver evidence, not as an ECS steering test.
Scope evidence is missing
A Google run completes, but the scope ledger reports no echoed scope and the answers are unchanged. That does not prove the hostname ignores ECS everywhere. It means this particular lookup did not produce enough scope evidence. Try another prefix, test both address families, or compare with an authoritative diagnostic before closing the investigation.
FAQ:
Why are only A and AAAA treated as ECS checks?
This page attaches a subnet hint only for address lookups. Other DNS record types can still reveal resolver differences, but the result should be read as a resolver comparison rather than proof of client-subnet steering.
Why use Google and Cloudflare together?
Google Public DNS provides the positive ECS-capable path for this checker. Cloudflare 1.1.1.1 provides a useful privacy baseline because it does not forward ECS to authoritative servers for production domains. Seeing both paths side by side reduces over-attribution.
Does a changed answer prove users hit a different server?
No. It proves that the DNS answer changed under the tested resolver, hostname, record type, and subnet. The actual application path still depends on client connection behavior, CDN mapping, caching, load balancing, and service health.
What does a broader returned scope mean?
A broader scope means the answer can be reused for a wider network than the specific source prefix you requested. That can be normal, but it means the result should not be described as unique to the smaller subnet.
Why can a high score still be inconclusive?
The score summarizes resolver evidence. It does not know the authoritative operator's intent, the CDN's live routing policy, or the application's end-to-end path. Read the answer ledger and scope ledger before acting on the score alone.
What data leaves my browser?
Each lookup sends the chosen hostname, record type, and optional subnet hint to the selected public resolver over HTTPS. The public-network shortcut also contacts a public IP service so the page can derive a network prefix for the test.
Glossary:
- ECS
- EDNS Client Subnet, a DNS extension that carries a shortened client-network hint with a query.
- Source prefix
- The significant network bits sent with the query, such as
203.0.113.0/24. - Scope prefix
- The cache-reuse boundary returned with an ECS response.
- DoH
- DNS over HTTPS, the encrypted HTTP transport used for the live resolver lookups.
- TTL
- Time to live, the remaining cache lifetime reported for a DNS answer.
- Answer membership
- The set of unique DNS answer values returned by a lookup, separate from their TTL values.
- Privacy baseline
- A resolver path used as a control because it is not expected to forward ECS for ordinary production lookups.
References:
- RFC 7871, Client Subnet in DNS Queries, IETF.
- RFC 8484, DNS Queries over HTTPS, IETF.
- JSON API for DNS over HTTPS, Google Public DNS.
- EDNS Client Subnet Guidelines, Google Public DNS.
- Cloudflare 1.1.1.1 FAQ, Cloudflare.