Who Resolves Your DNS? Measuring Resolver Opacity and Closing the Visibility Gap

Who Resolves Your DNS? Measuring Resolver Opacity and Improving DNS Observability

arXiv:2608.29371v1 [cs.NI] 29 Aug 2026

Kedar Thiagarajan Northwestern University kedarthiagarajan2028@u.northwestern.edu

Fabián E. Bustamante Northwestern University fabianb@northwestern.edu

Abstract

In-country

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 standardized, per-query mechanism to obtain the ordered resolver path. 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 quantify this opacity using RIPE Atlas measurements from 190 countries and then show that it is inexpensive to address. Even under a conservative treatment that assigns unattributable observations to the client’s AS, 39.8% of Campaign B observations (6,622 of 16,636) cross the client– frontend AS boundary. One in four geolocatable anycast frontend pairs resolves outside the client’s country, and Google Public DNS accounts for roughly two-thirds of those out-ofcountry cases. We present R ESOLVER -PATH, which enables participating resolvers to report their identity as they forward queries. We implement resolver-path disclosure in BIND 9, Unbound, and Knot Resolver with near-neutral throughput, latency, and CPU overhead. Because participation is voluntary, disclosure establishes the verifiable presence of reported hops, not the absence of hidden ones. An optional attestation extension authenticates received assertions, ordering, and freshness—not completeness. Together, disclosure and attestation provide bounded evidence about a query’s reported resolver path, giving DNS a transparency mechanism it currently lacks.

1

Venezuela

Russia

Ireland

France

Out-of-country

Unknown

Ingress

21/21

Egress

21/21

Ingress

180/240

Egress

171/240

Ingress

4/14

Egress

10/14

Ingress

23/203

Egress

96/203

0

20

40

60

80

100

Share of anycast pairs (%)

Figure 1: Ingress and egress cross-border rates for anycast resolution in selected countries. In Ireland and France, cross-border egress far exceeds cross-border ingress, a pattern consistent with hidden forwarding or providerinternal egress selection. Section 2.4 presents the full global analysis.

to this query; it is the normal condition of DNS resolution. ISPs increasingly outsource resolution to third-party operators, forwarding queries through resolution structures that can span organizations, Autonomous Systems, and national boundaries, and no standardized, per-query mechanism lets a client obtain the ordered resolver path [47]. 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. The gap carries real consequences. A France-to-Belgium or Ireland-to-UK crossing may remain within broadly comparable European legal regimes [18, 17], but our measurements also show domestic-looking anycast resolution from Colombia egressing in the United States; in those cases, the query is exposed to a different jurisdiction even though the clientfacing resolver appeared local. Such cross-border handling can subject DNS queries to different surveillance, censorship, or data-retention regimes [8, 51]. Out-of-AS resolution is also associated with higher latency in our measurements. Figure 1 previews the scale. Using RIPE Atlas across 190 countries,

Introduction

Consider a DNS query issued by a client—the stub resolver on an end host—in France. It is answered by an anycast public resolver whose client-facing instance sits inside the country: by every signal available to the client, resolution looks domestic. Yet the resolver that actually contacts the authoritative server sits in Finland—the query has quietly left the country, and the client has no way to know. That blindness is not unique 1

we find that one in four geolocatable anycast frontend pairs resolves outside the client’s country, and the two ends of the chain diverge: in Ireland and France, frontend (ingress) resolvers appear mostly domestic, yet the egress observed at our authoritative server crosses borders far more often— consistent with hidden forwarding or provider-internal egress selection, though our vantage observes two endpoints rather than a complete chain. A single operator, Google Public DNS, dominates the out-of-country anycast subset, accounting for roughly two-thirds of those cases. Resolver opacity is thus both common and concentrated. We argue that DNS resolution should be made visible— and show that it can be. We present R ESOLVER -PATH, in which participating resolvers report their identity as they forward a query. We implement this disclosure mechanism in three major resolver implementations with nearneutral overhead; the same information can also be collected through an alternative iterative query mechanism. Because non-participating resolvers may ignore or strip the metadata, deployment is incremental: modified resolvers contribute metadata while non-participants continue resolving as before. The resulting reported path, however, remains unauthenticated. An optional attestation extension authenticates each participating resolver’s contribution by binding every received assertion to the selected DNS response and a fresh client nonce. Our dataset, code, and analysis scripts will be released for replication. We make three contributions:

Figure 2: DNS resolution often spans multiple intermediaries, organizations, and ASes [47].

Atlas platform. This observed chain reveals only the clientfacing ingress resolver and the authoritative-facing egress resolver; it does not expose intermediate forwarders, forwarding depth, policy-dependent fan-out, or cache-dependent path changes in the full hidden forwarding path. The analysis is organized around three research questions: RQ1 How often do observed client–ingress–egress resolver chains cross AS, organizational, and national boundaries, and how has this changed over time? RQ2 Which providers and destination countries dominate out-of-country resolution in observed chains, and what cross-border handling is relevant to further legal or governance review?

• Resolver opacity is widespread. Under the conservative attribution convention, 39.8% of Campaign B observations (6,622 of 16,636) cross the client–frontend AS boundary. This establishes AS separation, not an intervening hop; separate endpoint comparisons expose pervasive address and prefix divergence without identifying the mechanism between them (§2.4).

RQ3 Given the opacity documented by RQ1–RQ2, can lightweight protocol extensions expose more of the hidden forwarding path by reporting a resolver path to clients without degrading resolver performance? Sections 2.1–2.4 address RQ1 and RQ2 by measuring the problem; Section 3 addresses RQ3 by showing that closing this visibility gap is technically inexpensive.

• Resolver-path disclosure is practical. We design and implement an EDNS-based disclosure mechanism in BIND 9, Unbound, and Knot Resolver and show that it incurs near-neutral overhead (§3).

2.1

The methodology identifies mismatches between client-facing and authoritative-facing DNS resolvers by mapping publicly routable addresses to ASes and organizations and applying an explicitly conservative convention to private ingress. Measurement design. All connected RIPE Atlas probes [45] serve as DNS clients. Each probe issues a query for a subdomain under a controlled authoritative domain. Probes perform the resolution using their locally configured (on-probe) resolvers. RIPE Atlas records which resolver IP receives the query and the resulting answer; that resolver IP is the ingress resolver. If a probe is configured with multiple local resolvers or fails over between resolvers, different ingress IPs appear across measurements, but each individual query contributes only one observed ingress resolver. All

• Attestation binds resolver assertions to responses. We specify and evaluate a response-bound hash-chain construction using published conformance vectors across two codebases and signed load tests (§3.4).

2

Methodology and Data Collection

Measuring Resolver Opacity

The conceptual gap motivates a direct measurement question: how often does resolution leave the client’s organization and country, and how concentrated are the responsible providers? The measurement campaign infers the observed client–ingress–egress resolver chain (Fig. 2) using controlled authoritative domains and metadata provided by the RIPE 2

such queries reach the authoritative name server, which returns as its answer the source IP address of the packet that reached it—the egress resolver. This egress endpoint is the authoritative-facing source address, not proof of the exact recursive process that performed every internal lookup behind NAT, forwarding, or provider-internal fan-out. Combining the Atlas-reported ingress IP with the egress IP encoded in the authoritative response reconstructs an observed client–ingress–egress resolver chain for each query. The Atlas API also provides the probe’s IP address, country, and ASN, which associates clients with their access networks. Private-ingress convention. Private ingress supplies neither a public BGP origin ASN nor an independently geolocatable address. Full-population analyses assign it to the client AS for AS comparisons and the client country for country comparisons; the 83 Campaign B rows lacking a client and/or ingress ASN are also counted as same-AS. These choices bias toward same-AS and domestic classifications. The measurement exposes only the ingress and egress endpoints. Exposing hidden intermediate resolvers requires a disclosure mechanism; we propose R ESOLVER -PATH to provide it.

2.2

use private IP addresses rather than refusing ICMP. The 2025 dataset contains 6,713 private-ingress observations (40.4% of 16,636 observations), reported separately to make the fullpopulation denominator explicit. RIPE Atlas probes are predominantly deployed in access networks (Appendix Figure 10), consistent with prior measurements showing that roughly 80% operate within serviceprovider ASes [5, 44]. This placement makes RIPE Atlas well suited to characterize DNS resolution from the perspective of end users. Resolver attribution. Resolver attribution maps each client and each publicly routable ingress and egress resolver IP to its origin AS using RouteViews BGP dumps [50] and to its organization using Borges [48]. This mapping identifies observed AS and organizational boundary crossings. Privateingress labels follow the convention above rather than an operator-ownership inference. Latency measurement. Latency measurement sends three ICMP pings from each client to its ingress and egress resolvers and records the minimum RTT. The AS-stratified latency analysis includes only publicly attributable ingress and egress addresses with known client and resolver ASNs; private ingress is excluded from the frontend population. Within this population, the analysis compares resolvers in the client AS with resolvers in a different AS. Because some resolvers block ICMP, DNS query timing provides a complementary estimate. Each probe performs two successive resolutions of a highly popular domain, maximizing the likelihood that the record is already present in the resolver cache. The second lookup therefore primarily reflects communication between the client and resolver rather than recursive fetch latency. Cache state and resolver behavior may still introduce noise. For intuitive interpretation, the analysis translates measured RTTs into order-of-magnitude path lengths using a fiber propagation speed of approximately c f ≈ 2/3c. These estimates are illustrative rather than literal: Internet paths rarely follow geodesic routes, and queuing, forwarding, and processing delays can all inflate RTT beyond pure propagation delay.

Dataset and Scope

Four collection runs span three years: January 5–9, 2023; August 19–28, 2024; May 29–30, 2025 (Campaign A); and October 1–2, 2025 (Campaign B). Across the three years, 10,082–11,918 unique probes returned results per year across 3,100–3,150 ISPs in 187–190 countries. Campaign-level ASN-completeness filtering retained 23,995, 9,899, 19,033, and 16,553 resolver chains, respectively, for 69,480 retained chains in total. Campaign B supplies the 16,636 successful rows used as the raw 2025 analytical coverage base; analyses then apply the field-specific completeness filters reported in Appendix Tables 12 and 17. Appendix Table 13 summarizes the 2025 entities. The longitudinal analysis instead uses a deduplicated union of Campaigns A and B for its 2025 year-level dataset. Probes are broadly distributed across continents but are concentrated in fixed-broadband and enterprise access networks, with correspondingly less coverage of mobile and VPN users. This repeated multi-year sampling allows us to observe temporal shifts in resolver behavior, including the growing adoption of cloud-based providers. 2.2.1

Geolocation. Resolver geolocation combines multiple complementary signals to identify cross-border resolution. PTR records supply city-level hints extracted with The Aleph framework [49]; the IPinfo database supplies the fallback for resolvers without embedded location hints [26]. RIPE Atlas RTT and traceroute constraints actively test every unicast resolver address whose country is supplied by IPinfo. When those measurements contradict the IPinfo location, the full-population analysis conservatively classifies the observation as in-country rather than as a cross-border mismatch; the stricter plausibility-consistent subset excludes it (Appendix G). For public anycast ingress resolvers, operator-provided serving-site identifiers supply the location signal: Google

Measurement Coverage

Latency was measured using three ICMP pings per probe– resolver pair and DNS resolution timing from successive cached lookups. The campaign geolocated 3,209 ingress and 7,563 egress resolvers with public IP addresses. Frontend RTT coverage is 44.6% (56.1% among known-AS targets); the primary coverage gap is that 51% of ingress resolvers 3

Egress

% of Total

% Conflict

Count

% of Total

% Conflict

TXT records 3,973 23.9% PTRs 632 3.8% IPInfo 5,318 32.0% Private ingress (near-side) 6,713 40.4%

86.6% 3.3% 0.0% –

0 0.0% 3,312 19.9% 13,309 80.0% – –

0.0% 8.2% 0.0% –

–

16,621 99.9%

–

Source

Total geolocated

Count

9,923 59.6%

Frontend Ping

1.0

Frontend DNS

In AS Out of AS Median P95

0.8 0.6

CDF

Frontend

0.4 0.2 In-AS m=2.20 ms, p95=19.71 ms Out-AS m=6.84 ms, p95=54.21 ms

0.0

Table 1: Geolocation sources used for country attribution in the 2025 dataset (N = 16,636 observed resolver chains per side). Methods are applied in priority order (TXT/NSID/CHAOS identity, PTR, then IPInfo), yielding the exclusive attribution shown. Private ingress is reported separately because it is not independently geolocated; complete-population country analyses follow the §2.1 convention.

100

1.0

101

Egress Ping

102

In-AS m=2.80 ms, p95=58.18 ms Out-AS m=8.95 ms, p95=65.66 ms

100

101

Egress DNS

102

0.8

CDF

0.6 0.4 0.2

Public DNS NSID airport-code labels, Cloudflare id.server values, Quad9 NSIDs, and Cisco Umbrella/OpenDNS diagnostic identifiers [20, 11, 10, 42, 9]. These identifiers represent the operator-selected serving site, not the infrastructure’s registration geography. RTT- and traceroute-based validation applies only to unicast addresses because repeated measurements to the same anycast IP may reach different points of presence. Table 30 summarizes the available signals and their agreement with IPinfo. Operator-reported serving sites and IP registration databases capture different properties: the former identifies the serving location selected for a query, whereas the latter reflects registration geography [27]. Table 1 summarizes the country-attribution sources used throughout this section. Public anycast frontend location is derived primarily from operator-reported serving-site identities, whereas egress location is derived primarily from actively validated PTR/IP geolocation. Private ingress is reported separately as a near-side category and is not independently geolocated. For Cloudflare, location information is obtained from CHAOS TXT id.server responses rather than NSID. Cloudflare confirmed in private correspondence with the authors that, under normal operation, id.server identifies the colo performing recursion. During overload, provider-internal forwarding can instead cause that client-facing identity to differ from the recursive egress. We therefore treat id.server as an operator-confirmed ingress-serving-site indicator, not evidence of a complete forwarding path. When an ingress IP belongs to a known anycast resolver, ingress country is determined in the following order of precedence: (i) NSID or id.server, (ii) Aleph-derived location, and (iii) the probe country when neither source provides a location. Anycast ingress analysis. Each probe–resolver pair constitutes one anycast-ingress observation and contributes to the geolocated subset only when the resolver exposes an identity string that maps to a documented serving site. Multiple probes may observe the same resolver and anycast site, so reported percentages are descriptive population shares rather than inferential estimates. Egress geolocation excludes anycast IPs because a single

0.0

In-AS m=3.67 ms, p95=27.03 ms Out-AS m=11.59 ms, p95=61.90 ms

10 1

100

101

RTT (ms)

102

In-AS m=6.28 ms, p95=62.98 ms Out-AS m=12.12 ms, p95=98.64 ms

100

101

RTT (ms)

102

103

Figure 3: Latency to same-AS and out-of-AS resolvers. The four panels compare publicly attributable, AS-classified frontend and egress resolvers using ICMP RTT and cached DNS lookup time; private ingress is excluded from the frontend comparison. In every panel, the out-of-AS category exhibits higher medians and heavier tails.

anycast address may represent multiple serving locations. The remaining egress population is overwhelmingly unicast, allowing standard IP geolocation after the active consistency checks described above. Anycast egress addresses represent only about 1% of unique egress IPs; excluding them removes 1,438 of 16,563 valid probe–frontend–egress country triples used in the observed-population analysis (Appendix G.1).

2.3

Latency Results

