Source-linked AI summary
Who Resolves Your DNS? Measuring Resolver Opacity and Closing the Visibility Gap
Kedar Thiagarajan, Fabian E. Bustamante
TL;DR
DNS lacks a per-query mechanism for clients to learn the ordered resolver path, even as resolution crosses organizational and national boundaries. The paper measures this opacity and introduces Resolver-Path, combining cooperative disclosure with response-bound attestation. Measurements find widespread cross-AS and cross-country resolution, while the proposed mechanism carries the reported path at near-neutral overhead but cannot reveal hidden non-participating hops.
Problem
DNS provides no standardized per-query mechanism for clients to obtain the ordered resolver path across organizations, Autonomous Systems, and national boundaries.
Method
Resolver-Path uses cooperative EDNS-based resolver disclosure and an optional response-bound hash-chain attestation tied to a fresh client nonce.
Results
The study finds that 39.8% of Campaign B observations cross the client–frontend AS boundary, while one in four geolocatable anycast frontend pairs resolves outside the client’s country.
Takeaways & Limitations
Disclosure and attestation provide bounded evidence about the selected response’s reported resolver chain, including authenticated integrity, ordering, and freshness for cooperative assertions.
Takeaways & Limitations
RIPE Atlas overrepresents fixed-broadband networks and Europe, so reported rates describe the measured population and 2023–2025 period rather than the Internet as a whole.
Abstract
from arXiv · showhide
DNS resolution has no notion of a verifiable resolver path. When an ISP outsources resolution to a third-party provider, a user's queries can cross organizational and national boundaries without their awareness---and the client that issued them has no protocol mechanism to learn which resolvers handled the query, where they sat, or who operated them. We argue that this opacity is an architectural gap rather than a deployment accident, and that a reported, verifiable resolver path should be a first-class goal of the resolution protocol. We motivate this with measurement and then show the gap is cheap to close. Using RIPE Atlas across 190 countries, we find that resolution routinely leaves the client's organization and country: under a conservative in-AS treatment of unattributable observations, 39.8% of observed resolver chains (6,622 of 16,636) use a frontend in a different AS than the client, one in four geolocatable anycast frontend pairs resolves outside the client's country, and a single operator---Google Public DNS---accounts for roughly two-thirds of those out-of-country cases. We then present Resolver-Path, an approach in which participating resolvers report their identity as they forward the query. Its base layer is cooperative in-band disclosure, it carries resolver-path metadata at near-neutral throughput, latency, and CPU cost. Because a non-participating resolver can ignore or strip the option, disclosure alone establishes the verifiable presence of reported hops, not the absence of hidden ones. Attestation authenticates the integrity, ordering, and freshness of the cooperative assertions carried by the selected response. Together, disclosure and attestation provide bounded evidence about the selected response's reported resolver chain---the substrate DNS currently lacks for jurisdictional accountability.
1 Introduction
DNS resolution commonly crosses organizational and national boundaries without giving clients a verifiable resolver path. Measurements show this opacity is widespread, while Resolver-Path offers cooperative disclosure and attestation with near-neutral overhead.
- Why opacity matters: Cross-border resolution can expose queries to different surveillance, censorship, or data-retention regimes, while out-of-AS resolution is associated with higher latency.Domestic-looking anycast resolution from Colombia was observed egressing in the United States.
- Motivation: One in four geolocatable anycast frontend pairs resolves outside the client’s country, with Google Public DNS accounting for roughly two-thirds of those cases.In Ireland and France, frontend resolvers appear mostly domestic while authoritative-facing egress crosses borders more often.
- Approach: Resolver-Path lets participating resolvers report their identities as they forward queries through an EDNS-based disclosure mechanism implemented in BIND 9, Unbound, and Knot Resolver.Non-participating resolvers may ignore or strip the metadata, so deployment is incremental.
- Approach: Attestation binds participating resolvers’ assertions to the selected DNS response and a fresh client nonce, authenticating the reported contributions.The construction verifies signatures, hash-chain order, nonce checks, and timestamps on received entries.
- Motivation: 39.8% of Campaign B observations (6,622 of 16,636) cross the client–frontend AS boundary under conservative attribution.This establishes AS separation, not an intervening hop.
2 Measuring Resolver Opacity
RIPE Atlas measurements reconstruct observed client–ingress–egress resolver chains and show frequent AS, country, endpoint, and provider-level opacity, while out-of-AS placement is consistently associated with higher latency.
- Measurement design: The campaign reconstructs observed client–ingress–egress chains from probe, ingress, and authoritative-facing egress data, but cannot reveal intermediate forwarders or full hidden-path changes.Country and AS attribution use conservative conventions for private or contradicted observations.
- Latency results: Out-of-AS resolvers exhibit higher medians and heavier tails across ICMP RTT and cached DNS lookup measurements for both frontend and egress roles.The paper interprets this as an association with AS-level placement, not proof that geographic displacement causes the latency difference.
- Cross-border resolution: 25.6% of geolocatable public-anycast pairs resolve outside the client country, while the conservative all-pairs rate remains 18.0%.The corresponding counts are 989 of 3,869 geolocatable pairs and 989 of 5,498 scheduled pairs, respectively.
- Endpoint divergence: 91.70% of public-ingress observations expose different ingress and egress IPs, while 40.42% of probe–frontend chains map to multiple egress IPs.NAT, multiple interfaces, egress selection, and forwarding remain indistinguishable from these endpoint observations.
- Administrative boundaries: 39.8% of Campaign B observations cross the client–frontend AS boundary, and 65.6% do so when restricted to public-ingress observations.These figures establish AS or organizational separation but do not establish an unobserved forwarding hop.
- Provider and destination concentration: Google Public DNS accounts for 67.3% of geolocatable out-of-country anycast frontend cases, and 57.6% of those cases keep egress in ingress’s foreign country.Among 989 out-of-country anycast frontend cases, 570 keep egress in the same foreign country and 264 continue to a third country.
- Interpretive boundary: Country attribution does not establish physical location, legal jurisdiction, or compliance, even when crossings occur within comparable legal regimes.Such crossings can still matter for privacy, governance, data transfers, latency, and CDN selection.
3 Closing the Visibility Gap
RESOLVER-PATH closes DNS’s visibility gap through cooperative disclosure and optional attestation, reporting participating resolvers while preserving incremental deployment. Controlled evaluation finds complete participating-path correctness and near-neutral performance, while non-participation still limits completeness.
- Protocol design: RESOLVER-PATH supports on-demand diagnostics and EDNS-based disclosure during ordinary DNS resolution, with optional attestation; reported paths include only participating resolvers.Technique 1 diagnoses forwarding topology, while Technique 2 accumulates the participating path carried by the selected response.
- Protocol design: EDNS disclosure cannot rely on legacy resolvers to preserve unknown options, so it establishes reported participating hops but not path completeness.Recursive resolvers may ignore or strip the option, and deployment requires a future assignment for prototype code 65024.
- Correctness: 63,042 individual paths and 47,042 selected-response paths matched linked per-resolver events across 185 controlled runs, while all 1,000 partially participating responses were marked incomplete.No sibling- or cross-response merges occurred.
- Performance: Technique 2 incurred a median throughput change of −0.90% and a median p95 latency increase of 2.08% relative to the modified-but-disabled baseline.One forwarding scenario increased CPU utilization by up to 17%, while no median packet loss was observed.
- Performance: At depth 15, throughput changed by only −0.10–0.40%, p95 latency rose from 0.077 to 0.097 ms, and reported-path recovery remained 100% without truncation or TCP fallback.Controlled cache-hit tests found all 17,000 selected-response paths matched current-query events, with no reuse of the cache-populating path.
- Attestation: Attestation binds resolver assertions to the selected response using signatures, a client nonce, canonical question, response digest, response-instance identifier, timestamps, and a hash chain.Signed mode sustained 19.4k–19.7k median QPS at 20,000 offered QPS, with all-load loss below 0.001%; these results do not establish path completeness.
4 Related Work
Prior work measures hidden DNS infrastructure and related steering or interception phenomena, but does not provide per-query evidence of the ordered recursive resolver path. RESOLVER-PATH addresses this gap through cooperative disclosure and optional attestation.
- Prior DNS measurement: Prior measurement identifies ingress, forwarding, hidden, and egress DNS infrastructure but cannot identify resolvers hidden between observed endpoints.This paper inherits that two-vantage boundary while studying outsourcing and cross-border dependencies.
- Path visibility: RESOLVER-PATH returns an ordered sequence of participating recursive resolvers with optional response-bound attestation, unlike X-Trace’s out-of-band task-tree reconstruction.The distinction is whether the DNS response itself carries the reported recursive path.
- Contribution boundary: The paper’s measurement contribution is cross-border and jurisdictional analysis with longitudinal control and identity-first handling of anycast, not the first observation of public-DNS concentration.Prior work has already documented public-DNS dominance and related open-resolver, cellular-DNS, and egress dependencies.
- Related DNS mechanisms: RESINFO describes the contacted resolver’s capabilities, whereas RESOLVER-PATH reports downstream participating hops, their order, and jurisdictional assertions for a particular query.CHAIN concerns DNSSEC delegation material, while NSID and CHAOS TXT identify only a single answering instance.
- Contribution boundary: Resolver forwarding creates a visibility gap analogous to opaque CDN steering, but RESOLVER-PATH’s novelty is cooperative disclosure of the logical resolver path carried by the response.CDN-steering work infers delivery strategies rather than revealing downstream resolvers handling a particular query.
5 Limitations and Ethical Considerations
The measurement study is broad but represents a measured population rather than the Internet as a whole, and the protocol evaluation remains bounded by controlled deployments and incomplete operational coverage.
- Scope of findings: RIPE Atlas overrepresents fixed-broadband networks, while mobile, enterprise, IoT, and VPN-mediated paths are comparatively underrepresented.Probes sharing an AS may also share resolver configuration, so observations are not independent.
- Scope of findings: The reported percentages characterize resolver behavior during the 2023–2025 campaigns rather than immutable Internet-wide constants.Resolver deployments evolve over time, limiting how broadly the measured rates should be generalized.
- Conservative AS attribution: The 39.8% client–frontend AS-mismatch rate conservatively treats unattributable cases as same-AS and retains all 16,636 successful observations.Private ingress lacks a publicly attributable BGP-origin ASN, and 83 observations lacked a client and/or ingress ASN.
- Protocol evaluation: RESOLVER-PATH feasibility was evaluated under controlled deployments across 23 scenario and 32 topology conditions rather than production-scale resolver ecosystems.Production systems may include other stacks, middleboxes, varied fan-out, and higher throughput than the tested 20,000 QPS BIND testbeds.
- Deployment boundary: Disclosure depends on intermediate resolvers implementing and preserving the EDNS option, so ignoring or stripping it truncates the accumulated path.Production-scale RPKA publication and rollover, nonce state, and operational key revocation remain unevaluated.
6 Conclusions
The paper finds frequent cross-organizational and cross-national resolver endpoint divergence and introduces RESOLVER-PATH to expose reported cooperative hops with near-neutral overhead and bounded authentication.
- Conclusions: Observed resolver endpoints frequently cross organizational and national boundaries, with implications for performance, jurisdiction, and infrastructure concentration.Endpoint observations still cannot identify whether divergence reflects NAT, multiple interfaces, egress selection, or forwarding.
- Conclusions: RESOLVER-PATH is a lightweight cooperative disclosure mechanism that exposes the reported resolver path with near-neutral completion throughput in controlled workloads.Its authenticated extension binds received cooperative assertions to the selected response while leaving non-participating hops outside the evidence.
- Conclusions: The method expands observable state for Internet measurement, enabling studies of resolver behavior, infrastructure dependencies, and their evolution over time.These studies are not possible with today’s endpoint-only observations.
- Conclusions: The appendix separates evidence supporting the submitted claims from validation that remains future work.It also records reproducibility, filtering, protocol, attestation, supplementary measurement, geolocation, and ethics details.
B Protocol Security and Privacy Details
The protocol fits within tested EDNS constraints and can coexist with other options, while its privacy and security guarantees are limited to authenticated cooperative assertions rather than complete-path or truth validation.
- Protocol operation: 94.5–98.2 B unsigned Technique 2 responses incurred no truncation or TCP fallback in the tested cases.Validation also confirmed a 36-byte header, 144-byte entries, six-entry limit, and 900-byte maximum option data.
- Protocol operation: ECS and RESOLVER-PATH share the requestor’s advertised EDNS payload budget, and unknown-option stripping can truncate disclosure without affecting normal resolution.Implementations must apply validated TC/TCP behavior rather than exceed the budget or silently delete entries.
- Privacy: The path option reveals resolver identifiers to the client and, in the raw-IP implementation, to the authoritative server.AS-plus-country granularity reduces exposure, but country remains an operator assertion rather than independent location or jurisdiction proof.
- Attestation: Signatures authenticate the integrity and ordering of linked assertions under reported operators’ keys but do not validate those assertions’ truth.The guarantee assumes authenticated key distribution.
- Attestation: The mechanism provides authenticated cooperative assertions, not proof of physical traversal, complete participation, or regulatory compliance.Resolvers can omit themselves, strip the option, replace a chain, or collude under keys they control.
B.1.1 Response-Bound RESOLVER-PATH Wire Specification
RESOLVER-PATH encodes response-bound resolver assertions in a fixed EDNS option and authenticates them with canonical response hashing, chained signatures, and RPKI-backed key authorization. The construction binds reported entries to the selected response and query freshness, while explicitly excluding completeness and non-participating hops from its guarantees.
- Wire format: The EDNS option uses a 36-byte header followed by one to six fixed-width 144-byte entries in network byte order.Queries carry a 16-byte client nonce and zero response identifier; responses carry a nonzero response identifier.
- Wire format: Entries are ordered from the deepest reported participant toward the client, with GAP_BELOW and CACHE_ANSWER indicating limited downstream knowledge rather than path completeness.These flags describe missing usable downstream attestation or local-cache production; neither asserts that all hops are present.
- Canonicalization: The canonical response digest covers the canonical question, response data, status, flags, and response identifier, while excluding transaction and EDNS metadata.The digest is SHA-256 over the complete Resolver-Path response serialization.
- Attestation: Each signature binds the client nonce, canonical question, response digest, identity, flags, key identifier, timestamp, and prior-entry hash into a response-specific chain.RPKI authorization validates the ASN-to-key binding, while the signed country remains an operator assertion rather than independently certified geography.
- Attestation: Fresh 128-bit client nonces and 300-second timestamp checks constrain replay, historical-chain reuse, and response-identifier transplantation.Verification also rejects malformed options and stops after six signature checks and six RPKA lookups.
- Evaluation: Conformance testing covered 18 canonical cases across two independently implemented codebases, while controlled heterogeneous runs verified assertions with about 1.3% full-run throughput reduction.The evaluation reports verification rate 1.0 and zero observed truncation or TCP fallback; throughput deltas ranged from −1.29% to −5.56% across configurations.
C Measurement Accounting and Reproducibility
The measurement record combines campaign manifests, dataset accounting, endpoint-divergence tables, and explicit conservative conventions to make the 2025 analysis reproducible. It preserves the distinction between visible endpoint differences and claims about hidden resolver paths.
- Campaign accounting: 35,586 resolver chains were retained from two 2025 runs, which together produced 35,814 successful results and 3,703 failed or timed-out results.Campaign B supplies the paper’s 16,636-row 2025 cross-sectional coverage base.
- Reproducibility: The reproducibility materials include campaign manifests, dataset labels, filtering populations, and explicit definitions for comparable and divergent endpoint pairs.The tables distinguish public-ingress populations from private-ingress cases where address translation can explain divergence.
- Campaign accounting: Campaign 2025B supplies 16,636 successful rows, with 16,553 in the ASN-complete subset and all 83 ASN-incomplete rows retained as same-AS for the lower bound.The conservative convention therefore treats missing client or ingress ASN information as not crossing the AS boundary.
- Endpoint accounting: Observed IP inequality and /24 divergence establish different visible endpoints, not an additional logical resolver or the number of intermediate hops.Administrative mappings likewise establish endpoint separation rather than an intervening forwarding path.
- Scope boundary: The completed evaluation excludes the operational distribution of ingress- and intermediate-cache-hit path lengths beyond the controlled cache matrix.The paper does not use that unanswered question to support stronger claims.
E Supplementary Measurement Results
Supplementary results provide longitudinal AS-level comparisons, full correctness accounting, and supporting protocol-evaluation records. They retain conservative same-AS treatment and distinguish controlled validation from operational path behavior not measured in the completed evaluation.
- Longitudinal accounting: The longitudinal 2025 row uses the deduplicated union of Campaigns A and B, while the 16,636-row cross-sectional analyses use Campaign B alone.The stable panel contains 2,468 probes present across the 2023, 2024, and 2025 year-level datasets with unchanged client AS and country.
- Longitudinal accounting: The AS-level supplementary tables apply the conservative convention that assigns every private ingress to the client AS.The 2025 full-population client–frontend result also counts 83 ASN-incomplete observations as same-AS.
- Protocol evaluation: Supplementary protocol materials report per-behavior capacity, depth scaling, throughput, resource, and cache figures referenced by the main text.These materials expand the protocol-evaluation results rather than changing the measurement population.
- Correctness evaluation: The final correctness matrix contains 185 required runs, exactly 37 in each of five repetitions, with both strict validators passing all 23 scenario and 32 topology conditions.Three pre-fix failures and two interrupted attempts remain separate from the required-run matrix.
- Correctness evaluation: The controlled evidence contains 49,242 client-query records, 65,242 upstream-response records, and 445,729 timestamped resolver events, with zero uncontrolled qnames.These records support strict transaction-level validation rather than claims of path completeness under arbitrary non-participation.
F.2 Completed Local Performance Matrices
The completed local matrices combine strict controlled validation with performance and geolocation-supporting analyses. They show successful correctness checks and low diagnostic latency, while the geolocation pipeline applies active plausibility checks and conservative fallback rules.
- Completed matrices: Table 24 includes only workloads with final cells; warm cache completed 100/100 repetitions and passed its strict validator.Cold-cache and conditional-forwarding rows are limited to their completed 20-cell matrices.
- Completed matrices: Strict controlled response-path correctness means agreement with linked client-query, upstream-response, and timestamped per-resolver evidence for the same transaction.This validates tested operational behavior, not path completeness under arbitrary non-participation.
- Diagnostic performance: The diagnostic latency fit was 0.2654 ms/hop at p50 and 0.3227 ms/hop at p95, with successful walks recovering configured topology.The walk issued depth+1 queries because it ended with an authoritative lookup; exposed configured hops need not process ordinary queries when answering from cache.
- Geolocation validation: Resolver geolocation combines passive and active measurements, using operator identity strings for public anycast ingress when registration databases may identify corporate headquarters instead of serving PoPs.Private ingress establishes a near-side hop but supplies neither an independently geolocatable address nor a public BGP origin ASN.
- Geolocation validation: Active validation tests relevant ingress and egress addresses with RTT, traceroute, distance, and domestic-hop checks before retaining country attributions as plausibility-consistent.Contradicted attributions are counted as in-country in the full-population analysis and excluded from the stricter subset.
G.1 Additional Geolocation Results
The appendix expands the geolocation analysis to the full 2025 dataset and reports country-level mismatch patterns. It also documents the scope of supporting performance tables and excluded-country inspection.
- Full-dataset geolocation: 16,563 valid probe–frontend–egress country triples show 8.63% probe–frontend mismatch, 17.06% probe–egress mismatch, 18.20% frontend–egress mismatch, and 0.42% three-way mismatch.These figures cover the full 2025 dataset, including chains excluded from the main-text non-anycast egress comparison.
- Supporting performance results: Table 24 reports median completed QPS at 20,000-QPS offered load for separately completed local workload matrices without aggregate claims across unfinished families.The table is explicitly scoped to completed workload rows.
- Supporting performance results: Table 25 reports final warm-cache performance at 20,000 QPS across 20/20 cells and 100/100 repetitions, with signed client verification costing 226.01 µs median.CPU is reported as summed resolver-chain cost.
- Country-level appendix: The complete per-country frontend-selection table covers all 171 observed countries and identifies countries excluded from main-text views by support thresholds.It provides the appendix counterpart to the top-country figures.
H Ethics
The study describes ethical safeguards for both measurement and evaluation, including controlled authoritative queries, anonymized workload data, and aggregate reporting. Supporting materials also delimit the evaluated workloads, geolocation signals, and resolver-chain behavior.
- Measurement ethics: The RIPE Atlas campaign used controlled authoritative domains and aggregate returned IP, ASN, and country metadata without observing third-party traffic.Private ingress was not assigned an operator identity, and Atlas use followed its usage policies.
- Evaluation data: The performance trace came from a ten-minute university DNS capture, anonymized before release and approved for secondary research use.Client identifiers and queried names were removed or anonymized.
- Evaluation safeguards: The Docker evaluation configured its local authoritative service to answer every replay name and released results only at country or AS level.No per-probe identifiers were included in the released dataset.
- Result interpretation: The appendix distinguishes diagnostic-query latency tables from ordinary-query performance and reports cloud-capacity results as medians across five repetitions.These scope statements constrain interpretation of the supporting performance figures.
- Protocol evaluation: Technique 2 recovered paths at 100% of tested depths with zero truncation or TCP fallback.This table reports wire-level depth-scaling metrics at 20,000 QPS.