{{ interpretationLead }}
| # | ECS answer | TTL | No-ECS answer | TTL | Delta | Copy |
|---|---|---|---|---|---|---|
| {{ row.rank }} | {{ row.ecsAnswer }} | {{ row.ecsTtl }} | {{ row.plainAnswer }} | {{ row.plainTtl }} | {{ row.deltaLabel }} | |
| No answers returned. | ||||||
| Resolver | ECS first answer | ECS ms | No-ECS first answer | No-ECS ms | Signal | Copy |
|---|---|---|---|---|---|---|
| {{ row.resolver }} | {{ row.ecs_first || '—' }} | {{ row.ecs_ms === null ? '—' : row.ecs_ms }} | {{ row.plain_first || '—' }} | {{ row.plain_ms === null ? '—' : row.plain_ms }} | {{ row.signalLabel }} | |
| No resolver matrix data. | ||||||
EDNS Client Subnet, usually shortened to ECS, is a DNS extension that lets a resolver include a truncated client network hint when it asks an upstream DNS service for an answer. The point is not to expose the full client address. It is to let geographically sensitive systems such as content-delivery platforms choose an answer that better matches the user's network region. This tester turns that policy question into something you can inspect from the browser.
The package asks the same DNS question twice for the selected resolver: once with an ECS token and once without it. It then compares answer membership, TTL movement, response timing, and optional DNS flag variance. In cross-resolver mode it repeats the same pair on the peer resolver so you can see whether the signal belongs to one resolver path or survives across both Cloudflare and Google vantage points.
That makes the page useful when you are validating CDN geo-steering, checking whether a resolver is ignoring the subnet hint, confirming that a traffic shift changed the returned answer set, or investigating whether two resolvers behave differently even when the domain and record type are identical. The answer table shows the concrete records. The brief and matrix views turn those raw differences into operational language.
A changed answer set does not automatically mean a fault, and a stable answer set does not automatically mean ECS is unused. Some zones intentionally ignore ECS, some only vary by resolver policy, and some return the same records while still changing cache timing. The right interpretation comes from reading the answer rows, overlap ratio, latency delta, and resolver matrix together.
Privacy matters here as well. The page sends live DNS-over-HTTPS requests to external resolver endpoints, and the optional Use my IP helper asks public IP services for the current outward-facing address before converting it to a network base. That is appropriate for a diagnostics tool, but it means the session depends on external network calls rather than a sealed local simulation.
Start by choosing the domain and the record type that actually matter to the routing question. A and AAAA are the natural first checks because they can vary by geography and they are the only types for which the subnet controls are active in this package. If you switch to CNAME, MX, NS, TXT, SOA, CAA, or SRV, the tester still compares responses, but the client-subnet fields no longer drive the request.
The next choice is resolver vantage. Cloudflare (1.1.1.1) or Google (8.8.8.8) sets the primary comparison pair shown in the summary badges and the answer-drift table. Primary resolver pair only is useful for a quick pass. Primary + peer resolver matrix is better whenever you need confidence that a result is not just a single-resolver quirk.
The subnet itself should be chosen deliberately. The package expects a base address plus prefix length, not a host address with a mask tacked on casually. For most operational checks that means entering the network you want to simulate rather than an arbitrary endpoint inside it. The tooltip guidance mirrors common ECS practice: /24 is a practical IPv4 default and /56 is a practical IPv6 default when you want a hint without excessive specificity.
Flag consistency boost is a scoring choice, not a new DNS query mode. When enabled, differences in AD, RD, RA, or TC between the ECS and non-ECS responses feed the signal score alongside answer and TTL drift. That can be useful for a conservative diagnostics posture, but the core evidence is still in the returned answer sets themselves.
| Question | Best place to start | Why it helps |
|---|---|---|
| Did ECS change the returned records? | Answer Drift Table | Shows row-by-row answer membership and TTL differences between ECS and no-ECS runs. |
| Is the signal resolver-specific? | Resolver Footprint Matrix | Compares the primary resolver pair with the peer resolver pair under the same inputs. |
| Do I need a quick operational reading? | Assessment Brief | Summarizes answer shifts, TTL drift, overlap, and recommended next checks in plain language. |
| How strong is the combined signal? | Subnet Signal Radar | Turns answer shift, TTL shift, latency swing, overlap deficit, and scope or flag risk into one visual profile. |
The DNS query flow is explicit in the bundle. The page builds a DoH URL for the selected resolver, attaches name and type, and adds edns_client_subnet only when the record type is A or AAAA and a valid subnet base is present. Each request is wrapped in an abortable timeout derived from the slider, and the returned JSON payload is reduced to answer rows, status code, latency in milliseconds, echo-subnet text, and the AD, RD, RA, and TC flags when present.
Answer comparison is deterministic. IPv4 answers are sorted by numeric 32-bit value. IPv6 answers are expanded and sorted by numeric 128-bit value. Other record data sorts lexicographically as strings. Once both answer sets are normalized, the package computes the union of unique answers, counts how many records changed membership between the two sets, counts how many stayed present but changed only by TTL, and derives overlap, changed-ratio, and TTL-ratio metrics from that union.
The score shown in the summary is a package-level diagnostic index rather than a standards-defined ECS grade. It blends answer-set shift, TTL-only shift, latency swing, prefix-risk weighting, and optional flag variance into a 0 to 100 footprint score. That score is then placed into three bands: low, moderate, or high ECS steering signal. It is meant to speed triage, not to replace the underlying answer evidence.
The cross-resolver matrix follows the same structure. The selected resolver forms the primary pair that populates the main tabs. When cross mode is enabled, the peer resolver is queried in parallel and summarized as a second matrix row. If the peer query fails, the page records the failure as a note instead of silently dropping the comparison. That matters because partial visibility is different from genuine agreement.
| Output | What the page measures | What it does not prove |
|---|---|---|
| Changed answers | How many unique answer values appear on only one side of the ECS vs no-ECS comparison. | That the routed application traffic will necessarily land on a specific server. |
| TTL drift | How many shared answers stayed present but returned different TTL values. | That the content itself changed. |
| Latency delta | The millisecond difference between the ECS and no-ECS DoH requests for the primary pair. | A complete performance profile of the application path. |
| Echo subnet | The subnet string echoed back by the resolver payload when provided. | How every upstream authoritative server handled that hint internally. |
| Footprint score | A package-defined rollup of answer, TTL, latency, scope, and optional flag signals. | An IETF-defined compliance score. |
The page also exposes several operational conveniences. Use my IP calls an IPv6-first ipify endpoint and then an IPv4 fallback, converts the discovered public address to a network base, and applies a default /56 or /24 prefix depending on the address family. The answer-drift and matrix tables can both be copied or exported as CSV or DOCX. The radar chart supports PNG, WebP, JPEG, and CSV export, and the JSON tab preserves the raw inputs, computed diffs, recommendations, and raw resolver payloads together.
State handling is partly local and partly network-exposed. The active inputs are synchronized through the shared query-parameter layer so they can be restored from the URL. No tool-specific server helper stores the results, but the page does depend on external resolver APIs, ipify for public-IP discovery, and the charting asset referenced in metadata.
The clearest ECS signal is answer membership change. If the same domain and record type return different address rows with and without the subnet hint, the page is showing a real content-steering difference for that resolver path. TTL-only change is weaker. It often means the cache state differs while the content itself remains aligned.
Resolver disagreement is often the next most important clue. If one resolver pair shows strong answer drift and the other remains near-baseline, the operational conclusion is different from a case where both resolvers shift in the same way. The matrix view is therefore more than a convenience. It helps separate zone behavior from resolver behavior.
The score band should be read as a triage summary. High ECS steering signal means the page saw substantial answer, timing, or scope evidence that the subnet hint matters. Low ECS steering signal means the comparison stayed close to baseline under the tested conditions. Neither label tells you whether the routing policy is good, only whether the tested path looks sensitive to ECS.
| Pattern | Likely meaning | Reasonable next step |
|---|---|---|
| Changed answers, strong overlap drop | The resolver path is returning materially different records when the subnet hint is present. | Validate CDN steering policy, health-check regioning, and intended catchment for that subnet. |
| No answer change, only TTL drift | Cache position or cache policy differs more than the content itself. | Check resolver cache scope and repeat over time before treating it as routing drift. |
| One resolver shifts, the peer stays steady | The effect may be resolver-specific rather than universal. | Compare more resolvers or validate against authoritative or CDN-side telemetry. |
| No measurable signal | The tested question may ignore ECS or the chosen subnet may not cross a steering boundary. | Retest with a different subnet, resolver, or record family that reflects the real routing decision. |
A final caution: this page observes DNS answers, not end-to-end application success. A perfect-looking resolver result can still map to an unhealthy backend, and a resolver difference can still be harmless when both answers terminate inside the same healthy service pool. Use it as a DNS evidence layer, not the last word on application delivery.
An operator testing a new regional edge policy probes the same hostname with and without a /24 IPv4 subnet hint. The answer table shows a different address on the ECS side, and the cross-resolver matrix shows the same pattern on both resolvers. That is strong evidence that DNS steering is reacting to the supplied network hint.
A team sees a warning badge but the answer rows remain identical. The table reveals that only TTL values moved. In that case the safer interpretation is cache-state variance, not a true destination change, so the team watches repeated runs before opening an incident.
Cloudflare shows a moderate signal for a tested AAAA record, while Google looks flat. That does not invalidate the first result. It tells the operator to treat the behavior as path-specific until authoritative or CDN-side evidence confirms that the difference is intentional and not resolver policy noise.
No. The subnet controls are active only for A and AAAA. Other record types are still compared, but without the ECS token.
It is the subnet string the resolver returned in its JSON payload for the ECS query. It is useful evidence, but it is not a full explanation of every upstream handling step.
Because the score summarizes the selected primary pair first. The peer resolver matrix is there so you can decide whether the effect is broad or resolver-specific.
Yes. It calls ipify to discover the current outward-facing address, then converts it to a network base locally before building the ECS token.
No. It proves only what the tested DNS responses looked like under the selected conditions. Application health and traffic landing still need their own verification.