The latency analysis compares same-AS and out-of-AS resolvers using both ICMP RTT and cached DNS lookup time for the frontend and egress roles. Both comparisons are restricted to publicly attributable resolver addresses with known client and resolver ASNs; private ingress is excluded from the frontend latency population. Across both measurement methods and both resolver roles, the out-of-AS category consistently exhibits higher latency. Figure 3 shows a remarkably consistent pattern. Regardless of whether latency is measured using ICMP RTT or cached DNS lookup time, and regardless of whether the resolver is the frontend or the egress, out-of-AS placement shifts the latency distribution toward higher values. Median latency approximately triples for frontend ICMP measurements (2.20 vs. 6.84 ms) and increases similarly for frontend DNS lookups (2.80 vs. 8.95 ms). Comparable shifts appear for egress resolvers (3.67 vs. 11.59 ms ICMP; 6.28 vs. 12.13 ms DNS), with consistently heavier latency tails. The association is consistent across measurement methods and resolver roles, and holds when stratifying by probe continent (higher medians in 22/24 comparisons, higher p95 in 14/16 well-sampled strata). The agreement between ICMP RTT and cached DNS lookup time increases confidence that the observed latency differences reflect resolver placement 4

Takeaway (RQ1, country level): The cross-border share is 25.6% among geolocatable public-anycast pairs and a conservative 18.0% when all unresolved pairs are counted as domestic.

rather than artifacts of either measurement method alone. ASlevel mismatch is a proxy for, not equivalent to, geographic distance – two ASes may peer at the same IXP, while one AS may span continents – so the observed differences are interpreted as an association with AS-level resolver placement rather than a proven causal effect of geographic displacement or operator identity.

2.4.2

Takeaway (RQ1, latency): Among publicly attributable, ASclassified frontend and egress resolvers, out-of-AS placement is consistently associated with higher latency: out-of-AS resolvers exhibit higher RTTs, higher cached DNS lookup times, and heavier latency tails.

2.4

Endpoint divergence. In Campaign B, 91.70% of publicingress observations (9,103/9,927) expose different ingress and egress IPs; 83.57% of comparable IPv4 observations (6,078/7,273) place them in different /24s. This establishes endpoint and prefix divergence, not distinct operators or an intervening hop; NAT/SNAT, multiple interfaces, egress selection, and forwarding remain indistinguishable. Appendix Tables 14–16 give complete campaign and population accounting.

Resolver Boundary Crossings

Throughout this section, frontend denotes the client-facing resolver (called ingress in the methodology), while egress denotes the resolver that contacts the authoritative server. We begin with country-level observations, then examine AS and organizational boundaries, identify the principal destination countries and providers, and finally study how these patterns evolve over time. 2.4.1

Resolver endpoints diverge and cross administrative and national boundaries

AS-boundary crossing. Under the §2.1 convention, 6,622 of 16,636 Campaign B observations (39.8%) cross the client– frontend AS boundary (Appendix Table 21). This is a lower bound, not an ownership claim about unattributable observations, and it does not establish an unobserved forwarding hop. Restricting the analysis to public ingress removes the ambiguity introduced by private resolvers. Under this restriction, 6,480 of 9,877 public-ingress observations (65.6%) have client ASN ̸= frontend ASN. At the organization level, 6,206 of 9,773 classified observations (63.5%) belong to different client and frontend organizations. Endpoint variability reinforces this opacity: 40.42% of (probe_id, frontend_IP) chains map to multiple egress IPs and 6.73% to multiple egress ASNs. This is consistent with forwarding or provider-internal selection without distinguishing them, motivating standardized per-query path reporting.

Cross-border resolution is common

We begin by asking how often observed resolver chains leave the client’s country. We first consider public anycast frontend resolvers, which provide the strongest serving-site geolocation signals, and then compare them with the full observed resolver population. Figure 4 compares public-anycast frontends and all observed resolver chains for the 15 probe countries with the highest mean cross-border frontend rate among the 29 countries meeting the minimum thresholds of 25 anycast chains, 100 observed resolver chains, and 15 unique probes. Figure 4 shows that cross-border frontend resolution is common among public anycast resolvers. Across the full 2025 dataset, probe–frontend mismatch occurs in 1,430 of 16,563 chains (8.63%). For public anycast, 989 of 5,498 scheduled probe–resolver pairs (18.0%) geolocate outside the client country; among the 3,869 pairs with usable serving-site geolocation, the share rises to 25.6%. Even under the conservative assumption that every unresolved anycast pair remains in-country, nearly one in five frontend resolutions cross national boundaries. Egress mismatches remain common in the broader dataset: probe–egress mismatch occurs in 2,826 of 15,125 nonanycast-egress chains with known egress country (18.7%), and the corresponding full observed-population rate is 17.06% over all 16,563 valid probe–frontend–egress country triples, conservatively treating every IPinfo attribution contradicted by active checks as in-country.

2.4.3

Cross-border resolution is concentrated

Having established that cross-border resolution is common, we next examine where cross-border queries terminate. Figure 5 summarizes their destination countries. For thirdcountry cases, attribution uses foreign egress country only. Among the 989 out-of-country anycast frontend cases, 570 (57.6%) keep egress in the same foreign country as ingress, 264 (26.7%) continue to a third country, and 155 (15.7%) remain in the residual Ingress Out category because the egress lacks usable geolocation. The rightmost panel extends the analysis to all observed resolver chains, showing the distribution of foreign egress destinations for the same set of countries. In this selected set, 1,233 of 3,609 observed chains (34.16%) have out-of-country egress. The largest egress destinations are DE (240, 19.46%), SG (191, 15.49%), FI (190, 15.41%), BE (124, 10.06%), and PL (121, 9.81%). The ten plotted destination columns together 5

Probe Country

Anycast Frontend

CH CA FI BE FR GR CZ AT DK ID RO BG UA RU PH 0%

20%

40%

All Resolver Chains

60%

80%

Share of All Chains

Domestic

100% 0%

20%

40%

Frontend Structure I In, E Out Bounce Back

Ingress Out

60%

80%

Share of All Chains

100%

I Out, E Third

I Out, E Same

Anycast Frontend

65.4

71.4

40.7

All Resolver Chains -- Egress

All Resolver Chains 27.5

57.8

33.0 60.6

60

31.7 41.7

41.7

27.3

50

27.3

% of All Chains

44.7

70

71.4

27.5

63.0

40

27.8 38.6

30

55.0 31.2 37.1

20

43.6

10 TW

NL

IT

Foreign Destination Country

US

PL

SE

BE

FI

SG

DE

TW

NL

IT

Foreign Destination Country

US

PL

SE

BE

FI

SG

DE

TW

NL

IT

Foreign Destination Country

US

PL

SE

BE

FI

0 SG

PH RU UA BG RO ID DK AT CZ GR FR BE FI CA CH

DE

Probe Country

Figure 4: Frontend structure for the top 15 selected countries. Left: public Anycast Frontend. Right: All Observed Resolver Chains under the §2.1 convention. Bars are normalized by all observed chains per probe country and partitioned into Domestic, Ingress Out, Bounce Back, I In/E Out, I Out/E Same, and I Out/E Third. Key takeaway: public-anycast frontends exhibit substantially higher cross-border shares than the general observed-chain population.

Figure 5: Foreign-destination heatmap for the countries in Figure 4. Cells report the percentage of all chains for that probe country. Key takeaway: cross-border queries concentrate in a small number of regional hubs (notably DE, FI, SG), reflecting the geographic footprint of major public DNS providers.

cover 1,097 of 1,233 out-of-country egress cases (88.97%), with the remaining 136 (11.03%) aggregated in Other. We next ask which providers are responsible for these crossborder events. Figure 6 summarizes the provider mix. Across all 3,869 geolocatable anycast frontend chains, Google Public DNS accounts for 52.66%, Cloudflare 32.75%, Quad9 14.07%, and OpenDNS 0.53%. The out-of-country subset is substantially more concentrated: Google Public DNS represents 67.3% of geolocatable out-of-country frontend cases, compared with 52.66% overall, while Cloudflare and Quad9 account for 20.6% and 11.4%, respectively. In contrast, provider shares are more evenly distributed among out-ofcountry egress mismatches in the full observed population.

quences of any crossing depend on the relevant actors, transfers, jurisdictions, safeguards, and applicable law. Neither an operator-reported country label nor our geolocation pipeline establishes physical location, legal jurisdiction, or compliance. Intra-EU, EEA, and adequacy-jurisdiction crossings can still matter for privacy, governance, data transfers, latency, and CDN selection [40]. Takeaway (RQ2, continued): The measurements expose cross-border handling relevant to legal and governance review; they do not decide the review’s outcome or verify regulatory compliance. 2.4.4

Takeaway (RQ2): Cross-border anycast frontend resolution is highly concentrated. Google Public DNS accounts for twothirds of geolocatable out-of-country anycast frontend cases, and most foreign resolution terminates in a small set of regional hubs (DE, FI, SG). In most cases the egress endpoint remains in the same foreign country rather than returning to the client’s jurisdiction.

Longitudinal evolution and implications

The preceding analyses provide a snapshot; we next ask whether these patterns evolve over time. The longitudinal analysis uses a strict stable panel of 2,468 probes that appear in each of the three year-level datasets and remain in the same client AS and country. The 2025 year-level dataset is the deduplicated union of Campaigns A and B. All longitudinal results are reported under the §2.1 convention; within each year-level dataset, each probe is given total weight 1, divided across its observed resolver chains. Appendix Table 18 reports the resulting shares. Even within this controlled panel, fully same-AS observed chains decline from 41.5% in 2023 to 37.9% in 2025,

Geographic grouping and legal interpretation. The 989 out-of-country anycast frontend pairs are also grouped by an EU/EEA-and-adequacy scope in Appendix Figure 14. This is a descriptive geographic grouping, not an “EU-equivalent” legal classification. Observed country pairs identify candidate cases for further legal or regulatory review, but the conse6

Probe Country

Anycast Frontend

PH RU UA BG RO ID DK AT CZ GR FR BE FI CA CH

All Resolver Chains (Egress)

All Resolver Chains n=13 n=183 n=48 n=2 n=25 n=17 n=22 n=43 n=8 n=15 n=24 n=28 n=8 n=18 n=8

0%

20%

Google

40%

60%

80%

Provider Share of Out-of-Country Frontend Mismatches

Cloudflare

100%

n=16 n=193 n=51 n=3 n=26 n=21 n=23 n=53 n=15 n=15 n=67 n=30 n=30 n=30 n=13

0%

OpenDNS

20%

40%

60%

80%

Provider Share of Out-of-Country Frontend Mismatches

Quad9

Provider

WoodyNet

100%

n=190 n=312 n=96 n=50 n=50 n=35 n=28 n=80 n=80 n=27 n=203 n=12 n=15 n=55 n=40

0%

20%

i3D.net

40%

60%

80%

Provider Share of Out-of-Country Egress Mismatches

Datacamp

100%

Other

Figure 6: Provider mix for selected countries with shared row order: (left) public Anycast Frontend, (middle) All Observed Resolver Chains frontend mismatches, (right) All Observed Resolver Chains egress mismatches. Private ingress has no independently attributable provider identity. Key takeaway: Google Public DNS dominates the geolocatable out-of-country public-anycast frontend subset (67.3%), while egress mismatches are more evenly distributed across providers.

while different-AS ingress increases from 35.5% to 42.1%, different-AS egress from 39.6% to 43.9%, and chains exhibiting both from 16.5% to 23.9%. The directional result survives composition control under the §2.1 convention.

To address this limitation, we introduce R ESOLVER -PATH, a cooperative protocol for disclosing resolver forwarding behavior. The protocol supports both on-demand diagnostics and in-band disclosure during ordinary DNS resolution, with an optional attestation extension. Throughout this section, a reported resolver path contains only participating resolvers.

Takeaway (RQ1, longitudinal): Controlling for probe composition preserves the observed shift away from fully sameAS resolver chains from 2023 through 2025. Under the §2.1 convention, the increase in different-AS ingress is a lowerbound trend. Taken together, these results show that resolver behavior frequently crosses administrative and national boundaries and that these patterns are becoming more common over time. These findings have implications for ISPs, regulators, and resolver operators. ISPs should audit whether their configured resolvers forward queries across organizational and national boundaries: the public-anycast and egress observations expose candidate cross-border handling, while the AS lower bound shows pervasive boundary crossing under the §2.1 convention. Regulators and auditors can use authenticated operator assertions as one input to compliance review, but the protocol neither proves physical or legal jurisdiction nor verifies regulatory compliance. Resolver operators already expose single-hop identities (e.g., NSID and id.server) for operational debugging. RESOLVER-PATH extends this practice to the participating resolver path, supporting transparency, auditing, and standardized disclosure with negligible measured overhead.

3

3.1

Resolver-Path Disclosure Mechanisms

R ESOLVER -PATH provides two complementary disclosure mechanisms. Technique 1 is an on-demand diagnostic that allows clients to inspect reported forwarding behavior explicitly. Technique 2 integrates resolver-path disclosure into ordinary DNS resolution through an EDNS option, enabling continuous reporting during normal query processing. Figure 7 illustrates both mechanisms. We define a response path as the ordered participating resolvers whose processing contributed to one DNS response. A query may produce several upstream attempts or responses; each response retains its own path, and the client ordinarily observes only the path carried by the selected response. Attempts that produce no response, discarded losing responses, and non-participating resolvers are outside this construct. An ingress cache hit has path length one, while a hit at the kth participating resolver terminates that response path at length k. A cache answer constructs fresh current-response metadata for the client’s nonce and never reuses the path or signatures from the transaction that populated the cached RRset. Technique 1: Recursive DNS Query Tracing This technique provides an on-demand diagnostic of the reported forwarding topology. A client walks the resolver chain by querying each participating resolver for its reported next hop using a new recursive query type (TYPE65400). Because this diagnostic is independent of an ordinary lookup, it may reveal a configured next hop that a cache-hit query would not traverse, and conditional forwarding or failover policy may select a different downstream resolver. TYPE65400 uses an experimental/private-use codepoint rather than a proposed permanent assignment. Technique 2: EDNS Resolver-Path Disclosure Technique 2 uses a new EDNS option (code 65024) to report the participating path carried by an ordinary DNS response.

Closing the Visibility Gap

Section 2 showed that resolver endpoints frequently cross AS, organizational, and national boundaries and that client-facing and authoritative-facing endpoints widely diverge. These properties evolve over time, yet endpoint observations cannot distinguish NAT, multiple interfaces, egress selection, or forwarding; the logical path between them remains opaque. This limitation is architectural: existing identity mechanisms— including NSID [4] and CHAOS TXT records—are fundamentally single-hop, allowing a client to identify only the resolver it directly contacts. 7

The unsigned disclosure implementation appends identity before forwarding and returns the accumulated list with the response; signed mode instead binds a return-path chain to the selected response (§3.4). Because EDNS is hop-by-hop under RFC 6891, recursive resolvers are not required to preserve unknown options. Consequently, Technique 2 reports only participating resolvers and cannot rely on arbitrary legacy deployments to propagate the option. Code 65024 is a prototype assignment; deployment would require DNSOP discussion and IANA Expert Review. Techniques 1 and 2 serve complementary operational purposes. Technique 1 supports explicit diagnostics by walking the reported forwarding topology through dedicated queries, whereas Technique 2 continuously reports the participating resolver path during ordinary query processing without additional client probes. Technique 2 therefore provides routine transparency during ordinary resolution.

3.2

