DNS Answers ({{ answersEcs.length }})
{{ answersEcs[0].data }}
Query time {{ responseTimeEcs }} ms
{{ error }}
ECS Answer TTL (s)
{{ row.data }} {{ row.ttl }} 
{{ formattedJSON }}
Categories: DNS , Networking , Security
Export to PDF Fullscreen

The Extension Mechanisms for DNS client-subnet option lets recursive resolvers append a truncated segment of the requester’s address to upstream queries. Authoritative servers and anycast delivery platforms can then return responses aligned with the caller’s presumed location, improving latency and routing accuracy yet splintering cache efficiency across networks.

This tester submits two DNS-over-HTTPS look-ups—one that carries the client-subnet prefix and one that omits it—then compares answer sets, time-to-live values, and round-trip durations. You supply a domain, a record type, and optionally a subnet prefix; the reactive engine times and parses each exchange, exposing disparities in a side-by-side table and raw JSON view.

Network engineers, CDN architects, or security teams use the comparison to verify geo-routing policies, audit cache divergence, and spot regional outage patterns. Use caution when interpreting large TTL gaps; upstream zone files might differ rather than the EDNS behavior alone.

Technical Details:

Concept Overview

EDNS client-subnet (RFC 7871) extends standard DNS with a location hint—an IP prefix—enabling upstream resolvers to tailor answers for the requester’s region. Public DNS-over-HTTPS endpoints accept a edns_client_subnet query string, match the prefix against their cache, and return address records plus remaining TTL. Key variables include query name (QNAME), record type (QTYPE), client prefix (ECS), and measured response time (t).

Core Process

  1. Compose two HTTPS GET requests: one with edns_client_subnet=<IP>/<len>, one without.
  2. Send each request to a public DNS-over-HTTPS resolver.
  3. Record elapsed time t for each exchange.
  4. Parse the JSON Answer array into data strings and TTL integers.
  5. Align answer sets by index and flag mismatches.

Interpretation Table

TTL Band (s)Typical Meaning
0 – 300Highly volatile, likely geo-steered edge records
301 – 1 800Short-lived balancing or fail-over records
1 801 – 86 400Standard authoritative zone values
> 86 400Static infrastructure or vanity domains

Shorter TTLs increase request volume but allow rapid routing shifts; longer TTLs favour cache efficiency over agility.

Variables & Parameters

ParameterMeaningTypical Range
domainFully-qualified domain to resolveany valid DNS label
typeRecord class requestedA | AAAA | CNAME | MX | NS | TXT
client_ipSubnet base for ECS hintIPv4 / IPv6 address
prefix_lengthBits from client_ip sent upstream0 – 32 (IPv4), 0 – 128 (IPv6)

Worked Example

Query example.com A with ECS 1.2.3.0/24:

tECS=42 ms
tplain=58 ms
Δt=tplain−tECS=16 ms

The ECS query reached a geographically closer cache, shaving 16 ms off round-trip time while returning the same address set.

Assumptions & Limitations

  • ECS behaviour depends on resolver and authoritative server support.
  • Public resolvers may anonymise or truncate prefixes beyond your input.
  • Measurements include network latency, not pure resolver processing time.
  • CDNs can override TTLs dynamically, masking true authoritative values.

Edge Cases & Error Sources

  • Non-existent domains produce empty answer sets.
  • CNAME chains may reorder answers, complicating comparisons.
  • IPv6 prefixes longer than 56 bits are sometimes rejected upstream.
  • Firewalls blocking DoH traffic trigger fetch errors.

Scientific Validity & References

Key references include RFC 7871 (EDNS0 Client Subnet), RFC 8484 (DNS-over-HTTPS), and peer evaluations of CDN cache localisation strategies in ACM SIGCOMM and NDSS proceedings.

Privacy & Compliance

The tester transmits query details to public DNS-over-HTTPS services; no user data is stored after the session ends.

Step-by-Step Guide:

Follow these steps to compare DNS answers with and without a client-subnet hint:

  1. Enter the target domain in the Domain field.
  2. Select a record class such as A or MX.
  3. (Optional) Expand Advanced and supply a subnet base and prefix length.
  4. Choose Test ECS to perform the first lookup and view results.
  5. Press Compare (no ECS) to run the plain query and highlight divergences.
  6. Switch to the JSON tab to inspect raw resolver output or download the response.

FAQ:

What is ECS?

The client-subnet option truncates your address and embeds it in a DNS query so upstream servers can choose location-aware answers.

Why compare two queries?

Side-by-side responses reveal whether location hints change record sets, TTLs, or latency, helping diagnose CDN behaviour and cache splits.

Is my data stored?

No persistent logs are kept by the tool; queries transit directly to the public resolver and are not saved by the page after completion.

Which resolvers are used?

The tester targets a major public DNS-over-HTTPS service known for stable ECS support; you can fork the code to point elsewhere if needed.

Does ECS expose my location?

Only a prefix—not your full address—is sent; the effective anonymity depends on prefix length and ISP subnet size.

Glossary:

EDNS
Extension mechanisms adding options to classic DNS queries.
ECS
Client-subnet option conveying part of the requester’s address.
DoH
DNS-over-HTTPS, performing DNS look-ups via HTTPS requests.
TTL
Time-to-live defining how long a record may be cached.
Anycast
Routing model directing traffic to the nearest node in a cluster.
Embed this tool into your website using the following code: