EDNS Client Subnet (ECS) Tester

Hostname:

Use a neutral public target such as example.com. No request runs until you choose Check ECS behavior.

Record type:

Address, alias, mail, authority, verification, and service records are available.

Client subnet:

Enter an IPv4 or IPv6 address and choose the source prefix sent to the ECS-capable path.

Prefix

Primary resolver:

Choose which resolver row leads the report; Cross mode adds the other resolver.

Probe depth:

Cross is the stronger attribution default; Single is useful for a focused retry.

Request timeout:

Accepted range: 1500–12000 milliseconds.

Flag consistency:

Off is neutral and still records raw flag differences in the evidence table.

{{ strictFlagsBool ? 'Include flag drift in verdict' : 'Record flags without escalation' }}

Evidence	Observed read	Operational meaning	Copy
{{ row.label }}	{{ row.value }}	{{ row.meaning }}

Resolver	Answer	ECS TTL	Control TTL	Membership	Copy
{{ row.resolver }}	{{ row.answer }}	{{ row.ecsTtl }}	{{ row.controlTtl }}	{{ row.membership }}

Step {{ index + 1 }}{{ step }}

A public DNS resolver normally asks authoritative nameservers on behalf of many users. That can hide where the original client is located. EDNS Client Subnet (ECS) lets an ECS-aware resolver attach a shortened client-network prefix so an authoritative service or content delivery network can return a geographically tailored answer.

The privacy and routing tradeoff is built into the protocol. A shorter prefix describes a larger population and reveals less location detail. A longer prefix describes a smaller network more precisely, which can improve steering but also exposes more of the client's address. RFC 7871 recommends truncation rather than sending the full address.

Source prefix identifies the client network presented with the query.
Scope prefix describes the network range for which the response may be reused.
Control query asks the same DNS question without the chosen client prefix.

A useful ECS test is a paired experiment. The hostname, record type, resolver, and timing stay fixed while only the subnet hint changes. The two answers can then be compared by DNS status, record membership, TTL, response flags, and returned scope. Changing several conditions at once makes attribution much weaker.

Different addresses provide the clearest evidence of steering, but equal addresses do not prove that ECS was ignored. The authoritative side may return the same destination for both networks, the resolver may have a suitable cached response, or the hostname may not use topology-sensitive DNS. An echoed scope shows that ECS participated in the response, not that a different server had to be selected.

The result is still a sample from public recursive DNS. It does not prove authoritative configuration, application reachability, or the answer seen by every client. Repeat tests with representative prefixes and keep the query conditions stable before drawing a routing conclusion.

How to Use This Tool:

Choose a hostname that may use location-sensitive DNS and a client prefix that represents the network you want to test.

Enter the public Hostname and choose one record type. Address, alias, mail, authority, TXT, CAA, and service records are supported.
Enter an IPv4 or IPv6 Client subnet address and select its prefix length. Host bits are masked, so an address inside the same prefix produces the same ECS token.
Use cross-resolver mode for stronger attribution. It adds a privacy-focused control resolver that does not normally forward ECS.
Keep flag consistency off for an answer-first review. Turn it on only when AD, RD, RA, or TC differences should raise a warning after status, answer membership, and TTL have been considered.
Run the paired query. If the request fails, confirm the hostname, address family, prefix range, and timeout before changing the test network.

Technical Details:

The client address is first reduced to its network base. IPv4 accepts prefixes from /0 through /32, while IPv6 accepts /0 through /128. Answer rows lose wrapping quotes and a final hostname dot, duplicate values are merged, and the smallest TTL for each repeated answer is retained.

Transformation Core:

Mask host bits to form the canonical source prefix.
Ask the ECS-capable resolver once with that prefix and once without it.
Normalize each answer set and form their union.
Classify every record as shared, ECS-only, or control-only; compare TTLs only for shared records.
Compare DNS status first, then answer membership, TTL, optional flag drift, and echoed scope.

Formula Core:

Answer overlap measures the shared members as a percentage of all distinct members observed in the pair.

O = {\begin{cases} round (\frac{H}{U} \times 100) & if U > 0 \\ 100 & if both sets are empty \end{cases}

O is overlap percent, H is the number of shared answers, and U is the size of the unique union. If one address is shared and each side has one additional unique address, overlap is 33% after rounding.

Rule Core:

ECS verdict precedence
First matching condition	Verdict	Interpretation
The selected primary row does not support ECS	Privacy control only	No positive ECS test was performed.
ECS and control DNS status differ	DNS status changed with ECS	The response class changed before record values are compared.
Either side has a unique answer	Answer steering observed	The ECS hint coincides with changed answer membership.
Shared answers have different TTLs	TTL drift only	Cache age differs without a destination change.
Strict flag review is on and flags differ	Response flag drift only	Protocol flags differ after stronger evidence remains equal.
An interpretable scope is echoed	ECS accepted; answers stable	ECS participated, but the returned record set stayed the same.
No earlier condition and no echoed scope	No positive ECS proof	The test found no evidence that ECS affected this response.

An echoed prefix shorter than the requested prefix is broader and covers more addresses; a longer echoed prefix is narrower. Equal prefix lengths are labeled matched. A returned scope alone is protocol evidence and must not be read as proof that the application endpoint is closer or reachable.

Interpreting Results:

Start with the verdict and the answer membership rows. A status change or ECS-only/control-only address is stronger evidence than TTL or flag drift. When addresses differ, compare them with the CDN or authoritative steering policy for the requested network.

Use the no-hint row as a control, not as proof that another resolver supports ECS. If answers stay equal and no scope is echoed, repeat with a hostname known to use geographic steering or another representative prefix before concluding that ECS has no effect.

Privacy Notes:

The ECS-capable query sends the selected network prefix through public DNS resolution, where supporting resolvers and authoritative nameservers can see it. Cloudflare 1.1.1.1 is used as a privacy control because it states that it does not send ECS to production authoritative domains.

Use synthetic or approved representative prefixes when possible. Do not submit a real client network if revealing that approximate location or network identity would violate policy.

Worked Examples:

Different address membership

An ECS query returns 203.0.113.10 and 203.0.113.11; the no-hint control returns 203.0.113.11 and 192.0.2.20. One answer is shared, one is ECS-only, and one is control-only, so overlap is 33% and the verdict is Answer steering observed. Confirm those destinations against the intended geographic policy.

Stable answers with an echoed scope

Both query paths return the same complete RRset, but the ECS response echoes a scope. The result becomes ECS accepted; answers stable. That supports ECS participation for this query while giving no evidence that the chosen prefix required a different destination.

References:

RFC 7871: Client Subnet in DNS Queries, IETF, May 2016.
EDNS Client Subnet Guidelines, Google Public DNS, September 2024.
JSON API for DNS over HTTPS, Google Public DNS.
Cloudflare 1.1.1.1 FAQ, Cloudflare, April 2026.