unique hostnames, of which 24,413 (23%) are locally managed. Before replay, query-source identifiers and qnames were anonymized. The authoritative side is configured to answer every replay name locally, so the benchmark does not send those names to external authoritative services. Experiments span cloud deployments, controlled local testbeds, and heterogeneous resolver chains. Cloud evaluation compares four BIND configurations: (i) vanilla BIND, (ii) a modified-but-disabled baseline that isolates implementation overhead, (iii) Recursive DNS Query Tracing (Technique 1), and (iv) EDNS Resolver-Path Disclosure (Technique 2). Because Technique 1 operates as an explicit diagnostic rather than during ordinary query processing, the performance analysis focuses on Technique 2; Technique 1 is evaluated separately. For Technique 2, an EDNS-aware client records wire-level metadata (hop lists, response sizes, truncation, and TCP fallback). Each experiment isolates a different aspect of the design: cloud deployments measure performance under realistic workloads, local testbeds evaluate scalability with resolver depth and cache behavior, and heterogeneous deployments verify interoperability across resolver implementations. Unless noted otherwise, the results below apply to these configurations, workloads, and participating resolvers; they do not estimate Internet-wide performance, path-length, or deployment distributions.

Prototype

We implement both disclosure mechanisms in BIND 9, Unbound, and Knot Resolver. The implementations preserve each resolver’s existing forwarding and caching behavior while adding support for reporting resolver identity and propagating resolver-path metadata. The Technique 1 prototype adds support for TYPE65400 queries, allowing participating resolvers to return their identity and reported next hop. The prototype requires 427 lines of code across six BIND files. Technique 2’s prototype adds EDNS option 65024 processing, allowing participating resolvers to accumulate resolverpath metadata during ordinary query forwarding. The BIND implementation requires 153 lines of code across two files. Equivalent functionality is implemented in Unbound and Knot Resolver.

Response-path correctness. Across 185 controlled runs spanning 23 scenarios and 32 topologies, validators compared each disclosure with linked per-resolver events. Every fully participating path matched: 63,042 individual and 47,042 selected-response paths. The P1 condition marked all 1,000 partially participating responses incomplete, and no siblingor cross-response merges occurred. Appendix Table 23 gives the condition-level accounting. Cloud Performance We measure the performance impact of the EDNS Resolver-Path disclosure mechanism (Technique 2) using BIND on AWS EC2 c7i.large instances (2 vCPUs, 4 GiB RAM) across Ireland, London, and Germany. The experiments span five path behaviors, four BIND configurations (vanilla, modified-tracing-disabled, Technique 1, and Technique 2), offered loads from 2,000–20,000 QPS, and five repetitions per operating point. Table 2 summarizes cloud-capacity results. At 20,000 QPS, vanilla BIND completes 5,075–18,085 QPS across behaviors, with p95 latency between 13.3 and 60.4 ms. The modified-butdisabled baseline remains statistically close to vanilla (median throughput delta −1.32%, median p95 delta 0.00%). Relative to that baseline, Technique 2 incurs a median throughput change of only −0.90% and a median p95 latency increase of 2.08%. Resolver CPU increases by up to 17% in the Ingress Out/Egress Third scenario. No median packet loss is observed; saturation manifests only as reduced throughput.

Measurement Instrumentation. An EDNS-aware client records Technique 2 wire-level metadata, including the returned hop list, response size, truncation, and TCP fallback. As an experimental control, we also evaluate a modified-butdisabled configuration in which all implementation changes are present but resolver-path disclosure is disabled. This allows us to separate the cost of the additional code paths from the cost of carrying resolver-path metadata.

3.3

Evaluation

We evaluate R ESOLVER -PATH’s (i) throughput and latency overhead, (ii) scalability across resolver depths and heterogeneous deployments, and (iii) correctness of reported-path recovery. Experimental Setup All experiments use the same replay of a university DNS trace from a peak 10-minute interval at 2 p.m. The trace contains 2,616,894 queries to 106,102

Takeaway (RQ3, cloud performance): Technique 2 adds negligible throughput and tail-latency overhead; one forward8

R1

R2

R3

ingress

forwarder

egress

Client

Client

TYPE65400 to R1

R1

R2

R3

ingress

fwd

egress

Q + opt[] Q + opt[R1 ]

next=R2 , path[R1 ]

path builds forward

Q + opt[R1 ,R2 ]

TYPE65400 to R2 iterative client probing

Auth

Q + opt[R1 ,R2 ,R3 ]

next=R3 , path[R1 ,R2 ]

R + path[R1 ,R2 ,R3 ] R + path[R1 ,R2 ,R3 ]

TYPE65400 to R3 reported path returns

next=∅, path[R1 ,R2 ,R3 ]

R + path[R1 ,R2 ,R3 ] R + path[R1 ,R2 ,R3 ]

(a) Technique 1: on-demand TYPE65400 diagnostic. The client walks each resolver’s reported next-hop topology, which need not equal an ordinary cache-hit path.

(b) Technique 2: unsigned EDNS Resolver Path Tracing (option 65024). Each resolver appends its identity before forwarding the normal query. This panel shows disclosure only; response-bound attestation signs after responses exist (Appendix Figure 9).

Figure 7: Unsigned resolver disclosure. Technique 1 (left) walks reported forwarding topology with dedicated probes. Technique 2 (right) accumulates the participating path of an ordinary forwarded query. Dashed arrows indicate responses; signatures are not shown here. Table 2: Cloud-capacity summary at a 20,000 QPS offered load on 2-vCPU c7i.large BIND testbeds (medians over five repetitions). Technique 1 is omitted because it operates as an explicit diagnostic rather than during ordinary query processing. Full load-sweep curves appear in Appendix Figures 11a and 11b; per-behavior detail in Appendix Table 26. p95 latency (ms)

recovery with little overhead as resolver depth increases. Completed local workloads. To measure warm-cache overhead, we ran all 20 mode/load conditions with five repetitions each (100 runs). At a 20,000-QPS offered load, signed mode completed 19,993.933 QPS versus 19,999.633 QPS for baseline, while p95 latency rose from 0.017 to 0.127 ms, chain CPU from 13.124 to 76.135 µs/query, and wire volume from 127 to 309 bytes/query. Median client verification cost was 226.01 µs. Separate 20-condition experiments tested cold-cache and conditional-forwarding behavior; their signedmode median completion rates at 20,000 offered QPS were 19,999.899 and 17,633.980 QPS, respectively. Appendix Tables 24 and 25 report the completed workload results.

CPU (µs/q)

Behavior

Van.

Off

T2

Van.

Off

T2

Domestic Egr. Out Ingr. Out/Same Ingr. Out/Third Bounce Back

13.3 44.0 14.6 60.4 51.2

12.3 44.0 15.4 60.4 53.2

12.5 44.0 14.6 62.5 55.3

216 313 359 454 447

239 246 378 452 428

207 352 389 531 469

ing scenario increases CPU utilization by 17%. Resource Costs. Technique 2 adds little resource overhead. Relative to the vanilla baseline, CPU utilization ranges from −4% to +17% (Table 2, right), memory remains within 2 MB, and wire-level response sizes stay between 94.5 and 98.2 B with zero truncation or TCP fallback. Scalability We evaluate scalability in a local Docker testbed by varying resolver-chain depth (2–15 resolvers) at a 20,000 QPS offered load and cache state (warm/cold) at a 10,000 QPS offered load, with five repetitions per configuration. Technique 2 scales cleanly with resolver-chain depth and cache behavior. Throughput changes by only −0.10–0.40% as chain depth increases (Appendix Figure 12a), while p95 latency rises modestly from 0.077 to 0.097 ms at depth 15. Reported-path recovery remains 100% at each forwarded depth, with zero truncation or TCP fallback. Controlled cache hits tested termination and historical reuse: all 17,000 selected-response paths matched currentquery events, and none reused the path that populated the cached RRset. Takeaway (RQ3, scalability): Technique 2 preserves path

Heterogeneous Deployments We evaluate interoperability across resolver implementations using depth-3 chains composed of BIND, Unbound, and Knot Resolver. Four topologies are considered: homogeneous BIND (B-B-B), B→U→B, B→K→B, and B→U→K. Each resolver runs native R ESOLVER -PATH support rather than simply forwarding an unknown EDNS option. Table 3 shows that all topologies maintain sub-millisecond p95 latency while achieving 100% reported-path recovery. Under both warm- and cold-cache conditions, packet loss remains ≤0.01% (Appendix Figure 13). Takeaway (RQ3, interoperability): Technique 2 maintains correct resolver-path accumulation and negligible performance overhead across heterogeneous resolver implementations. Recursive DNS Query Tracing (Technique 1). We evaluate Recursive DNS Query Tracing as an on-demand diagnostic rather than as part of ordinary query processing. Across all cloud topologies and Docker depth configurations, 9

Table 3: Heterogeneous depth-3 summary at a 20,000 QPS offered load in the local Docker testbed (medians over five repetitions). CPU is the summed resolver-chain cost in µs/query, excluding the authoritative server. The final column shows Technique 2 wire-level recovery as positive-path rate / conditional path length. p95 latency (ms)

CPU (µs/q)

R2

Q + EDNS65024 (n) Q + EDNS65024 (n)

observe response R fresh rid, digest create SigR 2

T2 path

Topology

Off

T1

T2

Off

T1

T2

rate / len

B-B-B B-U-B B-K-B B-U-K

0.024 0.083 0.024 0.095

0.019 0.019 0.022 0.022

0.026 0.077 0.028 0.091

15.2 18.8 14.6 20.2

11.5 11.6 12.7 12.8

16.2 18.0 18.2 19.9

100% / 3.0 100% / 3.0 100% / 3.0 100% / 3.0

R + chain[R2 ]

select R; verify chain append SigR 1 R + chain[R2 , R1 ] verify nonce, digest, links, and signatures

Technique 1 successfully completed every diagnostic walk (200/200 in each configuration). Its latency reflects the dedicated sequence of diagnostic queries and is therefore not directly comparable to ordinary-query performance. Complete per-hop and depth results appear in Appendix Tables 28 and 29. Diagnostic and ordinary-response paths differed in 4,000/7,000 paired trials (57.14%); we therefore report them separately.

Implemented: EDNS wire format, signing, chain verification, and private-hierarchy RPKA validation. Deployment work: production RPKI publication and operation.

Figure 8: Signed EDNS return path for Technique 2 (option 65024). The client supplies a fresh nonce; after R2 observes response R, it creates a fresh response identifier and digest and signs its entry. R1 selects that response, verifies the downstream chain, and extends it before the client verifies the received assertions.

standardizing the RPKA object type and publishing it through production repositories (Appendix B.1.1).

Takeaway (RQ3): Technique 2 reports the selected-response path with near-neutral throughput; Technique 1 separately diagnoses reported forwarding topology.

3.4

R1

Client

Evaluation. Wire and transport validation covered zero through six entries over IPv4 and IPv6, comparing serializer lengths with packet captures. Appendix Table 9 reports exact sizes, budgets, and verification work; Appendix Table 8 reports cross-implementation conformance. Two standalone, separately implemented codebases consumed the 18-case published specification vector suite for five repetitions: Go using standard-library Ed25519 and Python using cryptography Ed25519. Neither imports the production implementation or vector generator. Across 180 implementation decisions, all 18/18 vectors were evidence-ready; the codebases agreed on 90/90 paired verdicts and 85/85 signer-applicable canonical signatures, and recorded 180/180 agreements with the published expected state, parser/serializer result, and canonical hash. Every decision links to a client event, a separate implementation log, and one of 180 packets in 5 PCAPs. Canonical re-signing matched 130/170 signerapplicable presented payloads; the 40 expected non-matches are the removed-entry, reordered-entry, modified-entry, and copied-signature mutation vectors. This establishes agreement between the two codebases for the published vectors, not provenance from independent human teams or authors. Across 240 runs covering 48 conditions, all 1,840 packet captures and 1,600 linked event sets matched. At a 1,232-byte UDP payload, signed depth-eight and depth-15 cases used TCP in 10/55 and 45/125 cases per IP family, respectively; Appendix B.1.1 gives the condition-level accounting. Validation confirmed a 36-byte header and 144-byte entries, with option sizes 36 + 144h bytes (40 + 144h including the EDNS option header) for h = 0, . . . , 6. IPv4 and IPv6 had identical DNS-layer sizes. At six entries, the option contains 900 bytes of data and is 904 bytes in full, bounding work at six Ed25519 verifications and RPKA lookups. Captures confirmed TC/TCP fallback for responses exceeding the UDP

Path Attestation

Disclosure reveals what participating resolvers report, but not whether those reports are authentic. Attestation turns unsigned disclosure into authenticated cooperative resolver disclosure: participating resolvers sign after observing the response they return. The hash chain binds each received assertion to the client nonce, canonical question, response digest, and response-instance identifier. The client can verify the signatures on received entries, intact hash-chain order, and satisfaction of the nonce and timestamp checks. Table 4 is the canonical detailed threat and guarantee boundary. Design. The response producer creates a fresh identifier, canonicalizes the question and selected response, and signs its digest only after observing the response. Each upstream participant verifies the selected response’s downstream chain and appends its claimed ASN and country, timestamp, and prior-entry hash. Ed25519 covers both assertion fields; RPKI authorizes only the ASN-to-key binding. Appendix B.1.1 specifies the bytes, and Appendix Figure 9 expands the fanout, retry, sibling, and cache rules summarized in Figure 8. Attestation follows the response-path semantics defined above. A participant receiving an unattested response may start a gap-marked partial chain, and the client distinguishes valid, invalid, unattested, and unknown/revoked-key evidence. The implementation signs every entry’s ASN and country and validates ASN-to-key authorization using an RPKI object under a private test trust anchor and the standard CMS profile [33]. Validation covers the trust-anchor chain, current manifest and CRL, certificate resource coverage, validity interval, and key identifier. Production deployment requires 10

Property

Guarantee

Boundary

Authenticated assertions

Yes

Signed-entry ordering Freshness

A valid signature authenticates the assertion made under a reported participating operator’s key; it does not establish that the asserted identity or country is true. Verification fails when received signed bytes or intact hash links are changed.

Bounded

modification/re- Detectable

Omitted entries or non- No participating hops Stripping or arbitrary removal No False country, execution location, or physical traversal Collusion Path completeness / regulatory compliance

Query/nonce/timestamp binding rejects the tested stale or mismatched replays; nonce-reuse detection requires verifier state. A resolver can decline to append, and hidden hops need not preserve the option.

No

Internal removal before a later intact entry can break a hash link, but suffix, whole-chain, or replacement stripping is not generally detectable. The signature authenticates the operator’s assertion, not the assertion’s external truth.

No No

Colluding operators can coordinate assertions under keys they control. The mechanism supplies audit evidence; it neither proves completeness nor decides legal compliance.

Table 4: Threat and guarantee summary for authenticated cooperative resolver disclosure.

budget while preserving the complete chain (Appendix Table 9). Per-entry Ed25519 signing was 36.8–37.1 µs p50 and verification 93.4–95.2 µs p50. Direct depth-two verification took 149 µs p50 and 158 µs p95 over ten iterations. To measure throughput as load and reported-path depth increased, we ran five 300-second repetitions for every combination of depths 2, 3, and 5, baseline/unsigned/signed modes, and ten offered loads from 2,000 to 20,000 QPS: 450 runs and 37.5 measured hours. At 20,000 offered QPS, median signed throughput was 19.7k, 19.5k, and 19.4k QPS at depths 2, 3, and 5, respectively. Across all loads, signed loss remained below 0.001%; the maximum was 1,595 losses across 163.4 million queries at depth 5 (Appendix Table 10). A separate CPU/latency experiment ran at 2,000 QPS; completed heterogeneous runs reported verification rate 1.0 and no observed truncation or TCP fallback.

