EDNS Client-Subnet Tester

Introduction:

Domain name answers are the records a resolver returns for a given name and type. Networks can steer responses based on where a request appears to come from, so the address you see can differ by location and freshness. Use this to compare domain answers by client subnet when you want to check routing behavior with clear, repeatable steps.

Enter a domain, pick the record family you care about, and decide whether to supply a client subnet hint. The tool queries once with the hint and once without it, then shows the answers, the time to respond, and whether anything changes. A quick scan of the table tells you if results match or if only time to live values differ.

Teams use this during content delivery rollouts or regional failovers when they need to verify that resolution aligns with intent. A common read is that multiple addresses near a region signal load sharing, while a single address far away suggests a routing miss that needs attention. Keep inputs consistent between runs so comparisons remain fair.

Remember that a matching pattern does not prove that traffic will reach a specific server and a differing pattern does not always mean a fault. Treat this as a fast lens on resolver behavior, then confirm with flow data or application logs when decisions matter.

Technical Details:

The Domain Name System (DNS) answer set for a name and a resource record type contains one or more RDATA values and a time to live (TTL) in seconds. This tester examines how the Extension Mechanisms for DNS (EDNS) Client Subnet (ECS) hint influences those answers by issuing two lookups for the same question: one that includes a network base and one without the hint.

For each lookup, answers are normalized into a stable order so that comparisons are deterministic. Internet Protocol version 4 (IPv4) addresses sort numerically by 32‑bit value and Internet Protocol version 6 (IPv6) addresses sort by 128‑bit value. All other record data sort lexicographically by string. The app then reports two indices: the count of records that changed between sets and the count of entries that only differ by TTL.

Timing is measured per query using a monotonic clock and reported in milliseconds. A result is considered “identical” when both indices are zero. If records differ, the changed count conveys whether content steering is in effect or a resolver path differs; TTL‑only differences usually indicate distinct cache positions while content remains aligned.

Comparability depends on asking the same question with the same inputs. The ECS hint is applied only when the record type is A or AAAA; other types ignore the subnet fields. Default subnet widths favor common practice: /24 for IPv4 and /56 for IPv6. Rows align after normalization; when one side lacks a position, the table marks it clearly.

Processing pipeline

1. Read domain name and record type.
2. If type is A or AAAA and a subnet is provided, compute the network base for the prefix.
3. Build a JSON DNS query URL, adding the ECS string when available.
4. Fetch resolver JSON and measure elapsed time in milliseconds.
5. Extract Answer array; coerce TTL to integer seconds; strip outer quotes for TXT.
6. Normalize answer order deterministically by type‑aware sort.
7. Repeat the query without ECS and normalize results.
8. Compute changed‑record count and TTL‑only count; render tables and badges.

Symbols & units

Worked example

Interpretation bands

Validation & bounds

I/O formats

Networking & storage behavior

• Queries use DNS over HTTPS JSON at cloudflare-dns.com/dns-query with header accept: application/dns-json.
• The resolver selector is present in the UI, but lookups are sent to Cloudflare in this build.
• “Use my IP” requests your public address from IPv6‑first and IPv4 endpoints with a 6 second abort timer.
• Clipboard and file actions run locally; processing is browser‑based and state is not kept on a server.

Performance & complexity

• Normalization sorts A and AAAA numerically and other records lexicographically; complexity O(n log n).
• Timing covers request, response, and JSON parse.

Diagnostics & determinism

• Stable sorting ensures identical inputs render identical orderings.
• Result variability reflects resolver state and distance, not randomization by the UI layer.

Security considerations

• The ECS hint intentionally reveals a network segment to the resolver; use test ranges when demonstrating.
• The JSON view is rendered from returned text; highlight functions should escape untrusted content before HTML insertion.

Assumptions & limitations

• ECS is applied only for A and AAAA lookups.
• Resolver selection control is present but not wired to query logic in this version.
• Domain validation checks only for non‑empty input.
• IDNs are passed as typed; no punycode normalization is applied by the UI.
• Answer alignment is by sorted index; missing positions are shown as gaps.
• TXT values show without outer quotes for single‑string answers.
• Timings are approximate per call and not a throughput benchmark.
• No caching is implemented; back‑to‑back queries may observe TTL drift.
• Public IP detection may fail silently if endpoints block or time out.
• Heads‑up Differences do not prove reachability or application latency.

Edge cases & error sources

• Blank domain yields “Enter a domain.”
• Non‑conforming hostnames may cause resolver errors.
• IPv6 compression and zones are handled, but unusual forms may not sort as expected.
• Prefix length is clamped to 0–32 for IPv4 and 0–128 for IPv6.
• Resolver responses without an Answer array display “No answers.”
• TXT records with multiple strings remain concatenated as delivered.
• MX and SRV values sort as plain strings, not by priority.
• Network hiccups surface as generic lookup errors with HTTP status.
• Large answer sets increase sort time and diff cost.
• Clock skew is avoided by monotonic timing, but system load still affects measurements.

Privacy & compliance

Requests are issued from your browser to public endpoints; the app does not store your inputs server‑side. When using ECS, avoid sensitive or user‑specific addresses.

Step‑by‑Step Guide

Compare answer sets for a domain with and without a client subnet hint to understand routing and cache behavior.

1. Enter the domain to query.
2. Select the record type.
3. Open Advanced and provide a client subnet and prefix if testing A or AAAA.
4. Click Query and review answers and TTL.
5. Click Compare to run the same question without a subnet hint.
6. Scan badges for timing and difference counts; export data if needed.

Example. Query example.com type AAAA with subnet 2001:db8:: and prefix 56, then compare again without the hint.

• Tip: keep the same domain and type when comparing runs over time.

FAQ

Troubleshooting

• “Enter a domain.” Add a name and try again.
• DoH error with status code. Retry later or switch networks; rate limits and filtering can block the endpoint.
• No answers. Check the record type and spelling; try querying NS or SOA to confirm authority.
• Use my IP does nothing. The public IP service may be blocked; enter a subnet manually.
• All rows show gaps. The set sizes differ; scroll the JSON view to inspect raw arrays.
• TXT looks odd. Quotes are removed from single‑string TXT for readability; multi‑string records remain as delivered.

Advanced Tips

• Tip Use documentation ranges 192.0.2.0/24, 198.51.100.0/24, or 203.0.113.0/24 for examples.
• Tip Test both A and AAAA to reveal dual‑stack steering differences.
• Tip Re‑run the same query every few minutes to watch cache rollovers.
• Tip For IPv6, start with a /56 prefix unless you have a specific policy.
• Tip Sort the CSV externally by TTL to spot hot caches.
• Tip Use the JSON view to confirm resolver flags and response status fields.

Glossary

Answer set

The collection of records returned for a query.

TTL

Time in seconds that a record may be cached.

ECS

EDNS Client Subnet hint that carries a network base.

Network base

The masked address representing a prefix.

Normalization

Stable ordering of answers for fair comparison.

Resolver

A service that answers name queries.

A / AAAA

IPv4 and IPv6 address record types.

RDATA

The data portion of a resource record.