methodology cannot identify resolvers hidden between observed ingress and egress; the measurement in this paper inherits that boundary. Liu et al. compared the resolver a client intended to contact with response and authoritative-side signals to detect on-path DNS interception [35]. The measurement here likewise uses controlled queries and authoritative observations, but studies outsourcing and cross-border dependencies rather than treating this two-vantage construction as new. DNSRoute++ exploits transparent forwarding to extend TTL-limited probes beyond a forwarder and reveal the network-router path toward its recursive resolver [39]; it neither enumerates a logical chain of recursive resolvers nor provides authenticated resolver identities. These approaches reveal opacity from outside. R ESOLVER -PATH instead asks participating resolvers to disclose the logical resolver path used by a query. Follow-up measurements cover open resolvers [1, 2], cellular DNS [46], egress dependencies [37], and open-DNS clustering [54]. Public-DNS dominance is also well documented [7, 15, 24, 38]. The Google concentration result is therefore motivational and partly confirmatory; the measurement contribution is its cross-border and jurisdictional analysis, stable-panel longitudinal control, and identity-first handling of anycast.

Takeaway (RQ3, attestation): R ESOLVER -PATH’s wire behavior matched the validated model, signed mode sustained 19.4k–19.7k median QPS at 20,000 offered QPS with all-load loss below 0.001%, and the standalone Go and Python codebases agreed throughout the published-vector experiment. These results do not establish path completeness. Privacy considerations. The design adds no extra queries and defaults to AS and country identifiers to avoid exposing per-resolver topology. Appendix B gives additional detail on amplification, ECS coexistence, and infrastructure exposure.

4

Information for selection versus evidence of a chain. RESINFO is the closest selection-oriented DNS standard: a contacted resolver self-publishes capabilities, such as QNAME minimization and supported extended errors, for clients to use in resolver selection [43]. RESINFO describes that resolver, not the downstream resolvers used for a particular query. CHAIN also returns additional material in one DNS exchange, but its “chain” is the DNSKEY, DS, and related RRsets needed to validate an authoritative DNSSEC delegation, not a chain of recursive operators [53]. NSID [4] and CHAOS TXT records [25] identify a single answering instance. In contrast, R ESOLVER -PATH carries disclosures about the identities, jurisdictional assertions, and order of reported participating resolver hops; attestation binds those assertions to the selected response and client nonce. Appendix Table 5 makes these boundaries explicit.

Related Work

X-Trace propagated EDNS0 metadata through recursive DNS operations and reconstructed cross-layer task trees from outof-band reports [19]; R ESOLVER -PATH instead returns with the DNS response an ordered sequence of participating recursive resolvers, with optional response-bound attestation. Measuring hidden DNS dependencies. Schomp et al. established the ingress, forwarding, hidden, and egress taxonomy of client-side DNS infrastructure and inferred resolver pools from client and authoritative vantage points [47]. Their 11

From opaque steering to resolver-path accountability. Prior work characterizes CDN steering strategies and their implications for performance, resilience, and delivery geography [29]. That work infers which steering strategy a CDN deploys; it does not reveal the downstream resolvers handling a particular query. Resolver forwarding creates a related visibility gap when queries traverse multiple organizations. This paper’s novelty is cooperative disclosure of the logical resolver path carried by a selected response and cryptographic attestation of its reported resolver assertions—not the discovery that resolver chains, centralization, or cross-border DNS behavior exist. Encrypted DNS and path attestation. DoT [14], DoH [21], and ODoH [28] protect queries from observers [36, 6, 22, 23, 16]; R ESOLVER -PATH is complementary because it exposes reported path evidence to the client without providing query confidentiality. BGPsec [32], Certificate Transparency [31], and SCION [41] provide accountability analogies, while DNSSEC signs DNS data rather than resolver participation [30, 13, 8, 3].

32 topology conditions, rather than production-scale resolver ecosystems. Production deployments involve other stacks, middleboxes, more varied fan-out, and higher throughput than the 20,000 QPS offered-load experiments on 2-vCPU c7i.large BIND testbeds. Its EDNS disclosure depends on intermediate resolvers implementing and preserving the option; implementations that ignore or strip unrecognized options [52] truncate the accumulated path. The controlled cache matrix validates 17,000 selected cache-hit paths with no historical-path reuse, but does not characterize the distribution of cache-terminated path lengths in operational deployments. Deployment, attestation, and privacy. Deployment depends on operator adoption and preservation of the EDNS option. R ESOLVER -PATH generates and validates its RPKI ASN-to-key authorization under a private test trust anchor and implements the response-bound wire format, but production RPKA publication and rollover, production-scale nonce state, and operational key-revocation behavior remain unevaluated. Two standalone, separately implemented Go and Python codebases agree on the published conformance vectors, but this does not establish independent human-team or authorship provenance, production interoperability, or assertion truth. Table 4 consolidates the remaining trust and adversary boundaries; AS and country disclosure reduces topology exposure. Ethical measurement practices. Atlas queries target controlled authoritative domains, and results are reported only in aggregate. For performance tests, the replay trace was collected by the university IT department during routine network operations. The authors received only an anonymized version of the trace, in which client identifiers and queried names had been removed or anonymized prior to release. The organization that owns and operates the measured network approved secondary research use and release of the trace in transformed form; a local authoritative service in the Docker testbed answered every replay name.

5 Limitations and Ethical Considerations Scope of findings. RIPE Atlas provides broad global coverage but overrepresents fixed-broadband networks, particularly in Europe; mobile, enterprise, IoT, and VPN-mediated paths are comparatively underrepresented. Probes in the same AS share resolver configuration, so observations are not independent and the reported rates describe the measured population rather than statistical estimates for the Internet as a whole (§2.4). Our measurements characterize resolver behavior during the 2023–2025 campaigns; because resolver deployments evolve over time, the reported percentages should be interpreted as representative of that period rather than immutable Internet-wide constants. Conservative AS attribution. Private ingress provides no publicly attributable BGP-origin ASN, so the full-population comparison assigns each private ingress to its probe’s client AS. It also retains the 83 Campaign B observations missing a client and/or ingress ASN and counts them as same-AS. These choices place unattributable cases in the non-mismatch category: they retain all 16,636 successful observations in the denominator while 6,622 are classified as different-AS. The resulting 39.8% client–frontend AS-mismatch rate is therefore a conservative lower bound on observed AS-boundary crossing, not an ownership claim about private or ASN-incomplete ingress (§2.1). Generalizability of tracing mechanisms. The R ESOLVER PATH evaluation demonstrates feasibility under controlled deployments, including cache hits, multiple upstream responses, and intentional partial participation across 23 scenario and

6

Conclusions

We showed that observed resolver endpoints frequently cross organizational and national boundaries, with measurable implications for performance, jurisdiction, and infrastructure concentration. Existing DNS mechanisms expose only the endpoints of resolver chains; widespread ingress–egress address and prefix divergence leaves the connecting interval unresolved, but does not identify its mechanism or prove an additional forwarding hop. We introduced R ESOLVER -PATH, a lightweight cooperative disclosure mechanism whose base mode exposes the reported resolver path with near-neutral completion throughput in the completed controlled workloads. Its authenticated extension binds received cooperative assertions to the selected response while leaving non-participating hops outside the evidence. By expanding the observable state available to Internet measurement, R ESOLVER -PATH enables 12

a new class of studies of resolver behavior, infrastructure dependencies, and their evolution over time that are not possible with today’s endpoint-only observations.

13

References [1] Rami Al-Dalky and Kyle Schomp. Characterization of collaborative resolution in recursive dns resolvers. In Proc. of PAM, 2018.

[11] Cloudflare. Troubleshooting dns resolver. https://developers.cloudflare.com/1.1.1. 1/troubleshooting/, 2026. Documents CHAOS TXT id.server queries for checking the connected nameserver; accessed 2026-04-29.

[2] Hussein A. Alzoubi, Michael Rabinovich, and Oliver Spatscheck. The anatomy of ldns clusters: Findings and implications for web content delivery. In Proc. of the WWW, 2013.

[12] Carlo Contavalli, Wilmer van der Gaast, David Lawrence, and Warren Kumari. Client subnet in DNS queries. Technical Report RFC 7871, Internet Engineering Task Force, May 2016.

[3] Simurgh Aryan, Homa Aryan, and J Alex Halderman. Internet censorship in iran: A first look. In Proc. of USENIX FOCI, 2013.

[13] David Dagon, Niels Provos, Christopher P. Lee, and Wenke Lee. Corrupted dns resolution paths: The rise of a malicious resolution authority. In Proceedings of the Network and Distributed System Security Symposium (NDSS 2008), 2008.

[4] Rob Austein. Dns name server identifier (nsid) option. RFC 5001, RFC Editor, 2007.

[14] Sara Dickinson, Daniel Gillmor, and Tirumaleswar Reddy. Usage profiles for DNS over TLS and DNS over DTLS. Technical Report RFC 8310, Internet Engineering Task Force, March 2018.

[5] Vaibhav Bajpai, Samir J. Eravuchira, Jürgen Schönwälder, Robert Kisteleki, and Emile Aben. Vantage point selection for IPv6 measurements: Benefits and limitations of RIPE atlas tags. In 2017 IFIP/IEEE Symposium on Integrated Network and Service Management (IM), 2017.

[15] Trinh Viet Doan, Justus Fries, and Vaibhav Bajpai. Evaluating public dns services in the wake of increasing centralization of dns. In IFIP Networking Conference (IFIP Networking), 2021.

[6] Timm Böttger, Felix Cuadrado, Gianni Antichi, Eder Leão Fernandes, Gareth Tyson, Ignacio Castro, and Steve Uhlig. An empirical study of the cost of dnsover-https. In Proc. of IMC, 2019.

[16] Trinh Viet Doan, Irina Tsareva, and Vaibhav Bajpai. Measuring DNS over TLS from the edge: Adoption, reliability, and response times. In Proc. of PAM, 2021.

[7] Patricia Callejo, Ruben Cuevas, Narseo VallinaRodriguez, and Angel Cuevas. Measuring the global recursive dns infrastructure: A view from the edge. IEEE Access, 7, 2019.

[17] European Commission. Adequacy decisions. https://commission.europa. eu/law/law-topic/data-protection/ international-dimension-data-protection/ adequacy-decisions_en, n.d. Accessed August 5, 2026.

[8] Mariengracia Chirinos, Andrés Azpúrua, Leonid Evdokimov, and Maria Xynou. The State of Internet Censorship in Venezuela. Open Observatory of Network Interference (OONI) Blog, August 2018. https://ooni. org/post/venezuela-internet-censorship/.

[18] European Parliament and Council of the European Union. Regulation (EU) 2016/679 of the european parliament and of the council of 27 april 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing directive 95/46/EC (General Data Protection Regulation) (text with EEA relevance). Official Journal of the European Union, 2016.

[9] Cisco. Understand DNS Traffic Geographical Location Routing. https://www.cisco.com/ c/en/us/support/docs/security/umbrella/ 224948-understand-dns-traffic-geographical. html, 2025. Documents Cisco Umbrella/OpenDNS anycast georouting, IATA three-letter location labels, and which.opendns.com TXT responses; accessed 2026-04-29.

[19] Rodrigo Fonseca, George Porter, Randy H. Katz, Scott Shenker, and Ion Stoica. X-Trace: A pervasive network tracing framework. In 4th USENIX Symposium on Networked Systems Design and Implementation (NSDI 07), 2007.

[10] Cloudflare. Gathering information for troubleshooting sites. https:// developers.cloudflare.com/support/ troubleshooting/general-troubleshooting/ [20] Google Public DNS. Troubleshooting. https: gathering-information-for-troubleshooting-sites/, //developers.google.com/speed/public-dns/ 2026. Documents Cloudflare data-center three-letter docs/troubleshooting, 2024. Section “Determine IATA-style location codes; accessed 2026-04-29. metro serving your queries”; documents EDNS(0) 14

[34] Matt Lepinski and Stephen Kent. An infrastructure to support secure internet routing. Technical Report RFC 6480, Internet Engineering Task Force, February 2012.

NSID responses of the form gpdns-<airport code>; accessed 2026-04-29. [21] Paul E. Hoffman and Patrick McManus. DNS Queries over HTTPS (DoH). RFC 8484, October 2018.

[35] Baojun Liu, Chaoyi Lu, Haixin Duan, Ying Liu, Zhou Li, Shuang Hao, and Min Yang. Who is answering my queries: Understanding and characterizing interception of the DNS resolution path. In Proc. of USENIX Security, 2018.

[22] Austin Hounsel, Kevin Borgolte, Paul Schmitt, Jordan Holland, and Nick Feamster. Comparing the effects of DNS, DoT, and DoH on web performance. In Proc. of the WWW, pages 562–572, 2020.

[36] Chaoyi Lu, Baojun Liu, Zhou Li, Shuang Hao, Haixin Duan, Mingming Zhang, Chunying Leng, Ying Liu, Zaifeng Zhang, and Jianping Wu. An end-to-end, largescale measurement of DNS-over-encryption: How far have we come? In Proc. of IMC, pages 22–35, 2019.

[23] Rebekah Houser, Zhou Li, Chase Cotton, and Haining Wang. An investigation on information leakage of DNS over TLS. In Proc. of CoNEXT, pages 123–137. ACM, December 2019. [24] Geoff Huston. DNS resolver centrality. APNIC Blog, September 2019. https://blog.apnic.net/2019/ 09/23/dns-resolver-centrality/.

[37] Meng Luo, Liling Xin, Yepeng Yao, Zhengwei Jiang, Qiuyun Wang, and Wenchang Shi. Who are querying for me? egress measurement for open DNS resolvers. In Proc. CSCWD, pages 1544–1550, 2023.

[25] Internet Systems Consortium. How do i restrict people from looking up the server version?, 2021. Documents built-in CHAOS records including hostname.bind and id.server; accessed 2026-03-31.

[38] Giovane Moura. How centralized is dns traffic becoming?, 2020. [39] Marcin Nawrocki, Maynard Koch, Thomas C. Schmidt, and Matthias Wählisch. Transparent forwarders: An unnoticed component of the open DNS infrastructure. In Proc. of CoNEXT, 2021.

[26] IPinfo. IPinfo, n.d. [27] IPInfo. What is anycast?, n.d. Documents that anycast IP addresses do not have a single fixed location and that IPInfo returns WHOIS geography, typically the owner organization’s headquarters, for anycast IPs with conflicting locations; accessed 2026-07-21.

[40] John S. Otto, Mario A. Sánchez, John P. Rula, and Fabián E. Bustamante. Content delivery and the natural evolution of DNS: remote DNS trends, performance issues and alternative solutions. In Proc. of IMC, 2012.

[28] E. Kinnear, P. McManus, T. Pauly, T. Verma, and C.A. Wood. Oblivious DNS over HTTPS. RFC 9230, RFC Editor, June 2022.

[41] Adrian Perrig, Pawel Szalachowski, Raphael M. Reischuk, and Laurent Chuat. SCION: A Secure Internet Architecture. Springer, 2017.

[29] Rashna Kumar, Fabián E. Bustamante, and Marcel Flores. Who holds the steering wheel? opacity and consolidation in cdn replica selection. In 1st New Ideas in Networked Systems (NINeS 2026), pages 23:1–23:23, 2026.

[42] Quad9. FAQs. https://docs.quad9.net/FAQs/, n.d. Section “Detecting DNS Transparent Redirection (Hijacks)”; documents CHAOS TXT id.server queries and expected resXXX.xxx.rrdns.pch.net responses; accessed 2026-04-29.

[30] Marc Kührer, Thomas Hupperich, Jonas Bushart, Christian Rossow, and Thorsten Holz. Going wild: Largescale classification of open dns resolvers. In Proc. of IMC, Oct 2015.

[43] Tirumaleswar Reddy.K and Mohamed Boucadair. DNS resolver information. RFC 9606, Internet Engineering Task Force, 2024.

[31] B. Laurie, E. Messeri, and R. Stradling. Certificate transparency version 2.0. RFC 9162, RFC Editor, December 2021.

[44] RIPE NCC. Ipv6 deployment in RIPE atlas: A look at AS diversity. https://labs.ripe.net/Members/ kistel/ripe-atlas-and-ipv6-deployment, 2017. Accessed May 2025.

[32] M. Lepinski and K. Sriram. BGPsec protocol specification. RFC 8205, RFC Editor, September 2017.

[45] RIPE NCC. Atlas console, n.d.

[33] Matt Lepinski, Andrew Chi, and Stephen Kent. Signed object template for the resource public key infrastructure (RPKI). Technical Report RFC 6488, Internet Engineering Task Force, February 2012.

[46] John P. Rula and Fabián E. Bustamante. Behind the curtain: Cellular DNS and content replica selection. In Proc. of IMC, 2014. 15

[47] Kyle Schomp, Tom Callahan, Michael Rabinovich, and Mark Allman. On measuring the client-side dns infrastructure. In Proc. of IMC, 2013. [48] Carlos Selmo, Esteban Carisimo, Fabián E. Bustamante, and J. Ignacio Alvarez-Hamelin. Learning AS-toorganization mappings with borges. In Proc. of IMC, 2025. [49] Kedar Thiagarajan, Esteban Carisimo, and Fabián E Bustamante. The aleph: Decoding geographic information from dns ptr records using large language models. Proceedings of the ACM on Networking, 3(CoNEXT1):1– 20, 2025. [50] University of Oregon RouteViews Project. Routeviews, n.d. [51] Jennifer Valentino-DeVries. Secret f.b.i. subpoenas scoop up personal data from scores of companies. The New York Times, September 2019. [52] P. Vixie, J. Eastlake, M. Larson, R. T. Chandra, T. Fujisaki, and K. Ueda. Extension mechanisms for dns (edns(0)). RFC 6891, Internet Engineering Task Force, 2013. [53] Paul Wouters. CHAIN query requests in DNS. RFC 7901, Internet Engineering Task Force, 2016. [54] Wenhao Wu, Zhaohua Wang, Qinxin Li, Zihan Li, Yi Li, Jin Yan, and Zhenyu Li. ODNS clustering: Unveiling client-side dependency in open DNS infrastructure. In Proceedings of the ACM on Web Conference 2025, 2025.

16

A

Appendix Overview

moval that leaves a later intact hash-linked entry is necessarily exposed. The mechanism therefore provides authenticated cooperative assertions, not proof of physical traversal, complete participation, or regulatory compliance.

This appendix records reproducibility and filtering accounting, protocol and attestation detail, supplementary measurement results, geolocation methodology, and ethics limitations. It also distinguishes the evidence supporting the submitted claims from validation that remains future work.

B Protocol Security and Privacy Details

B.1

Attestation Design and Evaluation Details

B.1.1

Response-Bound R ESOLVER -PATH Wire Specification

Option header and byte order. EDNS option code 65024 carries one 36-byte header followed immediately by entry count fixed-width entries. All integers use unsigned network byte order. Octet strings have the widths in Table 6; there is no padding. A query has message kind 0, zero flags, zero entries, a 16-byte client nonce, and an all-zero response identifier. A response has message kind 1, a nonzero 16-byte response identifier, and one to six entries. Both the nonce and response identifier are generated independently with a cryptographically secure random-number generator. Entries are ordered in response direction: entry 0 is the deepest reported participant that produced or first received the response, and later entries move toward the client. A user interface may reverse this order for display but never changes the signed bytes. The GAP_BELOW bit states only that the signer received the selected response without usable downstream attestation; CACHE_ANSWER states that the signer produced the response from local cache. Neither bit asserts completeness.

Amplification and flooding. Technique 2 introduces no extra ordinary-query round trips, while Technique 1 is an explicit diagnostic walk. The unsigned Technique 2 experiments measured 94.5–98.2 B responses and no truncation or TCP fallback in the tested cases. R ESOLVER -PATH validation confirmed its 36-byte header, fixed 144-byte entries, six-entry limit, and maximum 900-byte option data and 904byte complete option (Table 9). The advertised EDNS UDP payload bounds the DNS message, not the enclosing IP/UDP packet, so IPv4 and IPv6 have the same hop budget. Ordinary IPv4/UDP adds 28 on-wire bytes beyond the DNS message; IPv6/UDP adds 48 bytes absent extension headers. Packet captures at the tested EDNS limits recorded TC signaling and TCP fallback for over-budget selected responses while preserving every signed entry. Coexistence with EDNS Client Subnet. EDNS Client Subnet (ECS, RFC 7871 [12]) shares the EDNS option space with R ESOLVER -PATH. Implementations may preserve recognized options such as ECS while stripping unknown ones, truncating disclosure without affecting normal resolution. ECS and R ESOLVER -PATH share the requestor’s advertised payload budget; an implementation applies the same validated TC/TCP behavior rather than exceeding that budget or silently deleting entries.

Canonical question and response. The canonical question is QNAME in lowercase, uncompressed DNS wire form, including its terminal zero octet, followed by QTYPE and QCLASS as two-byte integers. Exactly one question is permitted. To compute the canonical response digest, first encode each RR as canonical lowercase, uncompressed owner name; two-byte TYPE; two-byte CLASS; two-byte RDATA length; and RDATA in the DNSSEC canonical form of RFC 4034, Section 6.2. Embedded domain names are therefore lowercase and uncompressed; for an unknown type, the RDATA wire octets are unchanged. TTL is deliberately omitted so forwarding-time TTL decrement does not break the chain. OPT, TSIG, and SIG(0) records are excluded, including the R ESOLVER -PATH option itself. Within each answer, authority, and additional section, retain duplicates and sort the encoded RRs lexicographically by unsigned octet value. The response serialization is the ASCII string Resolver-Path response v1 followed by one zero octet; the 16-byte response identifier; a two-byte canonicalquestion length and the canonical question; a two-byte status whose high four bits are OPCODE and low 12 bits are the effective RCODE; one semantic-flags byte whose bits 0, 1, and 2 are AA, TC, and AD (other bits zero); then answer, authority, and additional in that order. Each section is encoded as its one-byte identifier (1, 2, or 3), a two-byte RR count, and for each sorted RR a four-byte length followed by

Infrastructure exposure and encrypted DNS. The EDNS path option reveals resolver identifiers to the client and, in the raw-IP implementation, to the authoritative server. DoT/DoH protects metadata in transit but not from endpoints. AS+country granularity reduces topology exposure. Both fields are covered by the entry signature, but RPKI authorizes only the ASN-to-key binding; the country remains an operator assertion rather than independent location or jurisdiction proof. Finer-grained identifiers add explicit topology exposure. Attestation integrity guarantees. Assuming authenticated key distribution, signatures authenticate assertions under reported operators’ keys and expose modification or reordering of entries that remain linked in the received chain. They do not validate the assertions’ truth. A resolver can omit itself, strip a suffix or the whole option, replace a chain with a new partial chain, or collude under keys it controls. Only re17

Table 5: Closest prior work and the boundary of the novelty claim. “Multihop IDs” means identities of logical resolvers rather than IP-router hops; “response path” means an ordered resolver sequence carried by the selected response; attestation applies only to reported participating hops. Work

Object exposed

Schomp et al. [47]

Externally inferred ingress, egress, and resolver pools; intermediate resolvers remain hidden On-path interception of traffic intended for a chosen resolver IP-router path through a transparent forwarder toward its recursive resolver Self-published capabilities of the contacted resolver DNSSEC validation RRsets along the authoritative delegation chain CDN replica-selection strategy inferred from latency

partial

×

×

× × × × ×

× × × × n/a

× × × × ×

Identities, jurisdictional assertions, and order carried by the selected response

✓

✓

✓

Liu et al. [35] DNSRoute++ [39] RESINFO [43] CHAIN [53] Kumar et al. [29] This work

Multihop IDs

Response path

Response-bound attestation

Structure

Field, in wire order

Bytes

Header

protocol version message kind flags entry count client nonce response identifier

1 1 1 1 16 16

Value 1 0=query, 1=response All bits zero at protocol version 1 0 in a query; 1–6 in a response Uniform random octets supplied by the client Zero in a query; fresh uniform random octets per produced response

Encoding and rule

Entry

identity namespace ASN country

1 4 2

entry flags key identifier timestamp prior-entry hash signature

1 32 8 32 64

Value 1 denotes an RPKI ASN Unsigned 32-bit autonomous-system number Signed uppercase US-ASCII ISO 3166-1 alpha-2 operator assertion; not RPKIauthorized Bit 0 GAP_BELOW; bit 1 CACHE_ANSWER; other bits zero SHA-256 of the key’s DER SubjectPublicKeyInfo Unix seconds, UTC SHA-256 of the complete preceding entry, or 32 zero octets for entry 0 Ed25519 signature defined below

Table 6: Normative R ESOLVER -PATH serialization. The header is 36 bytes and each entry is exactly 144 bytes.

its bytes. The canonical response digest is SHA-256 of this entire serialization. Thus transaction ID, RD, RA, CD, TTL, record order, and EDNS options are intentionally outside the digest; answer data, response status, and the unique response instance are inside it.

payload ASN, a current validity interval, and a matching key identifier and Ed25519 signature. Failure of the authorization chain or entry signature is invalid; an unavailable object, unknown key, expired interval, or revocation is unknown/revoked key. The implemented entry serialization includes the country in the Ed25519 input, so modification of either the ASN or country invalidates the signature. RPKI authorizes only the ASN-to-key binding and does not certify the signed country’s geographic truth. The prototype generates and validates the RPKA in a private RPKI hierarchy, including its trust-anchor chain, manifest and CRL, end-entity certificate resource coverage, validity interval, and key identifier. Allocating and standardizing the RPKA eContentType and operating production publication infrastructure remain deployment work; the RPKA payload and verifier algorithm are specified here rather than left as alternatives.

Signed bytes and chaining. For each entry, the Ed25519 input is exactly the following concatenation: the ASCII string Resolver-Path signature v1 followed by one zero octet; the one-byte protocol version; the 16-byte client nonce; a twobyte canonical question length and the canonical question; the 32-byte canonical response digest; the one-byte identity namespace; four-byte ASN; two-byte country; one-byte entry flags; 32-byte key identifier; eight-byte timestamp; and 32-byte prior-entry hash. The signature is not part of its own input. Entry 0 uses 32 zero octets as its prior hash; entry i > 0 uses SHA-256 over all 144 wire bytes of entry i − 1, including that entry’s signature. Consequently, a forwarding resolver verifies the complete downstream chain for its selected response before signing the hash of its last entry.

Freshness. The client generates a uniform 128-bit nonce for each outstanding query and never has two outstanding queries with the same nonce. Timestamps are unsigned 64-bit Unix seconds in network byte order. A verifier accepts an entry only when its nonce matches the outstanding query and its timestamp is within 300 seconds of the verifier’s clock. The client marks the nonce consumed when it selects a response, rejects a second selected response for that nonce, and retains consumed nonce–response-identifier pairs for 300 seconds. A response producer, including a cache-answering resolver, generates a fresh response identifier and chain for every response. Reuse of a historical cache chain, an expired timestamp, a consumed nonce, or a response identifier transplanted from a

Identity and key authorization. R ESOLVER -PATH uses the RPKI ASN namespace. A R ESOLVER -PATH Key Authorization (RPKA) is an RPKI signed object using the standard CMS profile [33] and a DER-encoded payload containing, in order, the ASN, Ed25519 SubjectPublicKeyInfo, 32-byte key identifier, not-before time, not-after time, and serial number. The key identifier must equal SHA-256 of the exact DER SubjectPublicKeyInfo. Verification requires a valid CMS chain to an accepted RPKI trust anchor, a current manifest and CRL, an end-entity certificate whose AS resources cover the 18

Identity granularity and key distribution. R ESOLVER PATH signs an AS+country assertion instead of a resolver IP. Across 16,141 validated observed chains, 3,166 cross borders; 1,091 of those 3,166 cases (34.46%) retain the same ASN across different ingress and egress country labels. This motivates including country as a useful operator assertion, not treating it as independently verified truth. Examples include Google AS15169 chains from Russian ingress to Finnish or Swedish egress labels and Orange AS3215 chains from French Guiana to France. Verification requires an RPKI RPKA object as specified above [34]. Production publication, rollover, revocation behavior under operational failure, and production-scale nonce state remain unimplemented deployment work. Wire-format and transport validation. The validation exercised entry counts zero through six over both IPv4 and IPv6. Serializer-reported lengths were compared with independently parsed packet captures while exercising the 1,232and 4,096-byte EDNS payload limits. The captures recorded TC signaling and TCP fallback for over-budget responses, and R ESOLVER -PATH preserved the complete chain rather than silently deleting entries. Every observed length matched the analytical values in Table 9. Full-scope wire matrix. The paper matrix completed 48/48 cells and 240/240 runs. Its strict artifact checks accepted 1,840/1,840 packet captures and reconciled 1,600/1,600 linked client/resolver event sets. At the 1,232-byte UDP payload, signed depth-eight cases used TCP in 10/55 cases for each IP family; signed depth-15 cases used TCP in 45/125 cases for each IP family. These counts characterize the tested transport matrix and do not imply that a resource-limited disclosed path is complete. Wire-format validation confirmed the R ESOLVER -PATH size model across both IP families. Every serialized entry was 144 bytes, and option data matched 36 + 144h bytes for h = 0, . . . , 6; including the EDNS option-code/length header yielded 40 + 144h bytes. IPv4 and IPv6 produced identical DNS-layer sizes. Packet captures independently confirmed the complete DNS-message sizes and the specified TC/TCP behavior at the tested EDNS payload limits. The advertised payload limits the DNS message rather than its enclosing packet: ordinary IPv4/UDP adds 28 bytes on wire, while IPv6/UDP adds 48 bytes absent IPv6 extension headers. If B is the DNS-message size excluding only the R ESOLVER -PATH option and U is the advertised EDNS payload limit, the supported entry count is    U − B − 40 hmax = min 6, . 144

sibling response is invalid. Partial deployment and response selection. The transition rules are deterministic. A valid selected downstream response is preserved and extended. A response without the option causes the first participating upstream resolver to create a fresh response identifier and entry with GAP_BELOW; option absence at the client is unattested. A cache or locally produced answer creates a fresh identifier and chain for the current nonce and sets CACHE_ANSWER. Malformed or cryptographically invalid downstream data is relayed as invalid and is not converted into a new valid partial chain; an unverifiable key similarly retains the unknown/revoked-key outcome. With retries or fan-out, every produced response has an independent identifier and chain; a resolver verifies and extends only the response it selects, discards losing chains, and never merges entries. On receiving six entries, an upstream participant forwards the chain without appending and the verifier marks the result resource-limited. Unsupported protocol-version values are unattested rather than parsed as R ESOLVER -PATH. For an option with protocol version 1, a question count other than one, header/length mismatch, response identifier of zero, response entry count outside 1–6, nonzero reserved bit, noncanonical country, or trailing octet is malformed and therefore invalid. Verification stops after six signature checks and six RPKA lookups. If the complete message exceeds the advertised UDP payload, the resolver preserves the chain and uses the validated TC/TCP behavior specified above rather than changing or merging the chain. Response-bound cross-implementation conformance. Two standalone, separately implemented codebases consumed the published specification vectors: Go using standardlibrary Ed25519 and Python using cryptography Ed25519. Neither codebase imports the production implementation or vector generator. The suite contains 18 canonical cases, executed for five repetitions by both codebases, yielding 180 implementation decisions. This establishes separate code paths, not provenance from independent human teams or authors. Coverage includes valid and fresh-cache responses, historical reuse, nonce replay, selected-answer/status substitution, sibling transplant, partial participation with GAP_BELOW, stripping, unknown and revoked keys, and six-entry overflow. Canonical re-signing matched 130/170 signer-applicable presented payloads. The 40 non-matches are expected: those four mutation-vector families deliberately present a removed, reordered, or modified entry, or a copied signature, rather than the canonical payload the signer would produce. All 180 decisions link to client events and separate per-codebase logs, and the packet evidence comprises 180 packets in 5 PCAPs. These results test the published vector suite; they do not establish assertion truth, path completeness, physical traversal, or production interoperability.

This expression applies when U − B ≥ 40; otherwise the complete option does not fit in the advertised UDP budget. Cryptographic cost. Per-entry Ed25519 signing was 36.8– 37.1 µs p50 and verification 93.4–95.2 µs p50. Direct depth19

query

selected response

candidate response

Forwarder R1

Client

Downstream branch A

Downstream branch B

one query Q with fresh client nonce n fan-out: Q(n) fan-out / retry: Q(n) observe response A create rid_A, digest_A sign/extend chain_A on return

observe response B create rid_B, digest_B sign/extend chain_B on return

candidate response A: rid_A, digest_A, chain_A candidate response B: rid_B, digest_B, chain_B B discarded; never merged

selected: A verify chain_A, then append SigR1 (digestA , H(chainA )) after R1 has observed response A

selected response A with extended chain_A Sibling transplant: placing chain_B beneath the intact selecting-resolver entry for A is INVALID: digest_B̸=digest_A and H(chain_B) ̸= H(chain_A).

Cache hit (current nonce n): create a fresh rid_C, digest_C, and chain_C; never reuse historical attestation.

Guarantee boundary: valid attestation covers only received cooperative assertions. It does not prove completeness or physical traversal, and arbitrary whole-option stripping or replacement remains outside the guarantee.

Figure 9: Response-bound attestation under fan-out and retries. Solid blue arrows carry one query and its fresh client nonce; dashed arrows carry candidate responses, and the thick green arrow marks the selected response. Each downstream branch first observes its response and then creates a distinct response identifier, canonical response digest, and independent chain. R1 selects A, verifies chain_A, and only then appends its signature; B is discarded, and sibling chains are never merged. Transplanting chain_B beneath the intact selecting-resolver entry for A fails the response-digest/prior-hash checks. Valid attestation covers only received cooperative assertions, not completeness or physical traversal; arbitrary whole-option stripping or replacement remains outside the guarantee.

Separate CPU/latency and heterogeneous experiments. A separate CPU/latency experiment ran at 2,000 QPS. At the measured 36.8 µs signing cost, the arithmetic service-rate estimate is approximately 27,000 signatures/s per core; this estimate is distinct from the observed end-to-end depth-load results above. At depths 2, 3, and 5, CPU cost rose from 76.7 to 189.4, 101.8 to 202.1, and 122.4 to 224.4 µs/query, respectively. P95 latency rose from 0.247 to 0.463 ms at depth two, 0.303 to 0.495 ms at depth three, and 0.073 to 0.239 ms at depth five. The offered 2,000 QPS completed with zero measured loss.

two verification took 149 µs p50 and 158 µs p95 over ten iterations. Depth-load throughput and loss. The depth-load matrix crossed three depths, three modes, ten offered loads from 2,000 to 20,000 QPS, and five 300-second repetitions per cell. The resulting 450 runs covered 135,000.268 measured seconds. Table 10 reports median achieved throughput at the 20,000-QPS load and loss both at that load and across all ten loads. Signed mode remained below 0.001% loss across all loads at every depth. Depth Mode

Loss at 20k

Loss, all loads

2 Baseline 2 Unsigned 2 Signed

Median QPS

19,998.902 55 / 29,998,235 19,998.068 37 / 29,997,548 19,695.803 196 / 28,231,110

130 / 164,997,520 141 / 164,996,990 386 / 163,155,575

3 Baseline 3 Unsigned 3 Signed

19,995.483 101 / 29,993,381 232 / 164,988,590 19,995.706 132 / 29,991,123 294 / 164,986,692 19,545.222 439 / 29,132,169 1,095 / 163,704,716

5 Baseline 5 Unsigned 5 Signed

19,959.482 195 / 29,939,714 836 / 164,903,749 19,955.340 201 / 29,934,516 657 / 164,895,498 19,423.159 499 / 28,979,101 1,595 / 163,372,922

In heterogeneous runs, verification rate was 1.0 and observed truncation and TCP fallback were 0.0. Throughput deltas relative to Technique 2 were −1.29% for bind_bind_bind, −1.36% for bind_knot_bind, −3.35% for bind_unbound_knot, and −5.56% for bind_unbound_bind; corresponding p95 latencies were 6.527, 7.807, 7.807, and 11.519 ms. The full heterogeneous run reduced throughput by about 1.3%. These controlled participating-chain results authenticate received assertions but do not test assertion truth or hidden-hop omission.

Table 10: Attestation depth-load matrix. Each depth–mode–load cell has five 300-second repetitions. Achieved QPS is the median at 20,000 offered QPS; loss cells give lost queries over total queries at that load or across all ten loads. The complete matrix comprises 450 runs and 135,000.268 measured seconds.

20

Verifier state

Trigger

Interpretation

VALID_RECEIVED

Every received entry, link, digest, nonce, time, and key authorization verifies Bad layout, reserved bit, count/length, nonce, time, digest, response identifier, link, authorization chain, or signature Selected response contains no option A referenced authorization is unknown, expired, revoked, or unavailable

Only the integrity, order, and freshness of these received cooperative assertions; never completeness

INVALID

UNATTESTED KEY_UNAVAILABLE

Received attestation failed verification

No attestation evidence; stripping and non-participation are indistinguishable Assertions are not accepted as valid until the key state is resolved

Table 7: R ESOLVER -PATH verifier states. VALID_RECEIVED may carry GAP_BELOW and/or RESOURCE_LIMITED modifiers; neither modifier nor an unmodified valid state is a claim that the path is complete. Check

Population

Result

Interpretation

Evidence-ready vectors

18 canonical cases

18/18

Implementation decisions Cross-implementation verdicts Canonical signing Expected verifier state Parser/serializer Canonical response hash Evidence linkage

18 × 5 × 2 18 × 5 paired trials 17 signer-applicable cases ×5 180 decisions 180 decisions 180 decisions 180 decisions

180 90/90 85/85 180/180 180/180 180/180 180/180

Presented-payload re-signing

170 signer-applicable payloads

130/170

Every vector has the required decision, log, event, and packet evidence. One decision per codebase, case, and repetition. Go and Python returned the same verifier state. The codebases emitted identical canonical signatures. Each decision matched the vector’s expected state. Each codebase matched the canonical parsed and serialized bytes. Each codebase matched the published canonical hash. Decisions link to client events, separate implementation logs, and 180 packets in 5 PCAPs. The 40 expected non-matches are removed-entry, reordered-entry, modified-entry, and copied-signature mutation vectors.

Table 8: Published-vector conformance for two standalone, separately implemented codebases. Go uses standard-library Ed25519; Python uses cryptography Ed25519. Neither imports the production implementation or vector generator. The experiment establishes cross-implementation agreement for these vectors, not independent human-team or authorship provenance. Entries h

Option data

Full option

Residual at 1232

Residual at 4096

Verifications

0 1 2 3 4 5 6

36 180 324 468 612 756 900

40 184 328 472 616 760 904

1192 1048 904 760 616 472 328

4056 3912 3768 3624 3480 3336 3192

0 1 2 3 4 5 6

Table 9: Validated R ESOLVER -PATH wire sizes and verification bounds. Sizes are bytes. “Option data” is the EDNS option payload, “Full option” includes the four-byte option-code/length header, and each residual is the DNS-message budget remaining for the response and other EDNS data. IPv4 and IPv6 produce identical values because IP headers are outside the advertised EDNS payload.

C Measurement Accounting and Reproducibility The two 2025 runs together account for 23,353 requested probe measurements, 21,060 scheduled probes, 35,814 successful results, 3,703 failed or timed-out results, 228 listed ASN exclusions, and 35,586 retained chains. Campaign B is the source of the paper’s 16,636-row 2025 cross-sectional coverage base. Table 13: IPs, ASes, and organizations in the 2025 dataset. Entity

Clients

Ingress

Egress

Unique IPs Unique ASes Unique organizations

11,444 3,805 3,133

5,538 2,294 2,174

7,563 1,565 1,478

21

Run

UTC collection window

Measurement-ID span

Atlas meas.

Requested

Scheduled

Probes with result

2023

2023-01-05 02:45:53–2023-01-09 48540346–48579274 08:40:25 2024-08-19 18:20:29–2024-08-28 77472062–77715847 04:58:45 2025-05-29 15:14:19–2025-05-30 106351841– 04:03:00 106460342 2025-10-01 19:47:32–2025-10-02 130689926– 08:34:00 130790733

12,281

12,281

11,956

10,729

23,095

23,095

19,557

10,082

11,909

11,909

10,488

10,039

11,444

11,444

10,572

9,611

2024 2025A 2025B

Table 11: RIPE Atlas campaign manifest. Times are UTC. Measurement-ID values are reported as the minimum–maximum span for each run; the “Atlas meas.” column reports the campaign count rather than implying that every intervening integer belongs to the run. Requested and scheduled counts are per run; “Probes with result” counts distinct probes returning at least one result. Run

Successful

Failed / timeout

24,460 10,087 19,178 16,636

538 6,376 1,870 1,833

2023 2024 2025A 2025B

Excluded after success

Retained

465 missing frontend ASN 147 missing frontend ASN; 41 missing egress ASN 145 missing client ASN 75 missing client ASN; 6 missing client and ingress ASN; 2 missing ingress ASN

23,995 9,899 19,033 16,553

Table 12: Campaign-level result and exclusion accounting. Within every row, successful results minus the listed exclusions equals retained chains. Campaign 2025B supplies the 16,636 successful rows used as the raw 2025 analysis base; 16,553 remain in the ASN-complete subset after the campaign-level exclusions shown here. The full-population client–frontend lower bound retains all 16,636 rows by counting the 83 ASN-incomplete rows as same-AS. Run

Both endpoint IPs

Different endpoint IPs

Share

19,178 16,636 35,814

18,143 15,812 33,955

94.60% 95.05% 94.81%

2025A 2025B Combined

Public-ingress Different public observations endpoint IPs 11,155 9,927 21,082

10,121 9,103 19,224

Share 90.73% 91.70% 91.19%

Table 14: Observed ingress–egress IP divergence in the 2025 campaigns. Each row counts observations with both endpoint IPs; the public-ingress subset excludes private ingress. IP inequality establishes different visible endpoint addresses, not an additional logical resolver or the number of intermediate hops. “Combined” concatenates Campaigns A and B. Comparable IPv4 pairs

Run 2025A 2025B Combined

14,909 13,040 27,949

Different /24

Share

Public-ingress Public-ingress IPv4 pairs different /24

13,404 89.91% 11,845 90.84% 25,249 90.34%

8,080 7,273 15,353

Share

6,576 81.39% 6,078 83.57% 12,654 82.42%

Table 15: Ingress–egress IPv4 prefix divergence. A pair is comparable when both endpoints are IPv4 and is divergent when the first 24 bits differ. The public-ingress population is the primary endpoint-opacity population because private ingress can differ from public egress solely through address translation. Different /24s do not establish distinct operators or an additional logical resolver. Combined /24-divergent population All ingress Public ingress Non-public ingress

ASN known

Different ASN

Organization known

Different organization

25,243 12,654 12,589

10,592 (41.96%) 3,372 (26.65%) 7,220 (57.35%)

24,223 12,383 11,840

9,325 (38.50%) 2,983 (24.09%) 6,342 (53.56%)

Table 16: Administrative characterization of the combined Campaign A and B IPv4 /24-divergent observations. Percentages are conditional on /24 divergence and availability of the corresponding mapping; they are not prevalence rates over all comparable IPv4 pairs. Different AS or organization mappings establish administrative separation between the observed ingress and egress endpoints, not an intermediate forwarding path. Stage

Base

Retained

2025B successful results Campaign-level ASN completeness Full-population AS lower bound 2025 per-side observations Public frontend geolocation Valid country triples Plausibility-consistent subset

16,636 16,636 16,636 16,636 16,636 16,636 16,636

16,636 16,553 16,636 16,636 9,923 16,563 16,141

Anycast serving-site subset Non-anycast egress subset

5,498 16,563

3,869 15,125

Excluded / use Raw campaign-B analytical coverage base 83 rows with missing client and/or ingress ASN 83 ASN-incomplete rows retained and counted as same-AS Coverage base 6,713 private-ingress observations reported separately 73 without a retained complete triple 495 chains contradicted by active checks; counted in-country in the fullpopulation analysis 1,629 without usable serving-site geolocation 1,438 anycast-egress triples excluded

Table 17: Filtering and analysis-population accounting for the 2025B dataset.

22

D

Open Validation Questions

Table 20: AS and organizational relationship between clients (C), ingress (I), and egress (E) resolvers in the 2024 campaign under the conservative same-AS convention.

One question remains outside the scope of the completed evaluation and is not used to support stronger claims: the operational distribution of ingress- and intermediate-cache-hit path lengths beyond the controlled cache matrix. The previously open cross-implementation conformance question is addressed by the 18-case published-vector experiment in Table 8, including selected-answer/status and sibling substitution, cache freshness and reuse, partial participation, stripping, key state, overflow, separate logs, and packet captures. The two standalone codebases do not establish provenance from independent human teams or authors.

This section records the longitudinal material that is too detailed for the main text. It includes the probe-weighted stablepanel summary used in the main paper, older full-population campaign tables for 2023–2024, and the 2025 client–frontend AS-boundary summary. The older tables remain useful as baseline context but do not control for probe-composition churn. All AS-level tables in this subsection use the conservative same-AS convention: every private ingress is assigned to the client AS. For the 2025 full-population client–frontend result, the 83 ASN-incomplete observations are also counted as same-AS, so the different-AS share is a lower bound. The longitudinal 2025 row uses the deduplicated union of Campaigns A and B; the 16,636-row cross-sectional analyses use Campaign B alone. Classified Probes 2,432 2,439 2,468

C=I=E 41.5% 38.9% 37.9%

C=I, I̸=E 23.1% 20.8% 20.0%

C̸=I, I=E 19.0% 13.7% 18.2%

F

F.1

I/E ASes

Organizational Relationship

=

=

31%

=

̸=

15.4%

̸=

=

10.1%

̸=

̸=

All in the same organization C = I = E: 4.4% C = I ̸= E: 95.6% C = I = E: 1.1% C ̸= I = E: 98.9% C = I = E: 1.8% C ̸= I ̸= E: 95% C = I ̸= E: 2.8% C ̸= I = E: 0.4%

37.2%

=

=

26.6%

=

̸=

23.0%

̸=

=

13.3%

̸=

̸=

All in the same organization C = I = E: 4.4% C = I ̸= E: 95.6% C = I = E: 1.1% C ̸= I = E: 98.9% C = I = E: 1.8% C ̸= I ̸= E: 95% C = I ̸= E: 2.8% C ̸= I = E: 0.4%

Comparison

Count

N

Share

Client ASN ̸= frontend ASN

6,622

16,636

39.8%

Entity Type

Clients

Ingress

Egress

Unique IPs Unique ASes Unique Organizations

10,082 3,258 3,048

2,874 2,236 2,093

6,031 1,757 1,644

Supplementary Protocol Evaluation

Strict Response-Path Correctness

The final correctness matrix contains all 185 required runs, exactly 37 in each of five repetitions. Both strict validators pass across all 23 scenario conditions and all 32 topology conditions. Three pre-fix failures and two interrupted attempts remain preserved separately rather than being counted in the required-run matrix. The retained evidence contains 49,242 controlled clientquery records, 65,242 upstream-response records, and 445,729 timestamped resolver events. All query names were controlled: the validators found 0 uncontrolled qnames.

Table 19: AS and organizational relationship between clients (C), ingress (I), and egress (E) resolvers in the 2023 campaign under the conservative same-AS convention. C/I ASes

Organizational Relationship

This section expands the protocol-evaluation results from Section 3. It provides the per-behavior cloud-capacity breakdown at the common 20,000 QPS comparison point, the wire-level depth-scaling summary for Technique 2, and the full throughput, resource, and cache figures referenced in the main text.

Table 18: Probe-weighted AS-level chain shares under the conservative same-AS convention for the strict stable panel of 2,468 probes present in the 2023, 2024, and 2025 year-level datasets with unchanged client AS and country. The 2025 dataset is the deduplicated union of Campaigns A and B. Within each year-level dataset, each classified probe contributes total weight 1, split across its classified resolver chains.

43%

I/E ASes

Table 22: IPs and AS/organization analysis labels in the 2024 dataset. Private-ingress labels follow the conservative same-AS convention.

C̸=I, I̸=E 16.5% 26.6% 23.9%

C%

C/I ASes

Table 21: Client–frontend AS-boundary result in Campaign 2025B under the conservative convention that assigns every private-ingress observation to the client AS and counts all 83 observations lacking a client and/or ingress ASN as same-AS. The 16,636 denominator is therefore the full successful-result population; 16,553 rows are ASN-complete.

E Supplementary Measurement Results

Year 2023 2024 2025

C%

F.2

Completed Local Performance Matrices

Table 24 reports only workloads whose cells are final. Warm cache additionally completed 100/100 repetitions and passed 23

Condition

Population

Fully participating paths

63,042 individual responses; 47,042 se- Every path matched the linked resolver events exactly after excluding lected responses the intentionally non-participating P1 condition. Every response explicitly reported missing or truncated disclosure; 1,000 responses none reported false completeness. 17,000 responses Every current-response path was exact; historical-path reuse was 0/17,000. 29,042 parent-observed responses; Every observed and selected response path was exact; sibling/cross13,042 selected responses response merges were 0. 7,000 diagnostic/ordinary-response 4,000 pairs disagreed (57.14%), confirming that configured diagnostic pairs topology and ordinary response paths are distinct objects.

P1 partial participation Selected cache hits Multiple upstream responses Technique 1 comparison

Validated result

Table 23: Strict controlled response-path correctness. “Exact” means agreement with the linked client-query, upstream-response, and timestamped per-resolver event evidence for the same controlled transaction. The table validates the tested operational behavior, not path completeness under arbitrary non-participation.

Active Measurements: RIPE Atlas probes test every egress resolver whose country attribution comes from IPInfo and every ingress resolver for which IPInfo is the deciding signal. The validation collects RTT and traceroute measurements, compares implied distance against the claimed country under a fiber-speed bound of 200,000 km/s, inspects the last responsive traceroute hop, and measures the share of domestic hops. A country attribution enters the plausibility-consistent subset only when these measurements do not contradict it. When they do, the full-population analysis conservatively assigns the observation to the probe country rather than counting it as cross-border, while the stricter subset excludes it. This rule produces residual cases such as Ingress Out in the main-text structure figure: the ingress geolocates abroad, but no plausibility-consistent egress country remains available.

its strict validator. The cold-cache and conditional-forwarding rows are scoped to their respective completed 20-cell matrices. The diagnostic latency fit was 0.2654 ms/hop at p50 and 0.3227 ms/hop at p95. Successful walks recovered the configured topology and issued depth+1 queries because the walk ended with an authoritative lookup. A configured hop exposed by this diagnostic need not process an ordinary query, especially when a resolver answers from cache.

G Supplementary Geolocation Analysis This section documents the geolocation pipeline behind the country-level results and collects the supporting figures that would otherwise interrupt the main narrative. We first summarize the passive and active validation workflow, then provide additional country-level visualizations and the full frontend country-selection table used to choose the main-text countries. Resolver geolocation combines passive and active measurements for publicly routable addresses. Private ingress is handled separately: an RFC 1918/private-use address establishes the near-side hop but supplies neither an independently geolocatable address nor a public BGP origin ASN. All-observed country summaries place private ingress in the client country, a conservative convention analogous to the same-AS assignment. Passive Measurements: IPInfo supplies country-level geolocation data [26], while the Aleph extracts location hints from reverse DNS hostnames [49]. For public anycast ingress resolvers, operator-exposed identity strings (NSID or CHAOS TXT records such as id.server) provide the primary site signal because IP-registration databases frequently map anycast addresses to corporate headquarters rather than the serving PoP. Cloudflare confirmed in private correspondence with the authors that id.server generally identifies the ingress colo; during overload, internal forwarding can cause it to continue naming the client-facing site while a different downstream resolver supplies the recursive egress.

Reconciling passive signals with the active checks yields 16,141 frontend/egress country chains whose inferred countries remain plausible, the stricter robustness-check subset. The other cases were actively tested rather than left unvalidated: when an IPinfo location was contradicted, the fullpopulation analysis counted the observation as in-country. The 16,636 per-side geolocation-coverage base used in Table 1 and the main-text country-level mismatch claims therefore apply this conservative convention; Table 17 gives the complete accounting.

G.1

Additional Geolocation Results

This subsection provides additional detail behind the geolocation findings in Section 2.4. The summary statistics below and the figures that follow are grouped here to preserve space in the main text while still showing the broader EU-scope, ingress-mismatch, and egress-mismatch patterns. For comparison, the full 2025 dataset contains 16,563 valid probe– frontend–egress country triples, including the chains later excluded from the main-text non-anycast egress comparison: probe–frontend mismatch occurs in 1,430 cases (8.63%), probe–egress mismatch in 17.06% of cases, frontend–egress mismatch in 18.20%, and all three countries differ in 0.42%. 24

Workload

Completed cells

Baseline

Tracing disabled

Unsigned

Signed

20/20 20/20 20/20

19,999.633 19,999.865 17,609.977

19,999.303 19,999.982 17,633.096

19,998.139 19,998.474 17,589.189

19,993.933 19,999.899 17,633.980

Warm cache Cold cache Conditional forwarding

Table 24: Median completed QPS at a 20,000-QPS offered load for the completed local workload matrices. Each row is a separately completed workload; the table makes no aggregate claim across unfinished workload families.

Mode Baseline Tracing disabled Unsigned Signed

Completed QPS

p50 (ms)

p95 (ms)

p99 (ms)

Chain CPU (µs/query)

Peak memory (MB)

Bytes/query

19,999.633 19,999.303 19,998.139 19,993.933

0.012 0.012 0.012 0.069

0.017 0.018 0.018 0.127

0.163 0.163 0.167 0.423

13.124 12.987 13.358 76.135

243.58 246.12 251.64 247.44

127 127 163 309

Table 25: Final warm-cache performance at a 20,000-QPS offered load (20/20 cells, 100/100 repetitions, strict validation pass). CPU is the summed resolverchain cost. Signed client verification had a median cost of 226.01 µs.

G.2

Frontend Country Selection Table

This final table reports the complete per-country frontendselection metrics for all 171 observed countries. It serves as the full appendix counterpart to the top-country views shown in the main text and allows readers to inspect which countries were excluded by the support thresholds.

H

Ethics

This section summarizes the ethical constraints that shaped both the RIPE Atlas measurement campaign and the protocolevaluation workload. The Atlas campaign queries domains under controlled authoritative service and uses returned IP, ASN, and country metadata in aggregate. It does not observe or intercept thirdparty user traffic, and private ingress is not assigned an operator identity. Atlas use follows the platform’s Acceptable Use Policy and Terms of Service. The performance workload derives from a ten-minute university DNS trace collected on January 13, 2025, from 1:00– 1:10 p.m. CST (19:00–19:10 UTC) by the university IT department during routine network operations. The authors received only an anonymized version of the trace, in which client identifiers and queried names had been removed or anonymized prior to release. The organization that owns and operates the network approved secondary research use and release in transformed form; we omit the organization’s identity to preserve double-blind review. The transformed trace was released with the organization’s permission for research reproduction. The evaluation ran in a Docker testbed whose local authoritative service was configured to answer every replay name. Published results remain aggregated at country or AS level, with no per-probe identifiers in the released dataset.

25

Behavior

Mode

Domestic Domestic Domestic Domestic Egress Out, London Egress Out, London Egress Out, London Egress Out, London Ingress Out, Egress Same Ingress Out, Egress Same Ingress Out, Egress Same Ingress Out, Egress Same Ingress Out, Egress Third Ingress Out, Egress Third Ingress Out, Egress Third Ingress Out, Egress Third Bounce Back Bounce Back Bounce Back Bounce Back

Vanilla Tracing Off Technique 1 Technique 2 Vanilla Tracing Off Technique 1 Technique 2 Vanilla Tracing Off Technique 1 Technique 2 Vanilla Tracing Off Technique 1 Technique 2 Vanilla Tracing Off Technique 1 Technique 2

Completed QPS

p95 (ms)

Loss

CPU (µs/query)

Mem (MB)

18,084.6 [18,027.0–18,857.5] 18,240.9 [17,827.7–18,257.4] 19,999.9 [19,999.9–20,000.0] 18,290.6 [18,008.3–18,459.9] 12,562.5 [12,334.2–13,265.4] 12,954.8 [12,598.9–13,515.2] 20,000.0 [20,000.0–20,000.0] 12,837.7 [12,703.1–13,206.1] 9,292.1 [9,256.2–9,371.6] 9,116.2 [9,104.7–9,287.6] 10,149.9 [10,087.1–10,200.8] 9,164.1 [9,098.5–9,209.0] 5,075.0 [4,976.4–5,212.7] 5,008.2 [4,959.6–5,096.1] 9,996.5 [9,984.5–10,044.4] 4,834.7 [4,718.4–4,915.3] 5,459.8 [5,382.9–5,567.1] 5,382.1 [5,205.4–5,404.3] 10,105.8 [9,998.4–10,143.6] 5,168.4 [5,103.9–5,241.5]

13.311 [7.807–13.567] 12.287 [11.519–15.103] 0.543 [0.543–0.575] 12.543 [10.751–13.567] 44.031 [44.031–44.031] 44.031 [44.031–44.031] 0.327 [0.311–0.391] 44.031 [44.031–44.031] 14.591 [14.335–15.103] 15.359 [14.335–15.359] 10.495 [10.239–10.751] 14.591 [14.079–16.127] 60.415 [60.415–60.415] 60.415 [60.415–60.415] 10.751 [10.751–10.751] 62.463 [62.463–62.463] 51.199 [51.199–52.223] 53.247 [53.247–53.247] 10.751 [10.751–11.007] 55.295 [54.271–55.295]

0.000% 0.000% 0.000% 0.000% 0.000% 0.000% 0.000% 0.000% 0.000% 0.000% 0.000% 0.000% 0.000% 0.000% 0.000% 0.000% 0.000% 0.000% 0.000% 0.000%

216.182 238.551 55.730 206.842 313.060 246.291 23.890 351.514 358.625 377.865 91.719 389.218 453.789 452.412 114.469 531.305 447.450 427.962 81.357 468.703

97.77 98.33 65.91 98.84 98.11 94.13 67.53 97.26 94.38 93.28 66.78 95.93 92.17 90.93 66.01 92.36 90.93 91.12 65.42 89.97

Table 26: Cloud-capacity results at the common 20,000 QPS comparison point. Values are medians across five repetitions; brackets show interquartile ranges. Table 28: Technique 1 TYPE65400 diagnostic latencies across the cloud topologies (200 samples per topology). These dedicated diagnostic-query timings are not ordinary-query performance. Topology

Success

Ingr. p50

Mid. p50

Egr. p50

Auth. p50

Total p50

Total p95

Domestic Egr. Out Ingr. Out/Same Ingr. Out/Third Bounce Back

200/200 200/200 200/200 200/200 200/200

0.624 0.392 10.280 10.260 10.486

0.362 0.766 10.220 10.285 0.492

0.428 10.021 10.226 20.189 0.304

0.456 10.170 10.178 20.111 0.231

2.117 21.574 40.896 61.174 11.913

2.380 22.252 41.939 62.041 12.575

Table 29: End-to-end Technique 1 diagnostic time in the Docker depthscaling experiment (200 samples per depth). Metric p50 (ms) p95 (ms)

2

3

5

8

10

15

0.401 0.928

0.573 1.299

0.837 1.649

1.318 2.730

1.858 3.334

4.015 5.158

Table 30: Passive geolocation signals used for resolver-country inference. Signal source TXT / resolver identity Aleph PTR IPinfo

Country signals

Agreement vs. IPinfo

3,973 3,944 13,098

13.4% (531 / 3,972) 92.5% (3,417 / 3,695) –

26

Proportion

100% 75% 50% 25% 0% Table 27: Technique 2 depth-scaling wire-level metrics at 20,000 QPS. Path recovery is 100% at every depth with zero truncation or TCP fallback. Depth

Pos. rate

Path len.

Resp. (B)

TC / TCP

2 3 5 8 10 15

1.000 1.000 1.000 1.000 1.000 1.000

2.0 3.0 5.0 8.0 10.0 15.0

91.9 96.9 106.9 121.9 132.9 157.9

0/0 0/0 0/0 0/0 0/0 0/0

Probe Categories

e n nt nt ss Acce Conte Enterpris Educatio overnme G

Figure 10: Probe distribution by ASN type, dominated by access networks.

27

p95 latency (ms)

69

Domestic

Vanilla BIND

Tracing Off

New Query Type

EDNS Option

Egress Out, London

Ingress Out, Egress Same

Ingress Out, Egress Third

Bounce Back

10000

10000

10000

10000

34.5 0

10000

20000

20000

20000

20000

20000

Offered load (QPS)

Completed throughput (QPS)

(a) p95 latency. Technique 1’s lower latency reflects different query semantics, not a comparable improvement.

Vanilla BIND

20000

Domestic

Tracing Off

New Query Type

EDNS Option

Egress Out, London

Ingress Out, Egress Same

Ingress Out, Egress Third

Bounce Back

10000

10000

10000

10000

10000 10000

20000

20000

20000

20000

20000

Offered load (QPS) (b) Completed throughput. Technique 1’s higher throughput is expected (different query semantics).

Memory avg (MB) CPU avg (%)

Vanilla BIND 20

Tracing Off

New Query Type

EDNS Option

Domestic

Egress Out, London

Ingress Out, Egress Same

Ingress Out, Egress Third

Bounce Back

Domestic

Egress Out, London

Ingress Out, Egress Same

Ingress Out, Egress Third

Bounce Back

10000

10000

10000

10000

10 0 256 128 0

10000

20000

20000

20000

20000

20000

Offered load (QPS) (c) Resolver-side CPU and memory. Technique 1 is not directly comparable (lightweight query).

Figure 11: Cloud-capacity load-sweep results across the five observed path behaviors and four resolver modes over the 2,000–20,000 QPS load sweep. Panels (a)–(b) show client-side metrics; panel (c) shows resolver-side resource usage.

28

20000

0.06 0.05 0.04 0.03 0.02

95th-percentile latency (ms)

0.07

19600 19400 19200 19000 18800

Tracing Off New Query Type EDNS Option

18600 2 3

5

8 10 Resolver count

15

2 3

5

0.25 0.20 0.15 0.10

0.00

15

8000 6000 4000 2000

0.05

8 10 Resolver count

Warm Cold

10000

0.30

19800

0.08

Completed throughput (QPS)

95th-percentile latency (ms)

0.09

Completed throughput (QPS)

0.10

n ff Tracing O New Query Type EDNS Optio

(a) Depth scaling at 20,000 QPS over resolver chains of length 2–15.

0

n ff Tracing O New Query Type EDNS Optio

(b) Warm-cache and cold-cache behavior at 10,000 QPS.

Depth-3, 20k QPS

Figure 12: Depth-scaling and cache experiments. Technique 2 remains throughput-stable as depth increases; neither tracing mechanism shows a meaningful penalty under warm- or cold-cache conditions.

D D IND Knot D-BIN nd-BIN Knot-B -UnboundUnbou BINDBIND BIND-

IN BIND-B

Warm Cache, 10k QPS

10000

New Query Type

p95 Latency (ms)

EDNS Option

Loss (%)

0.10

0.05

0.08

0.04

0.06

0.03

0.04

0.02

0.02

0.01

0.00

IN BIND-B

D D IND Knot D-BIN nd-BIN Knot-B -UnboundUnbou BINDBIND BIND-

0.00

0.010

0.12 0.10

0.008

6000

0.08

0.006

4000

0.06

0.004

0.04

2000

0.02

0.002

0

0.00

0.000

10000 8000 6000

IND IND IND Knot IND-B Knot-B -Unboundound-B BINDBIND-B BIND-Unb BIND 4 3

4000

2

2000

1

0

0

IND IND IND Knot IND-B Knot-B -Unboundound-B BINDBIND-B BIND-Unb D BIN

D IND IND Knot nd-BIN IND-B Knot-B -UnboundUnbou BINDBIND BIND-

BIND-B

8000

IND IND IND Knot IND-B Knot-B -Unboundound-B BINDBIND-B BIND-Unb BIND

Cold Cache, 10k QPS

Tracing Off

Completed Throughput (QPS)

20000 17500 15000 12500 10000 7500 5000 2500 0

t D IND t-BIND bound-Kno d-BIN IND-B D-Kno n nboun U IN U B D D BIN BIN

BIND-B

D IND IND Knot nd-BIN IND-B Knot-B -UnboundUnbou BINDBIND BIND-

BIND-B 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0.0

t D IND t-BIND bound-Kno d-BIN IND-B D-Kno n nboun U IN U B D D BIN BIN

BIND-B

Figure 13: Heterogeneous depth-3 and cache-performance overview. The figure compares the homogeneous BIND control against mixed BIND → Unbound → BIND, BIND → Knot → BIND, and BIND → Unbound → Knot chains under the same local offered-load settings used in the main text.

29

0%

N=9 N=7 N=27 N=10 N=36 N=230 N=40 N=46 N=127 N=145 N=82 N=67 N=42 N=41 N=32 N=25 N=21 N=19 N=18 N=16 N=12 N=10 N=6 N=5

20%

40%

60%

80%

Within EU Outside EU

EU Probe Country

EU Probe Country

IE HR DK LU BE DE SE AT FR NL IT ES PL CZ FI BG RO GR SI HU EE LV SK PT

100%

Share Of Mapped Anycast Ingresses

IE HR DK LU BE DE SE AT FR NL IT ES PL CZ FI BG RO GR SI HU EE LV SK PT 0%

(a) EU-scope anycast ingress N/ S/ M rates.

M=3 M=1 M=3 M=1 M=1 M=6 M=1 M=1 M=1 M=1 M=0 M=0 M=0 M=0 M=0 M=0 M=0 M=0 M=0 M=0 M=0 M=0 M=0 M=0

20%

40%

60%

80%

Provider

Google Quad9 Cloudflare

100%

Provider Share Of Outside-EU Anycast Ingresses

(b) EU-scope provider mix of out-of-country anycast ingress cases.

Figure 14: Supporting EU-scope anycast ingress visualizations. In panel (a), N is the out-of-country ingress share, S is the subset whose egress stays in the same foreign country as ingress, and M is the subset whose egress moves to a third country. All three bars use the same denominator, namely all anycast probe–resolver pairs for each probe country; unresolved replies remain in the denominator and are counted as in-country. Panel (b) decomposes the out-of-country anycast ingress cases for the countries shown in panel (a).

30

Egress Country

ZA US SG HK TW JP FR DE IT CA PE QA AE FI GB BG PL PK

N=13 N=11 N=213

N=13 N=45 N=51

0.8

N=16 N=85 N=45 N=11

0.6 0.4

Probe Country

Egress Mismatch Percentage

1.0

M=13

MM

M=11

PH

M=190

IQ

M=11

VN

M=38

VE

M=43

DO

M=13

IR

M=68

BY

M=36

AF

M=8

0.2

IR BY AF

VE DO

IQ VN

PH

AO MM

0.0

Provider

AO

0%

Probe Country

20%

40%

60%

80%

OpenDNS Google Cloudflare WoodyNet Level 3 Parent i3D.net Other

100%

Provider Share Of Egress Mismatches

(a) Egress mismatch bar plot.

(b) Egress mismatch provider mix.

Mismatch (%) 0

20

40

60

80

100

(c) Egress mismatch heatmap. Figure 15: Supporting egress mismatch visualizations. Countries such as Angola (13/13), Myanmar (11/11), the Philippines (190/213), Iraq (11/13), Vietnam (38/45), and Venezuela (43/51) show high out-of-country egress rates. Panel (b) shows the provider mix; panel (c) maps mismatch rates geographically.

31

Table 31: Per-country frontend selection metrics. A = Anycast Frontend, G = All Resolver Chains. Countries above the rule in the first column are eligible for the main-text figures (NA ≥ 25, NG ≥ 100, PT ≥ 15 unique probes); all countries are ranked by XBµ = (XBA + XBG )/2. Rk CC NA NG PT XBA XBG XBµ Rk CC NA NG PT XBA XBG XBµ Rk CC NA NG PT XBA XBG XBµ 1 PH 26 213 113 92.3 89.2 90.8 58 NG 2 6 3 100.0 83.3 91.7 115 BT 0 2 1 0.0 100.0 50.0 2 RU 246 665 401 78.1 50.7 64.4 59 BY 12 45 26 100.0 82.2 91.1 116 CG 0 2 2 0.0 100.0 50.0 3 UA 64 227 131 78.1 43.6 60.9 60 DO 7 16 10 100.0 81.2 90.6 117 EG 0 2 1 0.0 100.0 50.0 4 BG 33 108 62 72.7 47.2 60.0 61 SN 2 5 2 100.0 80.0 90.0 118 GP 0 2 1 0.0 100.0 50.0 5 RO 38 121 66 68.4 41.3 54.9 62 MK 6 14 8 100.0 71.4 85.7 119 HT 0 2 1 0.0 100.0 50.0 6 ID 27 131 69 63.0 29.8 46.4 63 RE 2 51 31 100.0 68.6 84.3 120 LS 0 2 1 0.0 100.0 50.0 7 DK 36 138 84 61.1 25.4 43.2 64 ZW 1 6 4 100.0 66.7 83.3 121 MP 0 2 1 0.0 100.0 50.0 8 AT 83 272 151 51.8 31.2 41.5 65 PA 3 23 17 100.0 65.2 82.6 122 PG 0 2 2 0.0 100.0 50.0 9 CZ 60 384 215 60.0 21.6 40.8 66 KE 3 19 10 100.0 63.2 81.6 123 PS 0 2 1 0.0 100.0 50.0 10 GR 32 113 62 50.0 23.9 37.0 67 TZ 4 8 5 100.0 62.5 81.2 124 TO 0 2 1 0.0 100.0 50.0 11 FR 210 1282 711 52.9 19.4 36.1 68 MV 1 8 7 100.0 62.5 81.2 125 AX 0 1 1 0.0 100.0 50.0 12 BE 55 244 128 50.9 16.4 33.7 69 GU 4 13 7 100.0 61.5 80.8 126 DZ 0 1 1 0.0 100.0 50.0 13 FI 44 198 115 20.5 20.2 20.3 70 EC 2 28 16 100.0 60.7 80.4 127 KN 0 1 1 0.0 100.0 50.0 14 CA 91 397 231 20.9 16.4 18.6 71 IM 2 5 3 100.0 60.0 80.0 128 MH 0 1 1 0.0 100.0 50.0 15 CH 80 395 233 20.0 11.4 15.7 72 SI 27 72 41 100.0 56.9 78.5 129 LV 14 46 30 64.3 30.4 47.4 16 SE 72 252 156 18.1 9.9 14.0 73 GT 4 16 7 100.0 56.2 78.1 130 IE 15 95 60 66.7 26.3 46.5 17 AU 88 306 189 10.2 11.4 10.8 74 CR 3 18 12 100.0 55.6 77.8 131 AE 16 28 19 56.2 35.7 46.0 18 SG 62 167 103 4.8 16.8 10.8 75 PY 2 9 7 100.0 55.6 77.8 132 SA 3 22 13 66.7 22.7 44.7 19 BR 27 120 75 11.1 10.0 10.6 76 AL 6 40 21 100.0 52.5 76.2 133 AM 7 28 16 42.9 42.9 42.9 20 PL 60 227 136 11.7 8.8 10.2 77 UZ 9 21 10 100.0 52.4 76.2 134 IL 9 31 18 55.6 29.0 42.3 21 DE 385 2237 1255 12.5 7.0 9.7 78 MA 3 6 2 100.0 50.0 75.0 135 KW 2 6 3 50.0 33.3 41.7 22 ZA 64 166 92 4.7 6.0 5.4 79 NA 1 6 3 100.0 50.0 75.0 136 NO 19 123 69 57.9 25.2 41.5 23 GB 189 737 421 3.2 6.0 4.6 80 KH 2 4 2 100.0 50.0 75.0 137 IR 0 86 64 0.0 80.2 40.1 24 IN 46 145 96 2.2 6.9 4.5 81 PE 12 24 13 91.7 54.2 72.9 138 NZ 13 125 75 53.8 24.8 39.3 25 NL 235 783 467 3.8 5.2 4.5 82 HN 4 10 5 75.0 70.0 72.5 139 PT 15 279 130 66.7 9.0 37.8 26 ES 94 307 180 2.1 6.8 4.5 83 MD 11 36 19 100.0 44.4 72.2 140 TL 0 4 2 0.0 75.0 37.5 27 IT 105 418 245 2.9 5.7 4.3 84 HR 12 42 26 91.7 52.4 72.0 141 MX 15 59 34 40.0 33.9 37.0 28 US 602 2343 1401 2.5 3.5 3.0 85 TJ 3 23 13 100.0 43.5 71.7 142 BF 0 6 4 0.0 66.7 33.3 29 JP 58 269 171 0.0 5.6 2.8 86 BO 10 32 18 90.0 53.1 71.6 143 SK 8 66 36 37.5 28.8 33.1 87 KR 1 26 18 100.0 42.3 71.2 144 FJ 0 5 2 0.0 60.0 30.0 30 MM 7 11 6 100.0 100.0 100.0 88 KZ 23 57 34 82.6 59.6 71.1 145 TN 0 9 4 0.0 55.6 27.8 31 AO 2 13 7 100.0 100.0 100.0 89 MY 18 50 27 83.3 58.0 70.7 146 NI 0 6 4 0.0 50.0 25.0 32 VI 6 7 3 100.0 100.0 100.0 90 MU 2 5 4 100.0 40.0 70.0 147 LC 0 4 3 0.0 50.0 25.0 33 MT 3 8 7 100.0 100.0 100.0 91 LU 13 61 33 84.6 54.1 69.4 148 MW 0 4 2 0.0 50.0 25.0 34 BJ 2 5 3 100.0 100.0 100.0 92 UY 5 22 12 100.0 36.4 68.2 149 CV 0 2 2 0.0 50.0 25.0 35 GH 3 4 2 100.0 100.0 100.0 93 AZ 6 6 4 66.7 66.7 66.7 150 GF 0 5 2 0.0 40.0 20.0 36 CD 2 4 3 100.0 100.0 100.0 94 NP 4 22 14 100.0 31.8 65.9 151 LB 0 3 2 0.0 33.3 16.7 37 CM 3 3 2 100.0 100.0 100.0 95 BD 13 22 12 61.5 68.2 64.9 152 HK 23 63 36 8.7 19.0 13.9 38 FM 2 4 2 100.0 100.0 100.0 96 BA 5 24 11 100.0 29.2 64.6 153 AD 0 4 3 0.0 25.0 12.5 39 GG 3 3 1 100.0 100.0 100.0 97 IS 9 16 10 77.8 50.0 63.9 154 JO 0 4 2 0.0 25.0 12.5 40 GQ 3 3 1 100.0 100.0 100.0 98 RS 21 70 39 90.5 32.9 61.7 155 LK 0 6 5 0.0 16.7 8.3 41 LA 2 3 1 100.0 100.0 100.0 99 CO 14 39 22 78.6 43.6 61.1 156 PK 1 9 5 0.0 11.1 5.6 42 ZM 2 3 2 100.0 100.0 100.0 100 AR 18 62 38 83.3 38.7 61.0 157 PF 0 9 5 0.0 11.1 5.6 43 CI 1 3 1 100.0 100.0 100.0 101 EE 22 55 30 81.8 36.4 59.1 158 TW 44 84 50 0.0 6.0 3.0 44 DJ 2 2 2 100.0 100.0 100.0 102 GE 6 15 10 66.7 46.7 56.7 159 CL 23 111 63 0.0 0.9 0.5 45 KY 2 2 1 100.0 100.0 100.0 103 MN 1 8 5 100.0 12.5 56.2 160 LI 0 7 4 0.0 0.0 0.0 46 PW 2 2 1 100.0 100.0 100.0 104 LT 8 48 31 75.0 35.4 55.2 161 UG 0 7 3 0.0 0.0 0.0 47 TV 2 2 1 100.0 100.0 100.0 105 TR 21 64 44 61.9 48.4 55.2 162 BH 0 5 3 0.0 0.0 0.0 48 KI 1 2 2 100.0 100.0 100.0 106 HU 24 61 36 70.8 39.3 55.1 163 OM 0 4 2 0.0 0.0 0.0 49 SS 1 2 1 100.0 100.0 100.0 107 KG 5 32 16 80.0 28.1 54.1 164 BB 0 2 1 0.0 0.0 0.0 50 BW 1 1 1 100.0 100.0 100.0 108 CN 4 132 62 100.0 7.6 53.8 165 CK 0 2 1 0.0 0.0 0.0 51 QA 1 1 1 100.0 100.0 100.0 109 CY 3 22 12 66.7 40.9 53.8 166 SM 0 2 1 0.0 0.0 0.0 52 TT 1 1 1 100.0 100.0 100.0 110 TH 15 45 29 53.3 46.7 50.0 167 SV 0 2 1 0.0 0.0 0.0 53 AF 5 11 7 100.0 90.9 95.5 111 NC 2 8 5 50.0 50.0 50.0 168 VA 0 2 1 0.0 0.0 0.0 54 IQ 2 13 5 100.0 84.6 92.3 112 ME 0 6 5 0.0 100.0 50.0 169 BI 0 1 1 0.0 0.0 0.0 55 VN 18 45 25 100.0 84.4 92.2 113 MZ 0 4 2 0.0 100.0 50.0 170 BZ 0 1 1 0.0 0.0 0.0 56 VE 22 51 27 100.0 84.3 92.2 114 PR 0 3 1 0.0 100.0 50.0 171 MG 0 1 1 0.0 0.0 0.0 57 TD 5 6 3 100.0 83.3 91.7

32

Related documents

• Who Resolves Your DNS? Measuring Resolver Opacity and Closing the Visibility Gap#794168
• Who Resolves Your DNS? Measuring Resolver Opacity and Closing the Visibility Gap#790149
• DNS Resolver Information#131436
• Negative Caching of DNS Resolution Failures#399464
• dnsix#19157