provenance:design:dns
Table of Contents
Provenance: Design:DNS
Working notes behind dns: every query, every fold, every quote check, every external fetch, and every call that could reasonably have gone the other way. Corpus-level caveats — the venue funnel, the 2025–2026 provisional years, the extraction's own stability — are on corpus and are not restated here.
This page is a log, not prose. It is for someone checking a number.
The run
| Date | 2026-08-27 |
| Corpus | data/extract/run1/extractions.jsonl, 5,859 papers, 7 venues, 2010–2026 |
| Content page | dns, created 2026-08-27 |
| Report script | scripts/report_dns.mjs |
| Fold | scripts/dns_fold.mjs (85 self-tests) |
| Figure/quote check | scripts/verify_dns_figures.mjs |
| External checks | scripts/external_checks_dns.sh + scripts/dnschk/*.py |
| Published code | pages/resolver_disagreement.py |
| Code-block builder | scripts/build_dns_codeblock.mjs |
| Author | Claude (Opus 5), single sitting, unsupervised |
| Reviewers | see Review log |
The population rule, written before any figure
The rule was fixed before the first count, because a curated set whose boundary is decided after the tables exist re-derives every table on the first awkward find.
- A — DNS is the subject.
titleorslugmatches /\bdns(?:sec)?\b|\bdns-over-|\bdoh\b|\bnxdomain\b|\bodoh\b|\bdoq\b|\bopendns\b|\bzdns\b|\bmassdns\b|\bresolver/i - B — DNS is the instrument. The paper has a
tools[]entry withusedOrMentionedin {used,produced} whose name the fold maps to a kind inDNS_KINDS= {query-tool,passive-dns,resolver-software,public-resolver,dnssec-tool,open-resolver-census,custom}. - DNSPOP = A ∪ B. This is the page's population.
- C — ambient. Full text matches /\bDNS(?:SEC)?\b/. Reported as an upper bound; never used as a denominator for a claim about DNS research.
- WEB = DNSPOP ∩
platformscontainsweb.
Deliberately excluded from B, and why:
| Excluded | Papers (corpus-wide) | Why not membership |
|---|---|---|
ZMap / XMap / ZGrab / Scapy (scanner-generic) | 156 | General-purpose scanners. ZMap finds open resolvers, but a ZMap paper is not a DNS paper. Reported in a separate row on the page. |
RIPE Atlas (vantage-platform) | 77 | A vantage network with many measurement types; most of the 77 use it for traceroute. Named on the page as the standard multi-vantage route, not counted as membership. |
WHOIS / RDAP / PSL / tldextract (adjacent:registry-metadata) | 113 + 52 + 4 | Registry questions (“who owns this name”, “where does the registrable domain end”), not resolution questions. Already covered by website_classification and ip_classification. |
| Domain categorisation services, registrar APIs, DGA string analysis, dnstwist, mDNS, RIPE IPmap | 11 + 7 + 4 + 3 + 1 + 1 | Adjacent by name only. Each has its own adjacent: family so the exclusion is countable rather than silent. |
| Off-topic homographs | see fold residue below | Speech recognition (50), lab hardware (46), ATLAS.ti (21), blocklists (18+2+2), ML models (13), NLP taggers (6), MongoDB Atlas (1), Graphviz DOT (1) |
Every figure on the page and where it comes from
The rule is that scripts/report_dns.mjs prints every corpus figure with its denominator, scripts/verify_dns_figures.mjs prints every per-paper figure with the needle it was checked against, scripts/external_checks_dns.sh prints every external fact with the command that produced it, and out/dns/resolver_run.txt is the script run. node scripts/check_page_numbers.mjs pages/design_dns.txt out/dns/allsources.txt over the whole page (no section window) reports:
OK — every figure in the page traces to out/dns/allsources.txt
Report script, unedited output
=== design:dns — every figure with its denominator ===
corpus 5859 papers, 7 venues, 2010–2026. Contracts: OK.
dns_fold self-tests: 85/85 pass.
--- A. POPULATION ---
A DNS in title/slug 108
B used/produced a DNS instrument 202
A ∩ B 66
A only (subject, no DNS tool named) 42
B only (instrument, not titled) 136
DNSPOP = A ∪ B 244 <- the page's population
of which posters 14
lab-rig instrument uses (hand-read, stay in the population) 7
C full text matches /\bDNS(SEC)?\b/ 1218 (20.8% of 5855 readable) — UPPER BOUND, not the population
full text missing for 4 papers
WEB DNSPOP ∩ platform 'web' 82 (33.6% of DNSPOP; 5.1% of the 1622 web-platform papers)
DNSPOP ∩ crawled 44
DNSPOP ∩ network-scan-or-probe 186
--- B. WHERE DNS WORK PUBLISHES (share of that venue's own output) ---
venue papers DNSPOP share A(titled) share
CCS 990 26 2.6% 13 1.3%
IEEE-SP 767 17 2.2% 6 0.8%
IMC 638 84 13.2% 40 6.3%
NDSS 701 26 3.7% 7 1.0%
PETS 510 14 2.7% 7 1.4%
USENIX 1410 61 4.3% 28 2.0%
WWW 843 16 1.9% 7 0.8%
share of DNSPOP in {IMC}: 84 / 244 = 34.4%
share of DNSPOP in {IMC, USENIX, NDSS}: 171 / 244 = 70.1%
share of DNSPOP in {WWW, PETS}: 30 / 244 = 12.3%
share of DNSPOP in {CCS, IEEE-SP}: 43 / 244 = 17.6%
--- C. OVER TIME (both ends bounded; 2025–2026 provisional) ---
window papers DNSPOP share A(titled) share
2010–2013 511 16 3.1% 8 1.6%
2014–2017 769 39 5.1% 13 1.7%
2018–2021 1439 76 5.3% 36 2.5%
2022–2024 1955 74 3.8% 33 1.7%
2025–2026* 1185 39 3.3% 18 1.5%
unbucketed years: 0
--- D. WHAT SHAPE THESE STUDIES ARE (denominator: DNSPOP) ---
studyTypes (multi-valued; the least stable field in the schema — ranking only), N=244
186 76.2% network-scan-or-probe
146 59.8% existing-dataset-analysis
108 44.3% system-or-defence-proposal
83 34.0% manual-audit
52 21.3% code-or-binary-analysis
40 16.4% automated-web-crawl
16 6.6% interview-or-survey
14 5.7% mobile-app-analysis
11 4.5% user-study
7 2.9% simulation-or-theory-only
platforms (multi-valued), N=244
218 89.3% other-online-service
82 33.6% web
24 9.8% offline
21 8.6% mobile
9 3.7% iot
1 0.4% not-applicable
--- E. INSTRUMENT INVENTORY (denominator: DNSPOP unless stated) ---
[query-tool] union 60 papers corpus-wide, 60 of them in DNSPOP — IN population
18 papers 6 spellings dig / drill / nslookup / tor-resolve
16 papers 13 spellings DNS libraries (dnspython, ldns, miekg/dns, getdns)
13 papers 2 spellings ZDNS
7 papers 1 spellings DNS fingerprinting (fpdns)
5 papers 2 spellings massdns
4 papers 4 spellings DoH/DoT client tooling
2 papers 2 spellings reverse-DNS lookup
[passive-dns] union 65 papers corpus-wide, 65 of them in DNSPOP — IN population
28 papers 16 spellings Farsight DNSDB / DomainTools (passive DNS)
14 papers 2 spellings OpenINTEL
8 papers 8 spellings other passive-DNS feeds
8 papers 7 spellings Rapid7 Open Data (FDNS/RDNS)
4 papers 5 spellings Chinese passive-DNS feeds (360, 114DNS)
3 papers 3 spellings zone files / CZDS
2 papers 2 spellings Active DNS Project
1 papers 1 spellings DNS Observatory
[resolver-software] union 62 papers corpus-wide, 62 of them in DNSPOP — IN population
29 papers 11 spellings BIND
25 papers 4 spellings Unbound
11 papers 2 spellings PowerDNS
9 papers 2 spellings dnsmasq
7 papers 2 spellings Knot
5 papers 2 spellings Microsoft DNS / Simple DNS Plus
5 papers 2 spellings NSD
3 papers 2 spellings MaraDNS
2 papers 1 spellings djbdns / dnscache
2 papers 2 spellings B-Root
2 papers 1 spellings CoreDNS
2 papers 3 spellings systemd-resolved
1 papers 1 spellings hnsd (Handshake)
1 papers 1 spellings gdnsd
[public-resolver] union 29 papers corpus-wide, 29 of them in DNSPOP — IN population
16 papers 6 spellings Google Public DNS
9 papers 1 spellings OpenDNS / Cisco Umbrella
6 papers 2 spellings Cloudflare DNS
5 papers 3 spellings other public resolvers (Comodo, CleanBrowsing, Quad9)
2 papers 1 spellings NextDNS
2 papers 2 spellings public-resolver lists
[dnssec-tool] union 3 papers corpus-wide, 3 of them in DNSPOP — IN population
3 papers 3 spellings DNSViz and DNSSEC validators
[open-resolver-census] union 1 papers corpus-wide, 1 of them in DNSPOP — IN population
1 papers 1 spellings Open Resolver Project
[custom] union 34 papers corpus-wide, 34 of them in DNSPOP — IN population
34 papers 34 spellings home-grown DNS code
[scanner-generic] union 156 papers corpus-wide, 38 of them in DNSPOP — reported only, NOT in the population rule
112 papers 13 spellings ZMap / XMap
33 papers 4 spellings Scapy
31 papers 6 spellings ZGrab
[vantage-platform] union 77 papers corpus-wide, 24 of them in DNSPOP — reported only, NOT in the population rule
75 papers 6 spellings RIPE Atlas
2 papers 1 spellings MobileAtlas
--- E2. FAMILY DETAIL FOR THE FAMILIES THE PAGE DESCRIBES IN PROSE ---
DNS fingerprinting (fpdns): 7 papers
by year: 2018:1 2023:3 2024:3
by spelling: fpdns x7
in DNSPOP: 7, of which IMC: 0
DNSViz and DNSSEC validators: 3 papers
by year: 2014:1 2023:1 2025:1
by spelling: DNSViz x2 | Extended DNSSEC Validator x1 | DNSSEC-downgrade tool x1
in DNSPOP: 3, of which IMC: 1
dig / drill / nslookup / tor-resolve: 18 papers
by year: 2010:2 2015:2 2019:4 2020:2 2021:4 2023:1 2024:1 2025:2
by spelling: dig x12 | nslookup x2 | Dig x1 | host name matching tool x1 | drill x1 | tor-resolve x1
in DNSPOP: 18, of which IMC: 7
RIPE Atlas: 75 papers
by year: 2015:4 2016:6 2017:7 2018:10 2019:5 2020:10 2021:5 2022:7 2023:5 2024:5 2025:6 2026:5
by spelling: RIPE Atlas x72 | RIPE Atlas API x2 | RIPE Atlas REST API x1 | RIPE Atlas streaming API x1 | RIPE Atlas measurement platform x1 | RIPE Atlas probes x1
in DNSPOP: 24, of which IMC: 21
MobileAtlas: 2 papers
by year: 2023:1 2025:1
by spelling: MobileAtlas x2
in DNSPOP: 0, of which IMC: 0
Sum of family paper counts is NOT the union: a paper naming BIND and Unbound is in both rows.
--- F. FOLD RESIDUE AND WHAT WAS DELIBERATELY EXCLUDED ---
candidate tool tuples matched by the loose sweep: 976
unmapped residue: 2 distinct strings, 2 tuples
1 "IEEE Organizationally Unique Identifier registry"
1 "Chrome DevTools Protocol Network domain"
mapped but excluded from the population rule (papers):
113 adjacent:registry-metadata — WHOIS / RDAP
112 scanner-generic — ZMap / XMap
75 vantage-platform — RIPE Atlas
52 adjacent:registry-metadata — Public Suffix List / TLD lists
50 offtopic:speech — speech recognition / synthesis
46 offtopic:hardware — lab hardware matching /dot|host|dig/
33 scanner-generic — Scapy
31 scanner-generic — ZGrab
21 offtopic:annotation — ATLAS.ti
18 offtopic:blocklist — domain blocklists
13 offtopic:ml — ML models matching /bind|nsd|dot/
11 adjacent:categorisation — domain categorisation services
7 adjacent:registrar — registrar and domain-shopping APIs
6 offtopic:nlp — part-of-speech tagging
4 adjacent:registry-metadata — DomainTools WHOIS archive
4 adjacent:name-analysis — domain-string analysis (DGA detection, shadowing)
3 adjacent:typosquatting — dnstwist
2 offtopic:blocklist — DNS-based lists (DNSBL / DNSEL)
2 adjacent:categorisation — OpenDNS/Umbrella as a categoriser
2 offtopic:blocklist — NextDNS blocklist
2 vantage-platform — MobileAtlas
1 offtopic:misc — Graphviz DOT
1 adjacent:geolocation — RIPE IPmap
1 adjacent:mdns — multicast DNS
1 offtopic:database — MongoDB Atlas
1 offtopic:misc — hand-excluded homograph
--- G. ENCRYPTED DNS AND WHEN IT ARRIVED (denominator: whole corpus per bucket) ---
Full-text sweeps, paper-counted. These are UPPER BOUNDS on "the paper engages
with this": a single sentence in related work counts. Read them as arrival dates.
protocol 2010–2013 2014–2017 2018–2021 2022–2024 2025–2026* total
DoH (DNS-over-HTTPS) 0/510 0/768 30/1437 34/1955 18/1185 82
DoT (DNS-over-TLS) 0/510 0/768 27/1437 13/1955 7/1185 47
DoQ (DNS-over-QUIC) 0/510 0/768 4/1437 4/1955 2/1185 10
ODoH (Oblivious DoH) 0/510 0/768 7/1437 5/1955 2/1185 14
DDR (Discovery of Designated Resolvers) 0/510 0/768 0/1437 0/1955 1/1185 1
DNSSEC 7/510 25/768 51/1437 53/1955 25/1185 161
ECS (EDNS Client Subnet) 1/510 3/768 11/1437 3/1955 2/1185 20
DNSCurve / DNSCrypt 0/510 1/768 8/1437 2/1955 1/1185 12
DoC (DNS over CoAP) 0/510 0/768 0/1437 0/1955 0/1185 0
(bare CoAP, for contrast) 0/510 2/768 4/1437 7/1955 7/1185 20
Same sweeps restricted to DNSPOP (the papers that are actually about DNS):
protocol 2010–2013 2014–2017 2018–2021 2022–2024 2025–2026* total
DoH (DNS-over-HTTPS) 0/16 0/39 23/76 16/74 9/39 48
DoT (DNS-over-TLS) 0/16 0/39 23/76 7/74 4/39 34
DoQ (DNS-over-QUIC) 0/16 0/39 4/76 1/74 1/39 6
ODoH (Oblivious DoH) 0/16 0/39 5/76 4/74 2/39 11
DDR (Discovery of Designated Resolvers) 0/16 0/39 0/76 0/74 1/39 1
DNSSEC 3/16 12/39 36/76 37/74 16/39 104
ECS (EDNS Client Subnet) 1/16 2/39 9/76 3/74 1/39 16
DNSCurve / DNSCrypt 0/16 1/39 8/76 1/74 1/39 11
DoC (DNS over CoAP) 0/16 0/39 0/76 0/74 0/39 0
(bare CoAP, for contrast) 0/16 0/39 0/76 1/74 0/39 1
--- H. WHAT A DNS PAPER SAYS ABOUT ITS OWN METHOD ---
names a vantage location
DNSPOP 124 / 244 50.8%
A (titled) 63 / 108 58.3%
B-only (instrument) 61 / 136 44.9%
scan branch (network-scan-or-probe) 487 / 930 52.4%
crawled population 301 / 1120 26.9%
names any used/produced tool version
DNSPOP 103 / 244 42.2%
A (titled) 46 / 108 42.6%
B-only (instrument) 57 / 136 41.9%
scan branch (network-scan-or-probe) 401 / 930 43.1%
crawled population 506 / 1120 45.2%
states artifacts.availability (non-sentinel, non-none)
DNSPOP 124 / 244 50.8%
A (titled) 57 / 108 52.8%
B-only (instrument) 67 / 136 49.3%
scan branch (network-scan-or-probe) 511 / 930 54.9%
crawled population 721 / 1120 64.4%
vantage.locations, folded count of DISTINCT stated location strings per paper (DNSPOP):
0 (none stated) 120 49.2%
1 46 18.9%
2–3 40 16.4%
4–10 35 14.3%
>10 3 1.2%
ethics (denominator: DNSPOP ∩ empirical):
ethics.reviewOutcome 72 / 241 29.9%
ethics.harmMitigation 186 / 241 77.2%
ethics.notifiedAffectedParties 147 / 241 61.0%
ethics.regulatorContact 132 / 241 54.8%
ethics, DNS population vs the whole empirical corpus:
ethics.reviewOutcome DNS 72/241 29.9% corpus 1728/5118 33.8%
ethics.harmMitigation DNS 186/241 77.2% corpus 3186/5118 62.3%
ethics.notifiedAffectedParties DNS 147/241 61.0% corpus 2354/5118 46.0%
ethics.regulatorContact DNS 132/241 54.8% corpus 2129/5118 41.6%
ethics.robotsTxt over the crawled population: 53 / 1120 = 4.7%
amplification/reflection full-text probe over DNSPOP: 58 / 244
of which say so in the title or slug: 15
open-resolver full-text probe over DNSPOP: 54 / 244
--- H2. LLM PROBE OVER DNSPOP (case-sensitive; a hit is not a method) ---
regex: /\b(?:LLM|large language model|GPT-[345]|ChatGPT|Llama|Gemini|Claude)\b/
papers: 16 / 244
by window: 2010–2013 0 2014–2017 0 2018–2021 3 2022–2024 5 2025–2026* 8
case-INsensitive, for contrast: 19 papers, by window 0/0/3/7/9
The four roles below are HAND-READ verdicts over all of the case-sensitive hits,
not a further probe. They are listed with their deciding text on the provenance page.
2020/NDSS/flowprint-semi-supervised-mobile-app-fingerprinting-on-encrypted-network-traffic
2021/IMC/the-far-side-of-dns-amplification-tracing-the-ddos-attack-ecosystem-from-the-int
2021/PETS/the-cname-of-the-game-large-scale-analysis-of-dns-based-tracking-evasion
2022/IMC/investigating-the-impact-of-ddos-attacks-on-dns-infrastructure
2023/PETS/heads-in-the-clouds-measuring-universities-migration-to-public-clouds-implicatio
2024/CCS/poster-dohunter-a-feature-fusion-based-llm-for-doh-tunnel-detection
2024/USENIX/guardians-of-the-galaxy-content-moderation-in-the-interplanetary-file-system
2024/IEEE-SP/practical-attacks-against-dns-reputation-systems
2025/USENIX/dns-flare-a-flush-reload-attack-on-dns-forwarders
2025/IMC/decoding-dnssec-errors-at-scale-an-automated-dnssec-error-resolution-framework-u
2025/IMC/fishing-for-smishing-understanding-sms-phishing-infrastructure-and-strategies-by
2026/NDSS/repairing-trust-in-domain-name-disputes-practices-insights-from-a-quarter-centurys-worth-of-squabbles
2026/PETS/more-space-less-privacy-measuring-the-effectiveness-of-ip-based-website-fingerpr
2026/USENIX/the-state-of-passkeys-studying-the-adoption-and-security-of-passkeys-on-the-web
2026/WWW/unveiling-the-resilience-of-llm-enhanced-search-engines-against-black-hat-seo-ma
2026/WWW/starlink-in-the-wild-multi-perspective-measurements-via-dns
--- G2. RECORD TYPES AND ADDRESS FAMILY (denominator: DNSPOP) ---
AAAA / IPv6 record 65 / 244 26.6%
CNAME record 75 / 244 30.7%
SVCB or HTTPS resource record 8 / 244 3.3%
NS / delegation 97 / 244 39.8%
PTR / reverse 61 / 244 25.0%
TXT record 24 / 244 9.8%
TC bit / truncation / fallback to TCP 22 / 244 9.0%
--- I. MEASURED RESULTS IN THE POPULATION (detection[].prevalence) ---
DNS-named detection tuples carrying a numeric prevalence: 536 across 193 of 244 DNSPOP papers (79.1%).
prevalence is a MODEL SUMMARY of the paper's result, not a quote. Every figure
quoted on the page was re-checked against paper.cols.txt — see verify_dns_figures.mjs.
The fold
scripts/dns_fold.mjs. Ordered families, first match wins, keyed exceptions before the family that would swallow them. Three problems it exists to solve, all found by reading the strings rather than by guessing:
- A candidate sweep loose enough to catch the real instruments catches everything. It has to match
hnsd,ldns,resolvectl,miekg/dnsandgdnsd, and any regex that loose also matchesDeepSpeech(via /ech\b/),ImageBindandLanguageBind(/bind\b/),TransD(/nsd\b/),ATLAS.tiandMongoDB Atlas(/atlas/), every part-of-speech tagger, andGhost.py/CyberGhost VPN(/host\b/). Those get namedofftopic:families so the discard is a number, not a silence. - One brand, several products.
OpenDNSis a public resolver and a website categorisation service, and the corpus uses it both ways.NextDNSis a resolver and a published blocklist.DomainToolssells passive DNS and a WHOIS archive. Keyed exceptions run first. - A name that cannot be resolved from the name. Rapid7 Open Data is four datasets under one brand (FDNS, RDNS, SSL certificates, TCP/UDP liveness) and half the corpus tuples say only
Rapid7orRapid7 Sonar. The Rapid7 family therefore carries a guard regex tested against name + the extractor's purpose sentence, requiring /dns/i. The candidate regex matches 13 tuples under 11 distinct spellings; all 13 were read by hand and the guard decides all 13 the way the reading did:
| Tuple | Purpose | Guard verdict |
|---|---|---|
| Rapid7 Sonar (CCS 2015, Caronte) | “Matched hidden-service certificates to Internet IP addresses” | excluded — certificates |
| Rapid7 SSL Certificate Scans (IMC 2015) | “Provided full IPv4 port 443 certificate scans” | excluded — certificates |
| Rapid7 Labs Open Data (USENIX 2021) | “Supplied full-IPv4-range scan results for liveness checks” | excluded — liveness |
| Rapid7 NeXpose (IEEE S&P 2010) | “Scan test applications for web vulnerabilities” | excluded — a vulnerability scanner, not Open Data |
| Rapid7 (CCS 2016) | “Internet-wide HTTPS and reverse-DNS scan datasets” | included |
| Rapid7 (IMC 2022, iGDB) | “Provide reverse-DNS mappings from IP addresses to hostnames” | included |
| Rapid7's passive DNS (NDSS 2019 and NDSS 2021, two tuples) | “Identify enterprise cloud-hosting IP addresses” / “Resolve domains and discover organization-controlled domains” | included |
| Rapid7 Forward DNS (IMC 2020) | “Collect reverse-DNS and zone-file domains for VPN identification” | included |
| Forward DNS dataset (IMC 2016, Entropy/IP) | “Collected actively queried DNS addresses” | included |
| Rapid7 Sonar FDNS / RDNS (PoPETs 2021, two tuples) | “Validated historical CNAME detection completeness” / “Checked historical tracker IP ownership” | included |
| Rapid7 sonar.udp (CCS 2022) | “Select open DNS resolvers for comparison” | included |
| Rapid7 (IMC 2022, iGDB) | “Provide reverse-DNS mappings from IP addresses to hostnames” | included |
One keyed (name, category) exclusion that no name regex can make: DIG with category == “program-analysis” (IEEE S&P 2024, Everything is Good for Something) is a likely-invariant inference engine, purpose “Likely-invariant inference engine”, not dig(1).
Seven mis-bucketings found by reading the instrument-only list and the folded family listings, and fixed in the fold, each of which would have added a non-DNS paper to the population: Khost (a KVM firmware-rehosting tool, matched a khost alternative that should never have been there), XMLdig-to-CSV converter (oscilloscope traces), DNSCAN (a clustering algorithm in a backdoor-forensics paper), USB2SOFT USB 2.0 device SIE (matched /\bsie\b/ intended for Farsight's Security Information Exchange), Rapid7 NeXpose, and DIG. A seventh, “Miek Gieben's DNS implementation”, was landing in the home-grown family via a generic /dns.*implementation/ alternative when it is in fact miekg/dns, the Go library; that moved home-grown from 35 papers to 34 and DNS libraries from 15 to 16, and it is why the page's home-grown claim is worded as “almost no two called it the same thing” rather than as a clean 35/35.
Fold residue, in full
Loose candidate sweep over tools[] (used or produced), regex:
/dns|resolver|bind\b|unbound|knot|nsd\b|powerdns|maradns|dnsmasq|djbdns|dnscache|zone ?file|czds|openintel|farsight|dnsdb|passive ?dns|massdns|zmap|xmap|zgrab|dig\b|kdig|drill\b|nslookup|host\b|ripe ?atlas|atlas|whois|rdap|public suffix|psl\b|domain|tld|registr|doh|dot\b|doq|odoh|ech\b|adns|getdns|dnspython|scapy|resolv/i
976 candidate tuples. 2 unmapped, both off-topic: “IEEE Organizationally Unique Identifier registry” (1 tuple) and “Chrome DevTools Protocol Network domain” (1 tuple). Neither is a DNS instrument and neither is in the population.
Section F of the report prints the residue and the full table of mapped-but-excluded families with their paper counts.
Hand-read verdicts
All 136 instrument-only papers were read
Each was read as (tool name, extractor purpose sentence). The dump is out/dns/bonly_audit_raw.txt. The overwhelming majority are genuine: resolving a name list with ZDNS or massdns, pulling history out of Farsight or OpenINTEL, standing up BIND or Unbound to test cache behaviour, querying public resolvers for comparison.
Seven are a DNS server inside an attack or lab rig rather than a measurement of DNS in the world. They stay in the population — they did use a DNS-specific instrument, and excluding them would need a judgement the rule does not encode — but the count is published on the page so a reader can subtract it. The list, with the deciding purpose, is the LAB_RIG map in report_dns.mjs; the report prints HAND-MAP STALE if any of them leaves the population:
| Paper | Deciding text |
|---|---|
NDSS 2019 badbluetooth-… | dnsmasq “Provided DHCP and DNS services for PAN attacks” |
NDSS 2020 imp4gt-… | dnsmasq “Provided the malicious DNS server” |
WWW 2019 unveil-capture-and-visualise-wifi-data-leakages | dnsmasq “Create rogue WiFi access points” |
USENIX 2023 bypassing-tunnels-… | dnsmasq “Returned spoofed VPN-server IP addresses through DNS” |
CCS 2025 deep-dive-into-in-app-browsers-… | Dnsmasq “Resolved test domains to the local web server” |
IMC 2024 iot-bricks-over-v6-… | dnsmasq “Provided DHCPv4, DHCPv6, SLAAC, and RDNSS” |
IEEE S&P 2014 when-https-meets-cdn-… | Extended DNSSEC Validator “Provided the Firefox extension base for modification” |
The sixteen LLM papers were read, and the probe count is not the claim
/\b(?:LLM|large language model|GPT-[345]|ChatGPT|Llama|Gemini|Claude)\b/ over the 244 gives 16 papers, 0 / 0 / 3 / 5 / 8 across the five windows. A probe hit is not a method, so all sixteen were read:
| Role | Papers |
|---|---|
| LLM is the DNS classifier | 1 — CCS 2024 poster, DoHunter (DoH tunnel detection) |
| LLM interprets hostname or domain strings inside a conventional pipeline | starlink-in-the-wild (reverse-DNS hostname semantics), dns-flare (ChatGPT filters shared CDN domains), guardians-of-the-galaxy (Bard/Llama2 label file targets), repairing-trust-in-domain-name-disputes (GPT-4o geocoding fallback), practical-attacks-against-dns-reputation-systems (LLM generates adversarial domain names) |
| LLM as a baseline that lost | IMC 2025 decoding-dnssec-errors-at-scale — compares against “naive LLM-based prompt engineering” with GPT-4o |
| Related work, limitations, or a generative-AI acknowledgement only | more-space-less-privacy, the-state-of-passkeys, fishing-for-smishing, and the remainder |
Conclusion published on the page, and the reason it is worded the way it is: an LLM is a defensible labelling aid for hostname semantics; it is not current practice for classifying DNS behaviour on this evidence; and the years the signal lives in (2025–2026) are the provisional ones. The page says so in the same sentence as the counts.
Quotes and per-paper figures
scripts/verify_dns_figures.mjs checks every literal per-paper figure and every quoted sentence against paper.cols.txt with whitespace collapsed, smart quotes folded and dashes normalised. 31 needles, 0 not found (30 located in paper.cols.txt, 1 in paper.pdf only — see the box below). Unedited output:
ok [.cols] 2018/USENIX/who-is-answering-my-queries-understanding-and-characterizing-interception-of-the
259 of the 3,047 ASes (8.5%) that we inspect exhibit DNS interception behavior
ok [.cols] 2018/USENIX/who-is-answering-my-queries-understanding-and-characterizing-interception-of-the
148,478 residential and cellular IP addresses
ok [.cols] 2022/USENIX/many-roads-lead-to-rome-how-packet-headers-influence-dns-censorship-measurement
that 37% of IPs across 56% ASes measured show some change in censorship behavior depending on source port and local source IP
ok [.cols] 2022/USENIX/many-roads-lead-to-rome-how-packet-headers-influence-dns-censorship-measurement
This behavior is frequently all-or-nothing
ok [.cols] 2017/USENIX/global-measurement-of-dns-manipulation
41,778 responses (0.31%) as manipulated, spread across 58 countries
ok [.cols] 2017/USENIX/global-measurement-of-dns-manipulation
1,408 domains
ok [.cols] 2017/USENIX/global-measurement-of-dns-manipulation
13,594,683 DNS responses
ok [.cols] 2023/PETS/certainty-detecting-dns-manipulation-at-scale-using-tls-certificates
17 TLS proxy vendors in 52 countries
ok [.cols] 2023/PETS/certainty-detecting-dns-manipulation-at-scale-using-tls-certificates
55 ASes in 26 countries with ISP-level DNS manipulation
ok [.cols] 2023/PETS/certainty-detecting-dns-manipulation-at-scale-using-tls-certificates
previous work using consistency-based heuristics is inaccurate, allowing for 72.45% false positives in the cases detected as DNS manipulation
ok [.cols] 2022/IMC/zdns-a-fast-dns-toolkit-for-internet-measurement
90K lookups per second when using an external recursive resolver
ok [.cols] 2022/IMC/zdns-a-fast-dns-toolkit-for-internet-measurement
solves 50M domains in 10 minutes
ok [.cols] 2021/PETS/the-cname-of-the-game-large-scale-analysis-of-dns-based-tracking-evasion
we detected a total of 10,474 websites (eTLD+1) that used at least one of the trackers
ok [.cols] 2010/IMC/comparing-dns-resolvers-in-the-wild
fer in terms of subnets for approximately 2, 000 out of our
ok [.cols] 2010/IMC/comparing-dns-resolvers-in-the-wild
10, 000 host names. In half of these cases, the returned IP
ok [.cols] 2010/IMC/comparing-dns-resolvers-in-the-wild
addresses even belong to di
ok [.cols] 2019/IMC/a-look-at-the-ecs-behavior-of-dns-resolvers
3382 out of 4147 resolvers in the CDN dataset send 100% of their A and AAAA queries with an ECS option
ok [.cols] 2019/IMC/a-look-at-the-ecs-behavior-of-dns-resolvers
103 recursive resolvers, or over half of all recursive resolvers we could study
ok [.cols] 2019/IMC/a-look-at-the-ecs-behavior-of-dns-resolvers
don't control caching based on scope at all
ok [.cols] 2015/IMC/going-wild-large-scale-classification-of-open-dns-resolvers
find up to 20 million open resolvers in the weekly IPv4 scans
ok [.cols] 2025/PETS/path-to-encrypted-dns-with-ddr-adoption-configuration-patterns-and-privacy-impli
In over 99 % of observed cases
ok [.cols] 2025/PETS/path-to-encrypted-dns-with-ddr-adoption-configuration-patterns-and-privacy-impli
DDR-compliant clients may fail to upgrade to DoE due to
ok [.cols] 2021/IMC/home-is-where-the-hijacking-is-understanding-dns-interception-by-residential-rou
occurrences of such trans- 3 parent interception
ok [.cols] 2020/NDSS/encrypted-dns-privacy-a-traffic-analysis-perspective
domains with high accuracy in closed and open world settings, using 124 times less data than attacks on HTTPS flows
ok [.cols] 2020/NDSS/encrypted-dns-privacy-a-traffic-analysis-perspective
We can identify resolvers
ok [.cols] 2020/NDSS/encrypted-dns-privacy-a-traffic-analysis-perspective
with 95% accuracy
WEAK NEEDLE 2020/NDSS/encrypted-dns-privacy-a-traffic-analysis-perspective: "with 95% accuracy" — short enough to match by accident
ok [PDF only] 2023/USENIX/user-awareness-and-behaviors-concerning-encrypted-dns-settings-in-web-browsers
73% of all participants reported having heard of DNS before the survey
ok [.cols] 2023/USENIX/user-awareness-and-behaviors-concerning-encrypted-dns-settings-in-web-browsers
ipants who reported having heard of DNS, only 59.9% had
ok [.cols] 2023/USENIX/user-awareness-and-behaviors-concerning-encrypted-dns-settings-in-web-browsers
85 (79.4%) had the default
ok [.cols] 2025/IMC/decoding-dnssec-errors-at-scale-an-automated-dnssec-error-resolution-framework-u
naive LLM-based prompt engineering
ok [.cols] 2025/IMC/decoding-dnssec-errors-at-scale-an-automated-dnssec-error-resolution-framework-u
concrete, verifiably correct fixes
31 needles checked, 0 not found, 0 papers unreadable.
--- QUOTES THE PAGE NORMALISES (source spelling -> page spelling) ---
"2 , 000" -> "2,000" (stray space in both the .cols rendering and the PDF (Ager et al., IMC 2010))
"10, 000" -> "10,000" (stray space in both the .cols rendering and the PDF (Ager et al., IMC 2010))
"dif- fer" -> "differ" (line-break hyphenation (Ager et al., IMC 2010))
--- FIGURES ON THE PAGE THAT ARE NOT FROM A CITED PAPER ---
population, venue, year, study-shape and web-slice counts
<- report_dns.mjs sections A-D
composite venue shares stated in prose
<- report_dns.mjs section B
instrument family counts, spelling counts, per-family year detail
<- report_dns.mjs sections E and E2
fold residue, candidate-tuple count, fold self-test count
<- report_dns.mjs section F and `node scripts/dns_fold.mjs`
encrypted-DNS per-window probe counts
<- report_dns.mjs section G
reporting-gap, vantage-bucket, ethics and amplification figures
<- report_dns.mjs section H
LLM probe counts, case-sensitive and case-insensitive
<- report_dns.mjs section H2
the 7 lab-rig papers
<- the LAB_RIG hand map in report_dns.mjs, which the report cross-checks
robots.txt reporting rate for the crawled population
<- data/extract/OVERVIEW.md, "Where the field goes quiet"
every resolver-run figure: verdict tallies, both summary denominators, TTLs
<- out/dns/resolver_run.txt and resolver_run.json, from pages/resolver_disagreement.py
the Tranco list id
<- tranco-list.eu, fetched 2026-08-27; recorded in the provenance page
RFC numbers, dates, statuses and obsoleted-by
<- external_checks_dns.sh, RFC block
tool versions, release and push dates, archived state, git tags
<- external_checks_dns.sh, GitHub/PyPI/Go-proxy blocks
vendor state: Farsight resolution, dnsdb.info and Rapid7 redirect targets, dataset dates
<- external_checks_dns.sh, Farsight and Rapid7 blocks
Firefox trr prefs and the DoH provider records
<- external_checks_dns.sh, Firefox blocks
the APNIC DDR figures and the ANRW Crossref record
<- external_checks_dns.sh, APNIC and ANRW blocks
This block names artefacts, not values. Run the named artefact for the number.
Where the extraction's prevalence did not survive the check. detection[].prevalence is a model summary of a result, not a quote, and four figures taken from it could not be located in the paper and were rewritten from the paper's own words before publication:
prevalence said | The paper says |
|---|---|
| “3,382 of 4,147 resolvers sent 100% of A and AAAA queries with ECS” | “3382 out of 4147 resolvers in the CDN dataset send 100% of their A and AAAA queries with an ECS option” |
| “103 resolvers ignored scope when reusing cached responses” | “we find 103 recursive resolvers, or over half of all recursive resolvers we could study, that don't control caching based on scope at all” |
| “95% resolver accuracy and 100% client accuracy” | “We built classifiers to distinguish resolver and client based on the TLS record length. We can identify resolvers with 95% accuracy, and we get no errors (100% accuracy) when identif[ying]…” — the 100% is the client, not the resolver; the page no longer pairs them |
| “DNS manipulation … 17 TLS proxy vendors in 52 countries and ISP-level manipulation in 26 countries” | two separate sentences: “CERTainty identifies 17 TLS proxy vendors in 52 countries” and “CERTainty also detects 55 ASes in 26 countries with ISP-level DNS manipulation” |
| “73% reported having heard of DNS” (Nisenoff et al., USENIX Security 2023) | In the PDF, absent from paper.cols.txt. See the note below — this one is a checker bug, not a source problem, and it was caught by a reviewer. |
The fourth is the one to remember: the extraction had fused two findings into one sentence, and quoting it would have invented a claim the paper does not make.
paper.cols.txt can be missing content the PDF has, and checking only .cols scores a faithful quote as a fabrication. Nisenoff et al.'s “73% of all participants reported having heard of DNS before the survey” is verbatim in paper.pdf and is not in paper.cols.txt at all; the only “73” near “heard of DNS” in the .cols rendering is the string “Firefox 73”, a browser version number in a settings table. Working only from .cols, this run concluded the figure was unverifiable and removed it from the page. The citations reviewer said it was in the paper; a pypdf re-extraction settled it in the reviewer's favour, the figure is back on the page as a verbatim quote, and verify_dns_figures.mjs now falls back to pypdf for any needle that misses against .cols and labels the route it was found by. One of the 31 needles is PDF only. Without that fallback the whole quote check was one rendering away from a false negative on every quote it examined.
One figure was dropped, not rewritten. The extraction reports “49 out of 220 intercepted probes” for Randall et al. (IMC 2021). Neither number could be located in paper.cols.txt by any probe tried. The page quotes the paper's own abstract claim (“over 200 occurrences of such transparent interception”) instead and makes no 49/220 claim.
One quote is normalised and says so on the page. Ager et al. (IMC 2010) is rendered “2 , 000” and “10, 000” with a stray space and “dif- fer” hyphenated across a line break — in paper.cols.txt and in a pypdf re-extraction of paper.pdf, so it is the source's own typesetting, not a column-repair artefact. The page carries a footnote saying so.
External checks
scripts/external_checks_dns.sh. Every check prints FAILED explicitly, so a 403 or a rate limit cannot read as a pass. Unedited output:
== run date (UTC)
2026-08-27T23:18:41Z
== RFCs the page names: status, obsoleted-by, updated-by
RFC1034 November 1987 INTERNET STANDARD obs_by=- upd_by=RFC1101,RFC1183,RFC1348,RFC1876,RFC1982,RFC2065,RFC2181,RFC2308,RFC2535,RFC4033,RFC4034,RFC4035,RFC4343,RFC4592,RFC5936,RFC8020,RFC8482,RFC8767,RFC9471 Domain names - concepts and facilities
RFC1035 November 1987 INTERNET STANDARD obs_by=- upd_by=RFC1101,RFC1183,RFC1348,RFC1876,RFC1982,RFC1995,RFC1996,RFC2065,RFC2136,RFC2137,RFC2181,RFC2308,RFC2535,RFC2673,RFC2845,RFC3425,RFC3658,RFC4033,RFC4034,RFC4035,RFC4343,RFC5936,RFC5966,RFC6604,RFC7766,RFC8482,RFC8490,RFC8767,RFC9619 Domain names - implementation and specification
RFC2181 July 1997 PROPOSED STANDARD obs_by=- upd_by=RFC2535,RFC4033,RFC4034,RFC4035,RFC4343,RFC5452,RFC8767 Clarifications to the DNS Specification
RFC4033 March 2005 PROPOSED STANDARD obs_by=- upd_by=RFC6014,RFC6840 DNS Security Introduction and Requirements
RFC4034 March 2005 PROPOSED STANDARD obs_by=- upd_by=RFC4470,RFC6014,RFC6840,RFC6944,RFC9077,RFC9824,RFC9905 Resource Records for the DNS Security Extensions
RFC4035 March 2005 PROPOSED STANDARD obs_by=- upd_by=RFC4470,RFC6014,RFC6840,RFC8198,RFC9077,RFC9520,RFC9824 Protocol Modifications for the DNS Security Extensions
RFC5001 August 2007 PROPOSED STANDARD obs_by=- upd_by=- DNS Name Server Identifier (NSID) Option
RFC6891 April 2013 INTERNET STANDARD obs_by=- upd_by=- Extension Mechanisms for DNS (EDNS(0))
RFC7766 March 2016 PROPOSED STANDARD obs_by=- upd_by=RFC8490,RFC9103 DNS Transport over TCP - Implementation Requirements
RFC7858 May 2016 PROPOSED STANDARD obs_by=- upd_by=RFC8310 Specification for DNS over Transport Layer Security (TLS
RFC7871 May 2016 INFORMATIONAL obs_by=- upd_by=- Client Subnet in DNS Queries
RFC8310 March 2018 PROPOSED STANDARD obs_by=- upd_by=- Usage Profiles for DNS over TLS and DNS over DTLS
RFC8484 October 2018 PROPOSED STANDARD obs_by=- upd_by=- DNS Queries over HTTPS (DoH)
RFC8499 January 2019 BEST CURRENT PRACTICE obs_by=RFC9499 upd_by=- DNS Terminology
RFC8767 March 2020 PROPOSED STANDARD obs_by=- upd_by=- Serving Stale Data to Improve DNS Resiliency
RFC8914 October 2020 PROPOSED STANDARD obs_by=- upd_by=- Extended DNS Errors
RFC9156 November 2021 PROPOSED STANDARD obs_by=- upd_by=- DNS Query Name Minimisation to Improve Privacy
RFC9230 June 2022 EXPERIMENTAL obs_by=- upd_by=- Oblivious DNS over HTTPS
RFC9250 May 2022 PROPOSED STANDARD obs_by=- upd_by=- DNS over Dedicated QUIC Connections
RFC9276 August 2022 BEST CURRENT PRACTICE obs_by=- upd_by=- Guidance for NSEC3 Parameter Settings
RFC9460 November 2023 PROPOSED STANDARD obs_by=- upd_by=- Service Binding and Parameter Specification via the DNS
RFC9462 November 2023 PROPOSED STANDARD obs_by=- upd_by=- Discovery of Designated Resolvers
RFC9463 November 2023 PROPOSED STANDARD obs_by=- upd_by=- DHCP and Router Advertisement Options for the Discovery
RFC9499 March 2024 BEST CURRENT PRACTICE obs_by=- upd_by=- DNS Terminology
RFC9520 December 2023 PROPOSED STANDARD obs_by=- upd_by=- Negative Caching of DNS Resolution Failures
RFC9539 February 2024 EXPERIMENTAL obs_by=- upd_by=- Unilateral Opportunistic Deployment of Encrypted Recursi
RFC9567 April 2024 PROPOSED STANDARD obs_by=- upd_by=- DNS Error Reporting
RFC9606 June 2024 PROPOSED STANDARD obs_by=- upd_by=- DNS Resolver Information
RFC9848 March 2026 PROPOSED STANDARD obs_by=- upd_by=- Bootstrapping TLS Encrypted ClientHello with DNS Service
RFC9953 March 2026 PROPOSED STANDARD obs_by=- upd_by=- DNS over CoAP (DoC)
== GitHub repositories: archived state, last push, latest release
zmap/zdns archived=False pushed=2026-08-24 stars=1131
latest release v2.1.1 on 2026-05-28
zmap/zmap archived=False pushed=2026-08-26 stars=6366
latest release v4.4.0 on 2026-05-29
blechschmidt/massdns archived=False pushed=2026-04-15 stars=3635
latest release v1.1.0 on 2024-03-09
dnsviz/dnsviz archived=False pushed=2025-04-21 stars=1246
latest release v0.11.1 on 2025-04-21
rthalley/dnspython archived=False pushed=2026-08-25 stars=2670
latest release v2.8.0 on 2025-09-07
miekg/dns archived=False pushed=2026-08-19 stars=8763
no GitHub release object: Not Found
NLnetLabs/unbound archived=False pushed=2026-08-26 stars=4822
latest release release-1.26.0 on 2026-08-04
NLnetLabs/nsd archived=False pushed=2026-08-26 stars=569
latest release NSD_4_15_1_REL on 2026-08-26
isc-projects/bind9 archived=False pushed=2026-08-27 stars=763
no GitHub release object: Not Found
PowerDNS/pdns archived=False pushed=2026-08-27 stars=4456
no GitHub release object: Not Found
CZ-NIC/knot-resolver archived=False pushed=2026-08-27 stars=461
no GitHub release object: Not Found
imp/dnsmasq archived=False pushed=2026-03-16 stars=389
no GitHub release object: Not Found
DNS-OARC/dnsperf archived=True pushed=2026-02-04 stars=478
latest release v2.14.0 on 2024-01-18
DNSCrypt/dnscrypt-proxy archived=False pushed=2026-08-27 stars=13605
latest release 2.1.18 on 2026-07-18
== miekg/dns has no GitHub Release object but DOES have semver tags
git tags: ['v1.1.73', 'v1.1.72', 'v1.1.70', 'v1.1.69', 'v1.1.68']
go module proxy @latest: {"Version":"v1.1.73","Time":"2026-08-19T05:07:32Z","Origin":{"VCS":"git","URL":"https://github.com/miekg/dns","Hash":"d854399da1ee385b432e8b07f79e53bbfc1ab1b0","Ref":"refs/tags/v1.1.73"}}
== Android Private DNS transport: Google's own announcement
e devices. DNS-over-HTTP/3 (DoH3) support was released as part of a Google Play system update , so by the time you’re reading this, Android devices from Android 11 onwards 1 will use DoH3 instead of DoT for well-known 2 DNS servers which support it. Which DNS service you are using is unaffected by this change; only the transport will be upgraded. In th
== ANRW 2026 DDR paper (not in the seven-venue corpus), doi 10.1145/3822163.3827932
The Illusion of DDR Deployment
Yevheniya Nosyk; Andrzej Duda; Maciej Korczynski
Proceedings of the 2026 Applied Networking Research Workshop [[2026, 7, 20]]
== APNIC DDR write-up by the ANRW authors (the figures the page quotes)
ok By Yevheniya Nosyk on 2 Sep 2025
ok Andrzej Duda and Maciej Korczy
ok 321k DDR-enabled open resolvers
ok 80.8% of DDR-enabled resolvers designating dns.google
ok Cloudflare came second at 12.4%
ok 97.4% of DDR-enabled resolvers
== PyPI: dnspython
dnspython 2.8.0 2025-09-07
== HTTP status of every URL the page cites
200 https://openintel.nl/
200 https://atlas.ripe.net/
200 https://czds.icann.org/
200 https://www.domaintools.com/products/farsight-dnsdb/
200 https://opendata.rapid7.com/
200 https://opendata.rapid7.com/sonar.fdns_v2/
200 https://dnsviz.net/
200 https://stats.labs.apnic.net/dnssec
200 https://dnscrypt.info/public-servers
200 https://developers.google.com/speed/public-dns/docs/doh
200 https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/
200 https://www.quad9.net/
200 https://ooni.org/
200 https://censoredplanet.org/
200 https://sidnlabs.nl/
200 https://www.dns-oarc.net/
200 https://root-servers.org/
200 https://ithi.research.icann.org/
200 https://scans.io/
200 https://www.dnsdb.info/
== Rapid7 Open Data: where does the cited host redirect to, and is the data current
200 https://opendata.rapid7.com/ -> https://sonardata.rapid7.com/
200 https://opendata.rapid7.com/sonar.fdns_v2/ -> https://sonardata.rapid7.com/sonar.fdns_v2/
200 https://opendata.rapid7.com/sonar.rdns_v2/ -> https://sonardata.rapid7.com/sonar.rdns_v2/
/sonar.fdns_v2/ Forward DNS (FDNS) last=08/23/2026
/sonar.rdns_v2/ Reverse DNS (RDNS) last=08/26/2026
/sonar.http/ HTTP GET Responses last=08/27/2026
/sonar.https/ HTTPS GET Responses last=08/27/2026
/sonar.tcp/ TCP Scans last=08/27/2026
/sonar.ssl/ SSL Certificates last=08/27/2026
/sonar.moressl/ More SSL Certificates (non-443) last=08/18/2026
/sonar.udp/ UDP Scans last=08/06/2026
== Farsight / DomainTools: does the cited vendor still exist under that name
farsightsecurity.com RESOLVE FAILED: [Errno -2] Name or service not known
www.farsightsecurity.com RESOLVE FAILED: [Errno -2] Name or service not known
dnsdb.info A= 104.244.14.64
200 https://www.dnsdb.info/ -> https://www.domaintools.com/platform
200 https://www.domaintools.com/products/farsight-dnsdb/ -> https://www.domaintools.com/platform
== DNS-OARC DITL and the other community datasets
200 https://www.dns-oarc.net/oarc/data/ditl
404 https://www.dns-oarc.net/oarc/data
200 https://catalog.caida.org/
401 https://data.caida.org/datasets/
== Firefox DoH: the shipped prefs, read out of the tree
all.js bytes=200412 trr lines=6
pref("network.trr.uri", "");
pref("network.trr.custom_uri", "");
--- network.trr.mode compiled default (StaticPrefList.yaml)
- name: network.trr.mode
type: RelaxedAtomicUint32
value: 0
mirror: always
firefox.js bytes=185642 trr lines=1
== Mozilla DoH provider steering list (Remote Settings, no auth)
5 DoH provider records in Mozilla Remote Settings (collection: doh-providers)
Cloudflare autoDefault=True https://mozilla.cloudflare-dns.com/dns-query
Shaw autoDefault=False https://dns.shaw.ca/dns-query
autoDefault=False https://doh.xfinity.com/dns-query
NextDNS autoDefault=False https://firefox.dns.nextdns.io/
CIRA Canadian Shield autoDefault=False https://private.canadianshield.cira.ca/dns-query
== Chrome: secure-DNS enterprise policy page
200 chromeenterprise.google/policies/
== APNIC DNSSEC-validation measurement, world (primary source, today)
bytes=528440
Validation Capability Metrics div { background: transparent url(/images/bg-watermark
== done
What the external pass changed on the page
| Fact | How it was checked | Effect on the page |
|---|---|---|
| RFC 8499 is obsoleted by RFC 9499 | rfc-editor.org/rfc/rfc8499.json, field obsoleted_by | The page names 9499 as the current terminology reference and says 8499 is out of date. |
| RFC 7871 (ECS) is Informational, not a standard | same index, field status | Stated inline, because a methods section that calls ECS “the standard” is wrong. |
| RFC 9230 (ODoH) is Experimental | same | The page says so and warns against describing ODoH as a deployed default. |
farsightsecurity.com does not resolve at all; dnsdb.info resolves to 104.244.14.71 and 301s to domaintools.com/platform, as does /products/farsight-dnsdb/ | socket.getaddrinfo + curl -L -w %{url_effective} | The 28-paper Farsight row is marked “renamed and re-homed”, with the redirect target named. |
Rapid7 Open Data FDNS/RDNS is still published — sonar.fdns_v2 last updated 2026-08-23, sonar.rdns_v2 2026-08-26 | parsed out of opendata.rapid7.com | This corrected a wrong prior belief. The draft was going to say the bulk DNS downloads had been discontinued in 2022. They have not. The page says “still live, contrary to what a 2022-era memory will tell you”. |
Firefox's DoH default is not in the source tree — network.trr.mode has value: 0 in StaticPrefList.yaml and network.trr.uri is empty in all.js | raw.githubusercontent mozilla-firefox/firefox main | The page tells the reader to check the Remote Settings collection and a date/region, not the tree. |
Mozilla's doh-providers collection has 5 records, only Cloudflare with autoDefault: true | firefox.settings.services.mozilla.com/v1/buckets/main/collections/doh-providers/records, no auth | Published with the URL, so a reader can re-run it. |
DNS-OARC's dnsperf repository is archived (last push 2026-02-04, last release v2.14.0 2024-01-18) | GitHub API | Not named on the page as a current tool. |
Tool currency: ZDNS v2.1.1 (2026-05-28), zmap pushed 2026-08-24, massdns v1.1.0 (2024-03-09) pushed 2026-04-15, DNSViz v0.11.1 (2025-04-21), dnspython 2.8.0 (2025-09-07), dnscrypt-proxy 2.1.18 (2026-07-18), miekg/dns pushed 2026-08-19 with no tagged release | GitHub API, PyPI | Each row's “State on 2026-08-27” column, and the advice to pin miekg/dns by commit. |
What could not be established
- A current DNSSEC validation rate from a primary source.
stats.labs.apnic.net/dnssec/XAreturns 200 but renders its figures client-side;XA.jsonand thecgi-binendpoint are both 404, and no data URL is present in the HTML. No DNSSEC deployment percentage is published on the page; APNIC is not cited for a number. - A dated primary source for the DomainTools acquisition of Farsight Security.
domaintools.com/company/press-releases/is 404 and no newsroom index was found. The page therefore states only what was measured directly: the old domain does not resolve and the old product URLs redirect. No acquisition date is claimed. internetsociety.orgDNSSEC statistics returns 403 to this host. Not cited.radar.cloudflare.comreturns 403 to this host. Cloudflare Radar has DNS data and may be worth a future row, but nothing was verified, so nothing is claimed. See the red linkprogramming:cloudflare_radar.
The published script
pages/resolver_disagreement.py, embedded on the page as a <file python> block. Standard library only (Python 3.8+): the container has no dnspython, no dig, no drill and no nslookup, which turned out to be the right constraint — the script is meant to run on a measurement host without a package install.
Design decisions worth recording:
- No EDNS0. Adding an OPT record changes which resolvers answer, and adding an ECS option changes the answer. The docstring says so, because a silent EDNS choice is the kind of thing that makes a resolution unreproducible.
- Source-address check on the reply. It accepts a datagram only from the address it queried, and rejects a transaction-ID mismatch. This does not defend against an on-path forger — nothing at this layer does — but it stops a stray answer being recorded as that resolver's.
no-A-recordis a separate verdict frominsufficient. The first draft merged them and reported “25% insufficient”, which hid the actual finding: those 25 names have no A record at the apex, which is a property of the zone and the most common way a list-driven crawl loses rows silently.- Two summaries, and the script says which to quote. Summary A over all names mixes “resolvers did not all agree” with “there was nothing to disagree about” (25 of 100). Summary B is over the 75 comparable names. Quoting the summary-A share would understate the disagreement by hiding it behind the no-answer rate. The values are in the run output below and are deliberately not restated here: the first version of this bullet restated the pre-fix classifier's numbers, and they survived the fix that retracted them.
The run behind the page's numbers
Tranco top 100, list ID 46W9X, fetched from tranco-list.eu on 2026-08-27. Three public resolvers over Do53/UDP from a single European vantage point.
Three runs, and what moved between them. The list was run three times over about ninety minutes: twice under the original (buggy) classifier, then again after the pairwise fix, then again after the script gained TC-bit handling. identical came back 46 in every run and no-A-record 25 in every run, so not identical was 29 in every run. The split of those 29 moved — 28 disjoint and 1 same-/24 under the buggy all-at-once intersection, then 21 partial / 8 disjoint, then 19 partial / 10 disjoint — as CDN mappings churned under the measurement. That is why the page quotes not identical as its headline and treats the partial-versus-disjoint split as illustrative rather than as a result. It is also why this section states no verdict counts of its own: they belong in the run output below, which is regenerated from the script.
The <code> block on the page is generated by scripts/build_dns_codeblock.mjs from out/dns/resolver_run.txt, with a mechanical abridgement rule (two header lines, the first disjoint stanza with address lists cut after two entries, both summary blocks). It is regenerated rather than pasted, because the first draft pasted an earlier run's TTLs under a later run's timestamp — the exact failure the builder now prevents.
Full run output:
# resolvers: Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9)
# names: 100 run at 2026-08-27T23:17:26Z
google.com -> partial
Google NOERROR 13.1 ms ttl=126 172.217.208.100, 172.217.208.101, 172.217.208.102, 172.217.208.113, 172.217.208.138, 172.217.208.139
Cloudflare NOERROR 9.8 ms ttl=287 172.217.208.100, 172.217.208.101, 172.217.208.102, 172.217.208.113, 172.217.208.138, 172.217.208.139 (2nd query TTL 278: served from cache)
Quad9 NOERROR 14.4 ms ttl=278 192.178.183.100, 192.178.183.101, 192.178.183.102, 192.178.183.113, 192.178.183.138, 192.178.183.139 (2nd query TTL 185: served from cache)
cloudflare.com -> identical
Google NOERROR 12.7 ms ttl=300 104.16.132.229, 104.16.133.229 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 8.0 ms ttl=37 104.16.132.229, 104.16.133.229
Quad9 NOERROR 16.0 ms ttl=141 104.16.132.229, 104.16.133.229 (2nd query TTL 137: served from cache)
gstatic.com -> partial
Google NOERROR 25.0 ms ttl=300 172.217.208.120, 172.217.208.94 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 9.7 ms ttl=200 172.217.208.120, 172.217.208.94 (2nd query TTL 169: served from cache)
Quad9 NOERROR 14.5 ms ttl=149 142.251.14.120, 142.251.14.94 (2nd query TTL 141: served from cache)
facebook.com -> partial
Google NOERROR 13.4 ms ttl=60 157.240.17.35 (2nd query TTL 60: unchanged)
Cloudflare NOERROR 10.2 ms ttl=38 157.240.17.35 (2nd query TTL 23: served from cache)
Quad9 NOERROR 14.9 ms ttl=21 157.240.253.35
microsoft.com -> partial
Google NOERROR 13.5 ms ttl=505 150.171.110.56 (2nd query TTL 475: served from cache)
Cloudflare NOERROR 10.8 ms ttl=2455 150.171.110.56 (2nd query TTL 1180: served from cache)
Quad9 NOERROR 15.7 ms ttl=201 150.171.109.101
googleapis.com -> disjoint
Google NOERROR 39.5 ms ttl=300 74.125.29.103, 74.125.29.104, 74.125.29.105, 74.125.29.106, 74.125.29.147, 74.125.29.99 (2nd query TTL 164: served from cache)
Cloudflare NOERROR 10.1 ms ttl=172 172.217.208.103, 172.217.208.104, 172.217.208.105, 172.217.208.106, 172.217.208.147, 172.217.208.99
Quad9 NOERROR 14.3 ms ttl=165 192.178.183.103, 192.178.183.104, 192.178.183.105, 192.178.183.106, 192.178.183.147, 192.178.183.99
amazonaws.com -> identical
Google NOERROR 10.6 ms ttl=802 15.197.250.250, 166.117.149.112 (2nd query TTL 246: served from cache)
Cloudflare NOERROR 9.8 ms ttl=747 15.197.250.250, 166.117.149.112 (2nd query TTL 709: served from cache)
Quad9 NOERROR 13.9 ms ttl=171 15.197.250.250, 166.117.149.112 (2nd query TTL 169: served from cache)
youtube.com -> disjoint
Google NOERROR 20.6 ms ttl=300 172.217.208.136, 172.217.208.190, 172.217.208.91, 172.217.208.93 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 8.9 ms ttl=111 192.178.170.136, 192.178.170.190, 192.178.170.91, 192.178.170.93
Quad9 NOERROR 15.0 ms ttl=154 142.251.13.136, 142.251.13.190, 142.251.13.91, 142.251.13.93 (2nd query TTL 154: unchanged)
apple.com -> identical
Google NOERROR 10.9 ms ttl=760 17.253.144.10 (2nd query TTL 760: unchanged)
Cloudflare NOERROR 8.7 ms ttl=617 17.253.144.10
Quad9 NOERROR 14.7 ms ttl=216 17.253.144.10
gtld-servers.net -> no-A-record
Google NOERROR 22.6 ms ttl=- (no A record)
Cloudflare NOERROR 59.2 ms ttl=- (no A record)
Quad9 NOERROR 20.0 ms ttl=- (no A record)
akamai.net -> no-A-record
Google NOERROR 17.0 ms ttl=- (no A record)
Cloudflare NOERROR 9.9 ms ttl=- (no A record)
Quad9 NOERROR 14.8 ms ttl=- (no A record)
instagram.com -> partial
Google NOERROR 14.0 ms ttl=60 157.240.17.174 (2nd query TTL 60: unchanged)
Cloudflare NOERROR 10.9 ms ttl=4 157.240.17.174
Quad9 NOERROR 15.4 ms ttl=33 157.240.253.174 (2nd query TTL 33: unchanged)
mail.ru -> identical
Google NOERROR 62.4 ms ttl=60 185.180.201.1, 89.221.239.1, 90.156.232.4 (2nd query TTL 53: served from cache)
Cloudflare NOERROR 10.0 ms ttl=13 185.180.201.1, 89.221.239.1, 90.156.232.4
Quad9 NOERROR 13.9 ms ttl=11 185.180.201.1, 89.221.239.1, 90.156.232.4
ezviz7.com -> no-A-record
Google NOERROR 340.7 ms ttl=- (no A record)
Cloudflare NOERROR 11.6 ms ttl=- (no A record)
Quad9 NOERROR 243.7 ms ttl=- (no A record)
fbcdn.net -> partial
Google NOERROR 14.0 ms ttl=60 157.240.17.35 (2nd query TTL 60: unchanged)
Cloudflare NOERROR 9.9 ms ttl=42 157.240.17.35 (2nd query TTL 42: unchanged)
Quad9 NOERROR 14.7 ms ttl=32 157.240.0.35 (2nd query TTL 30: served from cache)
twitter.com -> partial
Google NOERROR 11.6 ms ttl=249 172.66.0.227 (2nd query TTL 120: served from cache)
Cloudflare NOERROR 9.6 ms ttl=263 162.159.140.229 (2nd query TTL 203: served from cache)
Quad9 NOERROR 13.9 ms ttl=236 162.159.140.229
dzen.ru -> identical
Google NOERROR 9.7 ms ttl=450 95.163.218.220
Cloudflare NOERROR 9.1 ms ttl=29 95.163.218.220 (2nd query TTL 29: unchanged)
Quad9 NOERROR 16.1 ms ttl=308 95.163.218.220 (2nd query TTL 24: served from cache)
linkedin.com -> identical
Google NOERROR 14.6 ms ttl=300 130.211.32.14 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 9.4 ms ttl=237 130.211.32.14
Quad9 NOERROR 15.0 ms ttl=139 130.211.32.14
domaincontrol.com -> identical
Google NOERROR 25.7 ms ttl=600 127.0.0.1 (2nd query TTL 600: unchanged)
Cloudflare NOERROR 18.5 ms ttl=600 127.0.0.1 (2nd query TTL 600: unchanged)
Quad9 NOERROR 17.6 ms ttl=600 127.0.0.1 (2nd query TTL 600: unchanged)
googlevideo.com -> disjoint
Google NOERROR 17.7 ms ttl=300 74.125.29.103, 74.125.29.104, 74.125.29.105, 74.125.29.106, 74.125.29.147, 74.125.29.99 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 9.9 ms ttl=121 172.217.208.103, 172.217.208.104, 172.217.208.105, 172.217.208.106, 172.217.208.147, 172.217.208.99 (2nd query TTL 121: unchanged)
Quad9 NOERROR 14.8 ms ttl=152 142.251.14.103, 142.251.14.104, 142.251.14.105, 142.251.14.106, 142.251.14.147, 142.251.14.99
office.com -> identical
Google NOERROR 11.2 ms ttl=2 13.107.6.156
Cloudflare NOERROR 10.2 ms ttl=7 13.107.6.156
Quad9 NOERROR 15.5 ms ttl=6 13.107.6.156 (2nd query TTL 5: served from cache)
googletagmanager.com -> disjoint
Google NOERROR 24.7 ms ttl=300 172.217.208.97 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 10.7 ms ttl=271 74.125.29.97 (2nd query TTL 271: unchanged)
Quad9 NOERROR 15.5 ms ttl=23 192.178.183.97
hicloudcam.com -> no-A-record
Google NOERROR 319.1 ms ttl=- (no A record)
Cloudflare NOERROR 520.8 ms ttl=- (no A record)
Quad9 NOERROR 240.3 ms ttl=- (no A record)
live.com -> identical
Google NOERROR 13.1 ms ttl=104 204.79.197.212
Cloudflare NOERROR 9.8 ms ttl=2662 204.79.197.212 (2nd query TTL 2662: unchanged)
Quad9 NOERROR 14.9 ms ttl=2914 204.79.197.212 (2nd query TTL 2914: unchanged)
akamaiedge.net -> no-A-record
Google NOERROR 10.0 ms ttl=- (no A record)
Cloudflare NOERROR 10.5 ms ttl=- (no A record)
Quad9 NOERROR 15.1 ms ttl=- (no A record)
amazon.com -> identical
Google NOERROR 10.7 ms ttl=158 98.82.161.185, 98.87.170.71, 98.87.170.74
Cloudflare NOERROR 9.7 ms ttl=504 98.82.161.185, 98.87.170.71, 98.87.170.74 (2nd query TTL 492: served from cache)
Quad9 NOERROR 16.1 ms ttl=759 98.82.161.185, 98.87.170.71, 98.87.170.74 (2nd query TTL 506: served from cache)
akadns.net -> no-A-record
Google NOERROR 20.1 ms ttl=- (no A record)
Cloudflare NOERROR 10.9 ms ttl=- (no A record)
Quad9 NOERROR 15.9 ms ttl=- (no A record)
azure.com -> identical
Google NOERROR 9.7 ms ttl=1261 20.112.250.133, 20.231.239.246, 20.236.44.162, 20.70.246.20, 20.76.201.171
Cloudflare NOERROR 9.2 ms ttl=2975 20.112.250.133, 20.231.239.246, 20.236.44.162, 20.70.246.20, 20.76.201.171 (2nd query TTL 2955: served from cache)
Quad9 NOERROR 13.8 ms ttl=2722 20.112.250.133, 20.231.239.246, 20.236.44.162, 20.70.246.20, 20.76.201.171 (2nd query TTL 2722: unchanged)
bing.com -> identical
Google NOERROR 10.1 ms ttl=3542 150.171.27.10, 150.171.28.10 (2nd query TTL 691: served from cache)
Cloudflare NOERROR 10.7 ms ttl=2911 150.171.27.10, 150.171.28.10 (2nd query TTL 2719: served from cache)
Quad9 NOERROR 14.7 ms ttl=533 150.171.27.10, 150.171.28.10
github.com -> partial
Google NOERROR 18.2 ms ttl=60 140.82.121.3 (2nd query TTL 60: unchanged)
Cloudflare NOERROR 9.7 ms ttl=1 140.82.121.4
Quad9 NOERROR 14.0 ms ttl=51 140.82.121.4 (2nd query TTL 23: served from cache)
wikipedia.org -> partial
Google NOERROR 11.3 ms ttl=167 185.15.58.224
Cloudflare NOERROR 10.6 ms ttl=57 185.15.58.224
Quad9 NOERROR 17.1 ms ttl=63 185.15.59.224 (2nd query TTL 49: served from cache)
whatsapp.net -> partial
Google NOERROR 14.3 ms ttl=60 157.240.17.60 (2nd query TTL 60: unchanged)
Cloudflare NOERROR 10.7 ms ttl=40 157.240.17.60 (2nd query TTL 40: unchanged)
Quad9 NOERROR 15.0 ms ttl=27 157.240.0.60 (2nd query TTL 27: unchanged)
apple-dns.net -> no-A-record
Google NOERROR 10.0 ms ttl=- (no A record)
Cloudflare NOERROR 9.6 ms ttl=- (no A record)
Quad9 NOERROR 14.5 ms ttl=- (no A record)
fastly.net -> identical
Google NOERROR 11.5 ms ttl=2039 151.101.1.6, 151.101.129.6, 151.101.193.6, 151.101.65.6 (2nd query TTL 633: served from cache)
Cloudflare NOERROR 10.6 ms ttl=3494 151.101.1.6, 151.101.129.6, 151.101.193.6, 151.101.65.6 (2nd query TTL 1394: served from cache)
Quad9 NOERROR 16.2 ms ttl=1732 151.101.1.6, 151.101.129.6, 151.101.193.6, 151.101.65.6
googleusercontent.com -> disjoint
Google NOERROR 38.9 ms ttl=300 192.178.170.132 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 11.2 ms ttl=108 74.125.29.132
Quad9 NOERROR 14.9 ms ttl=300 142.251.20.132 (2nd query TTL 178: served from cache)
appsflyersdk.com -> disjoint
Google NOERROR 17.5 ms ttl=60 3.165.190.101, 3.165.190.35, 3.165.190.39, 3.165.190.48 (2nd query TTL 60: unchanged)
Cloudflare NOERROR 11.4 ms ttl=60 108.139.243.111, 108.139.243.112, 108.139.243.114, 108.139.243.9 (2nd query TTL 60: unchanged)
Quad9 NOERROR 18.5 ms ttl=60 13.226.244.111, 13.226.244.60, 13.226.244.76, 13.226.244.9 (2nd query TTL 60: unchanged)
doubleclick.net -> partial
Google NOERROR 16.2 ms ttl=300 74.125.29.100, 74.125.29.101, 74.125.29.102, 74.125.29.113, 74.125.29.138, 74.125.29.139 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 9.2 ms ttl=268 74.125.29.100, 74.125.29.101, 74.125.29.102, 74.125.29.113, 74.125.29.138, 74.125.29.139 (2nd query TTL 268: unchanged)
Quad9 NOERROR 14.1 ms ttl=90 192.178.183.100, 192.178.183.101, 192.178.183.102, 192.178.183.113, 192.178.183.138, 192.178.183.139 (2nd query TTL 90: unchanged)
aaplimg.com -> no-A-record
Google NOERROR 13.4 ms ttl=- (no A record)
Cloudflare NOERROR 10.0 ms ttl=- (no A record)
Quad9 NOERROR 15.2 ms ttl=- (no A record)
microsoftonline.com -> no-A-record
Google NOERROR 12.3 ms ttl=- (no A record)
Cloudflare NOERROR 9.9 ms ttl=- (no A record)
Quad9 NOERROR 14.9 ms ttl=- (no A record)
netflix.com -> partial
Google NOERROR 16.1 ms ttl=60 52.214.181.141, 54.170.196.176, 54.246.79.9 (2nd query TTL 60: unchanged)
Cloudflare NOERROR 11.7 ms ttl=58 18.200.8.190, 54.155.246.232, 54.73.148.110 (2nd query TTL 8: served from cache)
Quad9 NOERROR 15.0 ms ttl=44 18.200.8.190, 54.155.246.232, 54.73.148.110 (2nd query TTL 37: served from cache)
office.net -> no-A-record
Google NOERROR 11.2 ms ttl=- (no A record)
Cloudflare NOERROR 10.8 ms ttl=- (no A record)
Quad9 NOERROR 15.2 ms ttl=- (no A record)
trafficmanager.net -> no-A-record
Google NOERROR 12.7 ms ttl=- (no A record)
Cloudflare NOERROR 10.1 ms ttl=- (no A record)
Quad9 NOERROR 14.4 ms ttl=- (no A record)
gandi.net -> identical
Google NOERROR 36.2 ms ttl=600 217.70.185.65 (2nd query TTL 600: unchanged)
Cloudflare NOERROR 23.5 ms ttl=600 217.70.185.65 (2nd query TTL 600: unchanged)
Quad9 NOERROR 40.3 ms ttl=600 217.70.185.65 (2nd query TTL 217: served from cache)
sharepoint.com -> identical
Google NOERROR 10.0 ms ttl=1250 13.107.136.10, 13.107.138.10 (2nd query TTL 1087: served from cache)
Cloudflare NOERROR 10.4 ms ttl=2067 13.107.136.10, 13.107.138.10 (2nd query TTL 2067: unchanged)
Quad9 NOERROR 15.1 ms ttl=2089 13.107.136.10, 13.107.138.10 (2nd query TTL 2020: served from cache)
digicert.com -> identical
Google NOERROR 12.3 ms ttl=233 45.60.121.229, 45.60.131.229 (2nd query TTL 110: served from cache)
Cloudflare NOERROR 8.8 ms ttl=36 45.60.121.229, 45.60.131.229 (2nd query TTL 36: unchanged)
Quad9 NOERROR 14.3 ms ttl=38 45.60.121.229, 45.60.131.229
youtu.be -> partial
Google NOERROR 24.7 ms ttl=300 74.125.29.136, 74.125.29.190, 74.125.29.91, 74.125.29.93 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 10.4 ms ttl=66 74.125.29.136, 74.125.29.190, 74.125.29.91, 74.125.29.93 (2nd query TTL 47: served from cache)
Quad9 NOERROR 14.8 ms ttl=98 142.250.154.136, 142.250.154.190, 142.250.154.91, 142.250.154.93
wordpress.org -> identical
Google NOERROR 10.8 ms ttl=73 66.6.42.252 (2nd query TTL 73: unchanged)
Cloudflare NOERROR 9.5 ms ttl=328 66.6.42.252 (2nd query TTL 134: served from cache)
Quad9 NOERROR 15.1 ms ttl=52 66.6.42.252
skype.com -> identical
Google NOERROR 10.3 ms ttl=183 20.112.250.133, 20.231.239.246, 20.236.44.162, 20.70.246.20, 20.76.201.171
Cloudflare NOERROR 9.5 ms ttl=26 20.112.250.133, 20.231.239.246, 20.236.44.162, 20.70.246.20, 20.76.201.171
Quad9 NOERROR 14.1 ms ttl=1825 20.112.250.133, 20.231.239.246, 20.236.44.162, 20.70.246.20, 20.76.201.171
cloud.microsoft -> identical
Google NOERROR 9.1 ms ttl=97 20.112.250.133, 20.231.239.246, 20.236.44.162, 20.70.246.20, 20.76.201.171 (2nd query TTL 97: unchanged)
Cloudflare NOERROR 10.0 ms ttl=155 20.112.250.133, 20.231.239.246, 20.236.44.162, 20.70.246.20, 20.76.201.171
Quad9 NOERROR 13.3 ms ttl=157 20.112.250.133, 20.231.239.246, 20.236.44.162, 20.70.246.20, 20.76.201.171
goo.gl -> disjoint
Google NOERROR 25.2 ms ttl=300 74.125.29.100, 74.125.29.101, 74.125.29.102, 74.125.29.113, 74.125.29.138, 74.125.29.139 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 8.8 ms ttl=280 172.217.208.100, 172.217.208.101, 172.217.208.102, 172.217.208.113, 172.217.208.138, 172.217.208.139 (2nd query TTL 280: unchanged)
Quad9 NOERROR 15.5 ms ttl=29 142.251.13.100, 142.251.13.101, 142.251.13.102, 142.251.13.113, 142.251.13.138, 142.251.13.139 (2nd query TTL 29: unchanged)
cloudfront.net -> no-A-record
Google NOERROR 12.4 ms ttl=- (no A record)
Cloudflare NOERROR 11.5 ms ttl=- (no A record)
Quad9 NOERROR 17.0 ms ttl=- (no A record)
googledomains.com -> identical
Google NOERROR 32.6 ms ttl=300 216.239.32.29 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 23.8 ms ttl=300 216.239.32.29 (2nd query TTL 60: served from cache)
Quad9 NOERROR 26.7 ms ttl=300 216.239.32.29 (2nd query TTL 300: unchanged)
x.com -> partial
Google NOERROR 9.7 ms ttl=75 172.66.0.227 (2nd query TTL 74: served from cache)
Cloudflare NOERROR 9.4 ms ttl=104 162.159.140.229 (2nd query TTL 103: served from cache)
Quad9 NOERROR 15.1 ms ttl=143 162.159.140.229 (2nd query TTL 89: served from cache)
tiktok.com -> disjoint
Google NOERROR 23.7 ms ttl=20 2.21.22.17, 2.21.22.56 (2nd query TTL 20: unchanged)
Cloudflare NOERROR 10.3 ms ttl=13 104.109.250.146, 104.109.250.172 (2nd query TTL 13: unchanged)
Quad9 NOERROR 14.5 ms ttl=1 23.36.162.199, 23.36.162.207, 23.36.162.209, 23.36.162.213, 23.36.162.214, 23.36.162.215, 23.36.162.219, 23.36.162.221 (2nd query TTL 1: unchanged)
pinterest.com -> identical
Google NOERROR 12.0 ms ttl=316 151.101.0.84, 151.101.128.84, 151.101.192.84, 151.101.64.84 (2nd query TTL 316: unchanged)
Cloudflare NOERROR 10.0 ms ttl=308 151.101.0.84, 151.101.128.84, 151.101.192.84, 151.101.64.84
Quad9 NOERROR 14.2 ms ttl=169 151.101.0.84, 151.101.128.84, 151.101.192.84, 151.101.64.84
icloud.com -> identical
Google NOERROR 9.6 ms ttl=45 17.253.144.10
Cloudflare NOERROR 9.5 ms ttl=493 17.253.144.10 (2nd query TTL 415: served from cache)
Quad9 NOERROR 14.4 ms ttl=278 17.253.144.10 (2nd query TTL 94: served from cache)
whatsapp.com -> partial
Google NOERROR 11.9 ms ttl=36 157.240.17.60
Cloudflare NOERROR 10.9 ms ttl=16 157.240.17.60
Quad9 NOERROR 17.0 ms ttl=21 157.240.0.60 (2nd query TTL 4: served from cache)
roblox.com -> identical
Google NOERROR 20.6 ms ttl=31 128.116.5.3 (2nd query TTL 20: served from cache)
Cloudflare NOERROR 11.7 ms ttl=20 128.116.5.3
Quad9 NOERROR 15.2 ms ttl=45 128.116.5.3 (2nd query TTL 41: served from cache)
yahoo.com -> identical
Google NOERROR 10.0 ms ttl=400 74.6.143.25, 74.6.143.26, 74.6.231.20, 74.6.231.21, 98.137.11.163, 98.137.11.164 (2nd query TTL 105: served from cache)
Cloudflare NOERROR 9.2 ms ttl=587 74.6.143.25, 74.6.143.26, 74.6.231.20, 74.6.231.21, 98.137.11.163, 98.137.11.164 (2nd query TTL 587: unchanged)
Quad9 NOERROR 16.4 ms ttl=724 74.6.143.25, 74.6.143.26, 74.6.231.20, 74.6.231.21, 98.137.11.163, 98.137.11.164 (2nd query TTL 200: served from cache)
windowsupdate.com -> no-A-record
Google NOERROR 11.5 ms ttl=- (no A record)
Cloudflare NOERROR 11.0 ms ttl=- (no A record)
Quad9 NOERROR 14.7 ms ttl=- (no A record)
cloudflare.net -> identical
Google NOERROR 16.7 ms ttl=300 104.16.208.90, 104.17.156.85 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 11.6 ms ttl=91 104.16.208.90, 104.17.156.85
Quad9 NOERROR 15.2 ms ttl=38 104.16.208.90, 104.17.156.85
gvt1.com -> no-A-record
Google NOERROR 42.9 ms ttl=- (no A record)
Cloudflare NOERROR 11.0 ms ttl=- (no A record)
Quad9 NOERROR 15.6 ms ttl=- (no A record)
googlesyndication.com -> partial
Google NOERROR 25.6 ms ttl=300 172.217.208.103, 172.217.208.104, 172.217.208.105, 172.217.208.106, 172.217.208.147, 172.217.208.99 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 19.4 ms ttl=300 172.217.208.103, 172.217.208.104, 172.217.208.105, 172.217.208.106, 172.217.208.147, 172.217.208.99 (2nd query TTL 300: unchanged)
Quad9 NOERROR 25.5 ms ttl=300 142.251.110.103, 142.251.110.104, 142.251.110.105, 142.251.110.106, 142.251.110.147, 142.251.110.99 (2nd query TTL 300: unchanged)
msn.com -> identical
Google NOERROR 12.2 ms ttl=1507 204.79.197.219 (2nd query TTL 523: served from cache)
Cloudflare NOERROR 11.5 ms ttl=2504 204.79.197.219 (2nd query TTL 687: served from cache)
Quad9 NOERROR 15.9 ms ttl=717 204.79.197.219 (2nd query TTL 717: unchanged)
spotify.com -> identical
Google NOERROR 10.3 ms ttl=131 35.186.224.24 (2nd query TTL 130: served from cache)
Cloudflare NOERROR 9.8 ms ttl=87 35.186.224.24
Quad9 NOERROR 15.2 ms ttl=171 35.186.224.24 (2nd query TTL 162: served from cache)
windows.net -> identical
Google NOERROR 12.0 ms ttl=48 20.112.250.133, 20.231.239.246, 20.236.44.162, 20.70.246.20, 20.76.201.171 (2nd query TTL 48: unchanged)
Cloudflare NOERROR 9.0 ms ttl=2033 20.112.250.133, 20.231.239.246, 20.236.44.162, 20.70.246.20, 20.76.201.171 (2nd query TTL 2033: unchanged)
Quad9 NOERROR 15.3 ms ttl=632 20.112.250.133, 20.231.239.246, 20.236.44.162, 20.70.246.20, 20.76.201.171 (2nd query TTL 632: unchanged)
ntp.org -> identical
Google NOERROR 10.0 ms ttl=1158 204.93.207.22, 209.148.110.246
Cloudflare NOERROR 11.1 ms ttl=3461 204.93.207.22, 209.148.110.246 (2nd query TTL 3461: unchanged)
Quad9 NOERROR 15.4 ms ttl=2375 204.93.207.22, 209.148.110.246
adobe.com -> disjoint
Google NOERROR 17.3 ms ttl=20 92.123.27.153, 92.123.27.168, 92.123.27.169 (2nd query TTL 20: unchanged)
Cloudflare NOERROR 11.5 ms ttl=3 23.36.163.27, 23.50.131.121 (2nd query TTL 2: served from cache)
Quad9 NOERROR 15.6 ms ttl=11 2.19.126.138, 2.19.126.158 (2nd query TTL 6: served from cache)
myfritz.net -> identical
Google NOERROR 10.8 ms ttl=5152 212.42.244.100
Cloudflare NOERROR 26.1 ms ttl=86400 212.42.244.100 (2nd query TTL 86400: unchanged)
Quad9 NOERROR 15.2 ms ttl=40413 212.42.244.100 (2nd query TTL 31027: served from cache)
pv-cdn.net -> no-A-record
Google NOERROR 12.4 ms ttl=- (no A record)
Cloudflare NOERROR 10.7 ms ttl=- (no A record)
Quad9 NOERROR 14.1 ms ttl=- (no A record)
wa.me -> partial
Google NOERROR 20.9 ms ttl=60 157.240.17.60 (2nd query TTL 60: unchanged)
Cloudflare NOERROR 9.8 ms ttl=49 157.240.17.60 (2nd query TTL 49: unchanged)
Quad9 NOERROR 14.1 ms ttl=21 157.240.0.60
cdninstagram.com -> no-A-record
Google NOERROR 13.2 ms ttl=- (no A record)
Cloudflare NOERROR 10.5 ms ttl=- (no A record)
Quad9 NOERROR 13.6 ms ttl=- (no A record)
nginx.org -> partial
Google NOERROR 10.0 ms ttl=9 3.125.197.172 (2nd query TTL 9: unchanged)
Cloudflare NOERROR 9.6 ms ttl=19 52.58.199.22
Quad9 NOERROR 16.5 ms ttl=18 3.125.197.172
akam.net -> no-A-record
Google NOERROR 47.6 ms ttl=- (no A record)
Cloudflare NOERROR 10.7 ms ttl=- (no A record)
Quad9 NOERROR 17.0 ms ttl=- (no A record)
tiktokcdn.com -> no-A-record
Google NOERROR 9.7 ms ttl=- (no A record)
Cloudflare NOERROR 9.2 ms ttl=- (no A record)
Quad9 NOERROR 14.0 ms ttl=- (no A record)
chatgpt.com -> identical
Google NOERROR 28.5 ms ttl=300 104.18.32.47, 172.64.155.209 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 9.3 ms ttl=254 104.18.32.47, 172.64.155.209 (2nd query TTL 253: served from cache)
Quad9 NOERROR 14.6 ms ttl=135 104.18.32.47, 172.64.155.209 (2nd query TTL 135: unchanged)
zoom.us -> identical
Google NOERROR 13.1 ms ttl=60 170.114.52.2 (2nd query TTL 60: unchanged)
Cloudflare NOERROR 10.3 ms ttl=20 170.114.52.2
Quad9 NOERROR 14.7 ms ttl=22 170.114.52.2
tiktokv.com -> disjoint
Google NOERROR 10.4 ms ttl=8 104.126.37.128, 104.126.37.129, 104.126.37.131, 104.126.37.153, 104.126.37.155, 104.126.37.161, 104.126.37.179, 104.126.37.184, 104.126.37.186 (2nd query TTL 7: served from cache)
Cloudflare NOERROR 9.4 ms ttl=8 2.21.22.27, 2.21.22.34, 2.21.22.40, 2.21.22.41, 2.21.22.56, 2.21.22.58, 2.21.22.8, 23.10.249.81, 23.10.249.82 (2nd query TTL 3: served from cache)
Quad9 NOERROR 15.5 ms ttl=12 2.20.142.129, 2.20.142.136, 2.20.142.144, 2.20.142.160, 92.122.215.2, 92.122.215.59, 92.122.215.72, 92.122.215.73, 92.122.215.93 (2nd query TTL 11: served from cache)
vimeo.com -> identical
Google NOERROR 11.5 ms ttl=397 162.159.128.61, 162.159.138.60 (2nd query TTL 397: unchanged)
Cloudflare NOERROR 10.5 ms ttl=799 162.159.128.61, 162.159.138.60 (2nd query TTL 799: unchanged)
Quad9 NOERROR 15.5 ms ttl=523 162.159.128.61, 162.159.138.60 (2nd query TTL 153: served from cache)
edgekey.net -> no-A-record
Google NOERROR 11.3 ms ttl=- (no A record)
Cloudflare NOERROR 10.5 ms ttl=- (no A record)
Quad9 NOERROR 15.3 ms ttl=- (no A record)
baidu.com -> identical
Google NOERROR 10.5 ms ttl=502 110.242.74.102, 111.63.65.103, 111.63.65.247, 124.237.177.164 (2nd query TTL 502: unchanged)
Cloudflare NOERROR 10.7 ms ttl=264 110.242.74.102, 111.63.65.103, 111.63.65.247, 124.237.177.164
Quad9 NOERROR 15.4 ms ttl=268 110.242.74.102, 111.63.65.103, 111.63.65.247, 124.237.177.164 (2nd query TTL 268: unchanged)
cloudflare-dns.com -> identical
Google NOERROR 17.8 ms ttl=300 104.16.248.249, 104.16.249.249 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 9.5 ms ttl=84 104.16.248.249, 104.16.249.249
Quad9 NOERROR 14.7 ms ttl=51 104.16.248.249, 104.16.249.249
gvt2.com -> no-A-record
Google NOERROR 18.7 ms ttl=- (no A record)
Cloudflare NOERROR 17.9 ms ttl=- (no A record)
Quad9 NOERROR 15.7 ms ttl=- (no A record)
yandex.net -> identical
Google NOERROR 11.8 ms ttl=54 213.180.204.242 (2nd query TTL 54: unchanged)
Cloudflare NOERROR 10.2 ms ttl=547 213.180.204.242 (2nd query TTL 547: unchanged)
Quad9 NOERROR 15.1 ms ttl=6 213.180.204.242 (2nd query TTL 6: unchanged)
windows.com -> identical
Google NOERROR 10.3 ms ttl=2705 20.112.250.133, 20.231.239.246, 20.236.44.162, 20.70.246.20, 20.76.201.171 (2nd query TTL 623: served from cache)
Cloudflare NOERROR 10.1 ms ttl=2600 20.112.250.133, 20.231.239.246, 20.236.44.162, 20.70.246.20, 20.76.201.171 (2nd query TTL 2420: served from cache)
Quad9 NOERROR 15.2 ms ttl=2531 20.112.250.133, 20.231.239.246, 20.236.44.162, 20.70.246.20, 20.76.201.171 (2nd query TTL 107: served from cache)
root-servers.net -> no-A-record
Google NOERROR 18.6 ms ttl=- (no A record)
Cloudflare NOERROR 10.1 ms ttl=- (no A record)
Quad9 NOERROR 15.6 ms ttl=- (no A record)
openai.com -> identical
Google NOERROR 10.1 ms ttl=1 104.18.33.45, 172.64.154.211 (2nd query TTL 1: unchanged)
Cloudflare NOERROR 8.3 ms ttl=60 104.18.33.45, 172.64.154.211 (2nd query TTL 26: served from cache)
Quad9 NOERROR 14.6 ms ttl=5 104.18.33.45, 172.64.154.211 (2nd query TTL 5: unchanged)
gwfb.net -> no-A-record
Google NOERROR 402.9 ms ttl=- (no A record)
Cloudflare NOERROR 762.9 ms ttl=- (no A record)
Quad9 NOERROR 261.2 ms ttl=- (no A record)
ytimg.com -> no-A-record
Google NOERROR 29.8 ms ttl=- (no A record)
Cloudflare NOERROR 9.8 ms ttl=- (no A record)
Quad9 NOERROR 14.2 ms ttl=- (no A record)
workers.dev -> identical
Google NOERROR 13.6 ms ttl=300 104.18.12.15, 104.18.13.15 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 13.0 ms ttl=300 104.18.12.15, 104.18.13.15 (2nd query TTL 257: served from cache)
Quad9 NOERROR 18.7 ms ttl=300 104.18.12.15, 104.18.13.15 (2nd query TTL 160: served from cache)
qq.com -> identical
Google NOERROR 229.8 ms ttl=600 113.108.81.189, 123.150.76.218, 203.205.254.157 (2nd query TTL 597: served from cache)
Cloudflare NOERROR 9.6 ms ttl=299 113.108.81.189, 123.150.76.218, 203.205.254.157 (2nd query TTL 299: unchanged)
Quad9 NOERROR 15.9 ms ttl=199 113.108.81.189, 123.150.76.218, 203.205.254.157 (2nd query TTL 147: served from cache)
opera.com -> identical
Google NOERROR 22.3 ms ttl=600 185.26.182.103, 185.26.182.104 (2nd query TTL 600: unchanged)
Cloudflare NOERROR 22.1 ms ttl=600 185.26.182.103, 185.26.182.104 (2nd query TTL 600: unchanged)
Quad9 NOERROR 14.0 ms ttl=9 185.26.182.103, 185.26.182.104
samsung.com -> identical
Google NOERROR 9.5 ms ttl=155 211.45.27.231
Cloudflare NOERROR 9.2 ms ttl=176 211.45.27.231
Quad9 NOERROR 13.7 ms ttl=125 211.45.27.231
blogspot.com -> partial
Google NOERROR 24.6 ms ttl=300 74.125.29.191 (2nd query TTL 300: unchanged)
Cloudflare NOERROR 16.5 ms ttl=300 74.125.29.191 (2nd query TTL 300: unchanged)
Quad9 NOERROR 14.8 ms ttl=28 142.251.20.191
mozilla.org -> identical
Google NOERROR 10.2 ms ttl=57 35.190.14.201 (2nd query TTL 57: unchanged)
Cloudflare NOERROR 9.3 ms ttl=318 35.190.14.201 (2nd query TTL 17: served from cache)
Quad9 NOERROR 14.4 ms ttl=582 35.190.14.201 (2nd query TTL 582: unchanged)
nginx.com -> identical
Google NOERROR 11.9 ms ttl=123 159.60.134.0 (2nd query TTL 123: unchanged)
Cloudflare NOERROR 10.4 ms ttl=299 159.60.134.0
Quad9 NOERROR 16.0 ms ttl=101 159.60.134.0
wordpress.com -> identical
Google NOERROR 9.8 ms ttl=95 192.0.78.17, 192.0.78.9
Cloudflare NOERROR 10.6 ms ttl=51 192.0.78.17, 192.0.78.9
Quad9 NOERROR 16.4 ms ttl=209 192.0.78.17, 192.0.78.9 (2nd query TTL 12: served from cache)
edgesuite.net -> no-A-record
Google NOERROR 13.0 ms ttl=- (no A record)
Cloudflare NOERROR 10.5 ms ttl=- (no A record)
Quad9 NOERROR 15.1 ms ttl=- (no A record)
workbox.dk -> no-A-record
Google NOERROR 11.9 ms ttl=- (no A record)
Cloudflare NOERROR 133.7 ms ttl=- (no A record)
Quad9 NOERROR 23.0 ms ttl=- (no A record)
yandex.ru -> identical
Google NOERROR 11.5 ms ttl=360 5.255.255.77, 77.88.44.55, 77.88.55.88 (2nd query TTL 360: unchanged)
Cloudflare NOERROR 10.9 ms ttl=521 5.255.255.77, 77.88.44.55, 77.88.55.88 (2nd query TTL 285: served from cache)
Quad9 NOERROR 15.2 ms ttl=227 5.255.255.77, 77.88.44.55, 77.88.55.88 (2nd query TTL 95: served from cache)
summary A: all 100 names
identical 46 46.0%
partial 19 19.0%
disjoint 10 10.0%
no-A-record 25 25.0%
summary B: the 75 names where at least two resolvers returned an address
identical 46 61.3%
partial 19 25.3%
disjoint 10 13.3%
NOT identical 29 38.7% <- the headline: at least one resolver disagreed with another
Summary B is the denominator to quote. Summary A mixes two different
findings: how often resolvers disagree, and how often a name in your
list has no address to disagree about.
'disjoint' means NO PAIR of resolvers returned an address in common, and
no pair even shared a /24. 'partial' means some pair overlapped and some
pair did not. The number to quote for "how much does my choice of
resolver matter" is NOT identical: that is the share of your name list
where resolvers did not all agree -- from this vantage point, at this
instant. 'disjoint' alone understates it; quoting 'disjoint' as though
it meant "any disagreement" overstates it.
wrote out/dns/resolver_run.json
The 25 names with no A record at the apex:
25 names gtld-servers.net, akamai.net, ezviz7.com, hicloudcam.com, akamaiedge.net akadns.net, apple-dns.net, aaplimg.com, microsoftonline.com, office.net trafficmanager.net, cloudfront.net, windowsupdate.com, gvt1.com, pv-cdn.net cdninstagram.com, akam.net, tiktokcdn.com, edgekey.net, gvt2.com root-servers.net, gwfb.net, ytimg.com, edgesuite.net, workbox.dk
The names with fully disjoint answers, in the run below:
10 names googleapis.com, youtube.com, googlevideo.com, googletagmanager.com googleusercontent.com, appsflyersdk.com, goo.gl, tiktok.com, adobe.com tiktokv.com
Probes run and rejected
| Probe | Result | Why it is not on the page |
|---|---|---|
| /\bDDR\b/ for Discovery of Designated Resolvers | 30 papers, including 2 in 2010–2013 — four years before the draft existed | DDR is Double Data Rate memory. Replaced with a proximity probe requiring resolver or DNS within 60 characters, which gives 1 paper. That one paper is the PoPETs 2025 DDR study, and 1 is the number on the page. |
| /\bECS\b/ for EDNS Client Subnet | 33 papers | ECS is also Amazon Elastic Container Service. Same proximity fix; 20 corpus-wide, 16 in DNSPOP. |
| “own recursive resolver” phrasings | 1 paper | Far too narrow to support any claim. Dropped entirely; the resolver-software fold family (62 papers) is used instead, and the page makes no claim about how many papers ran their own recursive server. |
| /\bdot\b/ as a DoT alternative | Matched Droidot, Godot, OleViewDot-Net and every “dot” in prose | Never used. The DoT row uses the spelled-out phrase only, which is why its counts are conservative. |
| A “which resolver did the paper use” schema query | No such field exists | The schema has no place for it, and a full-text probe for resolver IP literals (69 papers naming 8.8.8.8 or similar) is an upper bound on mentions, not on use. No reporting-rate claim is made about resolver identification. This is the single biggest thing the corpus cannot answer for this page. |
Judgement calls
design:dnsrather thansecurity:dnsor a child ofsecurity:tls_certificates. The task nameddesign:dns, and the reasoning holds: this is an instrument-selection question, a sibling of ip_classification (“what is this address”) and automated_measurements (“which instrument”), not a deployment-security question. The TLS page answers “what does this host present after you connect”; nothing on it covers resolution, and stretching it would have been the wrong page. A reasonable person could have put it undersecurity:.- No child pages.
design:dns:encrypted_dns(48 DoH papers in DNSPOP) anddesign:dns:passive_dns(65) are each large enough to survive as a page, and both were declined. Encrypted DNS is a five-row table because the interesting content is the dating, which only works when the protocols sit beside each other; passive DNS is a four-row table because the interesting content is which vendor still exists. Splitting either would produce two pages that each need the other's context. Revisit when DoQ or DDR has more than one or two papers. prevalencefigures are quoted only after being re-found in the paper. Four of the figures first drafted fromdetection[].prevalencedid not survive; see the table above. Every remaining per-paper figure on the page has a needle inverify_dns_figures.mjs.- The seven lab-rig papers stay in the population. They used a DNS-specific instrument, which is what the rule says. Removing them would make the rule a judgement. Publishing the count is the compromise.
- Posters (14 of 244) are not excluded. The page's headline claims are not reporting-gap rates where poster brevity would bias the result upward; the vantage-location and version figures are, so the poster count is stated next to the population.
- Two rhetorical sentences were re-derived and one was wrong. The draft said “IMC is where this work lives, by a factor of three over the next venue” (true: 13.2% vs 4.3%) and “if you read only the web-measurement venues you are reading the wrong 60%” (unsupported). Measuring it: TheWebConf and PoPETs together are 12.3% of the 244 and IMC, USENIX Security and NDSS together are 70.1%. The sentence now states those two figures, which
report_dns.mjssection B derives so they are not hand arithmetic beside a table. - The 2010 Ager result leads failure mode 1 even though it is sixteen years old. It is the cleanest statement of a property that has not changed, and the script's own run is the current evidence beside it. The page says both.
security:tls_certificateswas not edited. automated_measurements routes “DNS” to that page and to ip_classification; both routings are now wrong. The parent's routing table was corrected to point here. The TLS page itself says nothing about DNS and needed no change.
Wiki wiring
| Page | Change |
|---|---|
| dns | created |
| dns | created (this page) |
| bibliography | 23 entries appended before </bibtex>, from a fresh ?do=export_raw. Zero key collisions, zero DOI collisions, zero URL collisions, zero title collisions against the 632 live entries. Cache purged afterwards; the page renders 29 references against 29 distinct citekeys with no unresolved warnings. |
| design | DNS row added to the namespace table and the page count corrected |
| automated_measurements | the scan row of the routing table now points at dns for DNS rather than at the TLS and IP pages |
Review log
Five review passes plus three rounds of self-review. Each reviewer was told explicitly that the author's context may not be exhaustive, and each was handed the page text, the report script and its unedited output, the fold, the quote checker and the external checks.
Snapshots. The three focused passes all read the same frozen snapshot,
out/dns/review/frozen_design_dns.txt (48,440 bytes, the page as published at
revision 1787870384) and out/dns/review/frozen_provenance.txt. Two rounds of
self-review corrections were applied to the live page while they were
running (revisions 1787870940 and 1787871092), so a reviewer reporting one of
those is reporting something already fixed — the table below says which.
Self-review, before the reviewers reported
Found by re-deriving the page's own framing sentences rather than its tables, which is where the site's history says unmeasured claims hide.
| Found | Verdict |
|---|---|
| “if you read only the web-measurement venues you are reading the wrong 60%” — unsupported, invented while writing | Fixed. Measured: TheWebConf and PoPETs together are 12.3% of the 244; IMC, USENIX Security and NDSS together are 70.1%. Both are now derived by report_dns.mjs section B rather than being hand arithmetic beside a table. |
| “the amplification literature in this corpus is large and consistent” — unmeasured | Fixed. 58 of 244 match an amplification/reflection probe; 15 say so in the title. Both now printed by the report. |
| “the DNS population is somewhat more ethics-forthcoming than the corpus average” — a comparison with no comparison printed, and false on one of the four fields | Fixed. The ethics table now carries the whole-corpus column beside the DNS column, and the sentence says explicitly that reviewOutcome is lower (29.9% vs 33.8%) while the other three are higher. |
| “most papers here answer fewer than half” of the eight-item methods checklist — the schema has a field for only two of the eight | Fixed. The page now says the extraction can measure two of the eight, gives those two rates, and calls the list a standard rather than a measurement. |
| “the single most cited reason a web crawl needs a resolution step” — an unmeasured superlative | Fixed, reworded to a claim about what a request-level measurement cannot see. |
“Miek Gieben's DNS implementation” was folding into home-grown code when it is miekg/dns, the Go library | Fixed in dns_fold.mjs; home-grown 35→34 papers, DNS libraries 15→16. The page's home-grown claim was reworded from a clean “35 distinct strings for 35 papers” to “34 distinct strings, only two of them shared, and both of those generic”. |
| “Seven of those papers use the software as part of an attack rig” sat under the resolver-software ranking, but only six of the seven lab-rig papers are in that family — the seventh is a DNSSEC-tool case. A figure that is right about the hand map and wrong about the section it is printed in. | Fixed. The sentence now says six, notes that all six are dnsmasq, and points at the seventh separately. |
| “Both of those slices are provisional years” about the LLM counts 0/0/3/5/8 — the 5 is 2022–2024, which is not provisional | Fixed. Only the 8 is in the provisional window, and the page now says so and says the growth rests on the thinnest years. |
Pass 1 — citations and quotes (sonnet)
| Finding | Verdict |
|---|---|
The 73% in Nisenoff et al. is real. This run had removed it after failing to find it in paper.cols.txt (the only “73” near “heard of DNS” there is the string “Firefox 73”). The reviewer said it was in the paper. | Accepted — and it exposed a checker bug. A pypdf re-extraction has “73% of all participants reported having heard of DNS before the survey” verbatim; it is absent from .cols entirely. The figure is back on the page as a quote, and verify_dns_figures.mjs now falls back to pypdf for any needle that misses against .cols and labels the route. 31 needles, 30 .cols, 1 PDF-only. Without this the quote check was one rendering away from a false negative on every quote it examined. |
Five papers are in literature:bibliography twice under two keys — fouad2022my/fouad2022_cookie and ahmad2026_ipfp/ahmad2026_more share a DOI, bottger2025_regional/boettger2025_regional likewise, plus lerner2016internet/lerner2016_internet and bouhoula2024automated/bouhoula2024_automated | Accepted, out of scope, recorded. None is cited by this page and all predate it. Filed as the dedup-bibliography-duplicate-papers work item with the fix and with the observation that a key-string collision check passes on all five — only a DOI and normalised-title scan finds them. |
| ZDNS's two throughput figures come from the same external-resolver sentence (not mixed with the paper's separate internal-recursion figures); Iris's four figures share one sentence; Liu et al.'s two share the abstract sentence; CERTainty's three are correctly kept apart; Siby's 95% (resolver) is correctly not paired with the paper's 100% (client) | Confirmations, no change. These are exactly the numerator/denominator and mirror-image traps the pass was asked to hunt, and the reviewer checked each. |
dao2021_cname and dimova2021cname are two different CNAME-cloaking papers, correctly presented as such | Confirmation, no change. |
| All 29 citekeys resolve; no key, DOI, title or URL collision between the 23 new entries and the 632 pre-existing ones; all ~20 prose attributions and 8 table attributions match their entry's author field; 15 entries spot-checked against Crossref and the venue landing pages | Confirmations, no change. |
Declared not checked by this pass: the fold counts and the venue/year corpus tables (out of scope for a citations review), and most of the non-paper external figures beyond the four it re-fetched.
Pass 2 — figures against the script (sonnet)
| Finding | Verdict |
|---|---|
The published script's verdict() was wrong, and the page's headline number with it. It intersected all answering resolvers' address sets at once, so with three resolvers, two agreeing exactly and a third differing produced an empty three-way intersection and fell through to disjoint — contradicting the definition the script prints in its own output and the page repeats. On the committed 100-name run, 17 of the 28 names labelled disjoint had two of three resolvers returning byte-identical addresses. | Accepted; the most serious finding of the run. Reproduced independently from the committed JSON before changing anything. verdict() is now pairwise, with a partial verdict between identical and disjoint and a one-answered verdict for the case where exactly one resolver returns an address; --self-test checks ten cases including facebook.com and wikipedia.org from the run that caught it. The measurement was re-run; the page's headline is now not identical, 29 of 75 (38.7%), replacing the published 28 / 37.3%. Per-verdict counts are deliberately not restated here — they are in the run output on this page, and see pass 5 for why the split between partial and disjoint is not a stable quantity. The page now says in the open that the first version was wrong and what it got wrong. |
| “All 7 uses [of fpdns] are pre-2024” is false — 1 in 2018, 3 in 2023, 3 in 2024. | Accepted. Reproduced. The row now gives the year breakdown and says what the recent uses are for. The report prints per-year and per-spelling detail for every family the page describes in prose, so this class of sentence is checkable. |
bhaskar2022_many does not use RIPE Atlas. The page said two papers were built on it and named this one; its tools are BreadCrumb, Censys, MaxMind and Go, and its vantage record says “we send DNS packets from an external measurement vantage point”. | Accepted, reproduced from the paper's own record. Replaced with four papers that do use it ([1Randall, Audrey; Liu, Enze; Padmanabhan, Ramakrishna; Akiwate, Gautam; Voelker, Geoffrey M.; Savage, Stefan; Schulman, Aaron (2021): "Home is where the hijacking is: understanding DNS interception by residential routers", in: Proceedings of the ACM Internet Measurement Conference. (DOI)], [2Moura, Giovane C. M.; Heidemann, John S.; Schmidt, Ricardo de Oliveira; Hardaker, Wes (2019): "Cache Me If You Can: Effects of DNS Time-to-Live", in: Proceedings of the ACM Internet Measurement Conference. (DOI)], [3Al-Dalky, Rami; Rabinovich, Michael; Schomp, Kyle (2019): "A Look at the ECS Behavior of DNS Resolvers", in: Proceedings of the ACM Internet Measurement Conference. (DOI)], [4Randall, Audrey; Liu, Enze; Akiwate, Gautam; Padmanabhan, Ramakrishna; Voelker, Geoffrey M.; Savage, Stefan; Schulman, Aaron (2020): "Trufflehunter: Cache Snooping Rare Domains at Large Public DNS Resolvers", in: Proceedings of the ACM Internet Measurement Conference. (DOI)]), and the page now says explicitly that Bhaskar and Pearce do not — which is the point, since controlling their own source address is what their result depends on. |
| The DNSViz row was 3 papers, but only 2 use DNSViz; the third is a 2014 use of the Extended DNSSEC Validator Firefox extension, and the row printed DNSViz's currency for all three. | Accepted. Row is now 2, with the third named and explained. |
The 16 LLM papers / 0-0-3-5-8 figure was attributed to report_dns.mjs, which contained no such probe — the regex existed only as prose. And the regex is case-sensitive, which is load-bearing: case-insensitively it gives 19 papers and 0/0/3/7/9. | Accepted. The probe is now a section of report_dns.mjs which prints the regex, both counts, and the list of matching papers; the page says the probe is case-sensitive and gives the case-insensitive contrast. |
dnscrypt-proxy 2.1.18 / 2026-07-18 was attributed to external_checks_dns.sh, which did not check that repository. | Accepted. Added to the repository list; the figure is now reproducible from the named script. |
The dig family label said “/ host” but no paper in the corpus names host(1) — the only “host” string is one paper's own “host name matching tool”. | Accepted. Family relabelled to dig / drill / nslookup / tor-resolve in the fold and on the page, with the spelling breakdown given. |
query() called settimeout() once outside the receive loop, so the timeout restarted on every datagram: a stream of unrelated packets could keep one query alive far past --timeout. A bad property for a script whose subject is off-path packets. | Accepted. The timeout is now a total deadline recomputed per iteration. Tested against a blackholed resolver: it fails at the stated timeout. |
| Reviewer could not confirm the run is a genuine measurement against the real public resolvers, citing TTLs that rise between a query and its immediate repeat. | Rejected, with the reason recorded. A rising TTL on a repeat is ordinary anycast behaviour — the two queries reach different instances of the same public resolver, with independently warmed caches — and it is visible in the run in both directions. The answers are independently checkable and check out (example.com on Cloudflare addresses, three distinct Google ranges for gstatic.com, Akamai returning different addresses per resolver), the per-resolver RTTs are stably ordered across 100 names, and a query to a blackholed address times out rather than returning fabricated data. The caveat is nonetheless worth having on the record, and the page already frames the run as “one machine, one instant” rather than as a claim about the Internet. |
Confirmations: no drift between the committed outputs and a fresh run of all three scripts; the <file> and <code> blocks round-trip exactly; every population, venue, year, instrument-family, ethics, reporting-gap and encrypted-DNS figure traces; the poster count, robots.txt rate and fold residue check out; all 30 per-paper figures trace to their sources. | No change. |
Pass 3 — external currency (sonnet)
Every finding below was re-verified independently before being acted on, because a currency claim is exactly the kind a reviewer can get wrong from memory.
| Finding | Verdict |
|---|---|
| The DDR “frontier” framing is already contested: The Illusion of DDR Deployment, Nosyk, Duda and Korczyński, ANRW 2026, argues that resolvers scored as misconfigured DDR are in many cases transparent forwarders. | Accepted. Verified against the Crossref record for 10.1145/3822163.3827932 — title, all three authors, Proceedings of the 2026 Applied Networking Research Workshop, published 2026-07-20. ANRW is not in the corpus, so the “one paper in this corpus” claim stays true, but the page now says the 99% figure's interpretation is disputed and names the paper. The full text is behind an ACM 403 from this host and the page says the characterisation rests on metadata, not on a reading. |
“miekg/dns … no tagged releases (pin a commit, not a tag)” is wrong. The repo publishes no GitHub Release objects but does publish semver git tags. | Accepted. Verified two ways: api.github.com/repos/miekg/dns/tags returns v1.1.73 … v1.1.68, and proxy.golang.org/github.com/miekg/dns/@latest returns v1.1.73, 2026-08-19. The page's own advice would have made a reader's pin worse. Corrected, and the distinction between a Release object and a tag is now stated so the next check does not repeat it. |
| “Android's Private DNS is DoT” is stale. Since a July 2022 Google Play system update, Android 11+ uses DoH3 for well-known providers. | Accepted. Verified against Google's own Security Blog post, fetched and the sentence re-read: “Android devices from Android 11 onwards will use DoH3 instead of DoT for well-known DNS servers which support it”. The DoT row now says this, notes DoH3 is neither DoT nor RFC 9250 DoQ, and the check is in external_checks_dns.sh. |
| RFC 9539 (encrypted recursive-to-authoritative DNS, Experimental, Feb 2024) was in the run's own RFC dump and never reached the page. It is a different trust boundary from everything in the protocol table. | Accepted. The page now has a paragraph saying the table covers only the stub-to-recursive hop, and that “we measured encrypted DNS” must say which hop. |
| Several 2023–2026 DNS RFCs a “what is current” page should name are missing: 9953 (DNS over CoAP, March 2026), 9460 (SVCB/HTTPS RR), 9567 (DNS Error Reporting), 9520 (negative caching of failures), 9606 (RESINFO), 9848 (ECH bootstrap). | Partly accepted. All six verified against the RFC Editor index and added to the external check. RFC 9953 (DoC) is now a row in the protocol table with a zero corpus count, because omitting a five-month-old standardised transport from a table headed “what is actually current” is the exact failure this page is about. The other four were not added: 9460, 9567, 9520 and 9606 are real and relevant but each would need its own measurement-facing paragraph, and adding six RFC numbers without them would be a reading list, not guidance. Recorded here as the honest reason rather than as an oversight. |
opendata.rapid7.com 301s to sonardata.rapid7.com for every path, including both dataset directories the page cites. | Accepted. Verified with curl -L -w %{url_effective} on three paths. The substantive claim (data still current, updated 2026-08-23 / 2026-08-26) was unchanged. The page now names the new host and the check prints the redirect target. |
| iCloud Private Relay is the largest real-world ODoH deployment, so “not a deployed default” understates it. | Rejected. The reviewer's support is a third-party DFIR blog. Apple's own iCloud Private Relay Overview PDF 404s and the relevant Apple documentation pages render client-side, so no primary source for “Private Relay uses ODoH” could be fetched. Under this project's rule that a load-bearing industry claim needs a primary source, it is not going on the page. If someone finds an Apple document that says it, this is worth adding — it would materially change how the ODoH row reads. |
Apple's DNSSettings MDM profile and Windows Server 2025 DoH GA are coverage gaps. | Rejected as out of scope. Neither is a wrong claim on the page. The Apple docs page renders client-side and could not be read; the Windows claim was supported by search results rather than a Microsoft document the reviewer fetched. A page about measuring DNS does not need an enterprise-deployment survey. |
Confirmations: all ten RFC statuses and dates the page names, every tool version, the Farsight domain failing to resolve, the Firefox prefs and the five DoH provider records, and every URL except data.caida.org (401, already disclosed). | No change. |
Self-review, round three (after applying passes 1–3)
| Found | Verdict |
|---|---|
| The DDR tip box's lead sentence still said “the one paper that looked says the deployment is broken” while the rest of the box explained that the finding is contested. That is the exact pattern this site's history warns about: the careful version survives three paragraphs down, the prominent sentence loses the hedge. | Fixed. The box now leads with “what it measures is unsettled”. |
| The box's footnote credited “the authors' own public write-up” without that write-up having been fetched. | Fixed by fetching it. The APNIC post (Nosyk, 2 September 2025, with Duda and Korczyński) is a better source than the ACM-403 paper and gives quotable figures: “over 321k DDR-enabled open resolvers”, Google at 80.8%, top five at 97.4%. Five needles from it are now checked by external_checks_dns.sh. The box also makes the venue point that follows: DDR work in 2025–2026 is in PoPETs, at ANRW and on an operator blog, and this corpus contains one of the three. |
The code-block builder pinned its example to google.com; on the re-run google.com came back partial and the block would have illustrated the wrong verdict under a “disjoint” heading. | Fixed before it shipped: the builder now selects the first stanza whose verdict is disjoint, and the page states that rule. |
Pass 4 — figures re-check, after the fixes (sonnet, re-run of pass 2)
The pass-2 reviewer was re-run against the corrected page and scripts, as the workflow requires for any reviewer whose findings were acted on.
| Finding | Verdict |
|---|---|
The NON_PAPER_FIGURES ledger in verify_dns_figures.mjs was stale in three places, left behind by the very fixes it was checking — it still said “84 self-tests” (now 85), “35/35 home-grown” (now 34/34), and “28 / 75 / … / 37.3%” for the resolver run, which are the pre-fix, retracted verdict numbers. No check broke, because the correct values were independently present via the report; but a ledger whose entire purpose is “which artefact backs this figure” was pointing a future auditor at withdrawn ones. | Accepted, and fixed at the root rather than patched. The block now lists where each non-corpus figure comes from and never restates its value: a pointer cannot go stale, a copy always will. Two figures then failed the whole-page guard because their values were no longer duplicated anywhere — which is the guard doing its job. The robots.txt rate is now derived by report_dns.mjs instead of being lifted from OVERVIEW.md (a file the guard does not read), and the dnsdb.info A record was removed from the page: it rotated from 104.244.14.71 to 104.244.14.64 between two runs an hour apart, which is a poor thing to pin on a page about resolver-dependent answers. |
The Rapid7 guard's audit table claimed “all ten tuples were read” when the candidate regex matches 13 tuples under 11 spellings. The missing row is IMC 2016 Entropy/IP, tool name “Forward DNS dataset”. It is classified correctly and the family count (8 papers) is right — but the table was not exhaustive while saying it was. | Accepted. Reproduced against the raw extraction: 13 tuples, 11 spellings. The provenance table now has all 13 rows, marks the two rows that cover two tuples each, and the count is corrected in the fold comment, the report comment and the prose. This is the review layer catching an overstatement of the page's own rigour, which is exactly what the provenance page is most at risk of. |
verdict() fix confirmed correct and complete: 10/10 self-tests, and an independent re-implementation of the documented definitions reclassified all 100 names in the committed JSON with zero mismatches (46 / 21 / 8 / 25, 29 of 75 = 38.7%). one-answered and insufficient are reachable and simply do not occur in this run. | No change. |
Total-deadline fix confirmed: deadline is set once and remaining recomputed per iteration; a live query to a blackholed TEST-NET-1 address returned at 2.009 s against a 2.0 s timeout with a useful error string. | No change. |
Population confirmed unmoved by all four fold edits: A=108, B=202, A∩B=66, DNSPOP=244. Every page figure matches a fresh script run; <file> and <code> blocks round-trip byte-for-byte; the code block's example is confirmed the first disjoint stanza in the current run. | No change. |
The frozen2 snapshots no longer match the live page, because self-review round three was applied after they were taken. | Noted, not a defect: frozen2 is by definition the snapshot the reviewers read, and this log records what changed after it. Flagged here so nobody later cites frozen2 as canonical. |
Pass 5 — generic, no checklist (fable)
Read the frozen2 snapshots. As on every other page on this site, the generic pass found the worst remaining defect and it was of the predicted kind: a claim that is true nowhere a focused pass would look, and false where two sections meet.
| Finding | Verdict |
|---|---|
| The “What to report” section claimed the extraction measures “which resolver”, and the provenance page says in bold that it cannot. The page said the schema “has a field for only the first two” checklist items — Which resolver and Where from — and gave 50.8% and 42.2%. Those two rates are vantage location and any named tool version; neither measures resolver identification. A reader would have cited “42.2% of DNS papers say which resolver they used”, a figure about something else, from the most prominent methods section on the page. | Accepted; the most serious finding of this pass. The paragraph now says outright that almost none of the checklist is measurable, that the two rates measure adjacent things, that for which resolver the schema has no field and a full-text probe is an upper bound on mentions — and that this page therefore publishes no reporting rate for resolver identification, and you should distrust any page that does. The provenance's honest sentence now surfaces on the page instead of being contradicted by it. |
| The retracted pre-fix run survived in four places in the provenance log — “28/100”, “37.3%”, a repeat-stability claim crediting the published run with the buggy run's verdict counts (46 / 1 same-/24 / 28 disjoint), and a heading “The 28 names with disjoint answers” over a block listing eight. | Accepted. This is the site's own documented failure — a fix survives on the page and dies in the provenance. All four are gone, and the section now states no verdict counts of its own, pointing at the regenerated run output instead. In their place it records what three runs over ninety minutes actually showed: identical 46 and no-A-record 25 every time, so not identical 29 every time, while the partial/disjoint split moved 28-0 → 21-8 → 19-10 as CDN mappings churned. That stability difference is now a finding on the page, and the reason it quotes “not identical”. |
The NON_PAPER_FIGURES ledger and the dnsdb.info IP (also raised by pass 4). | Already fixed between the frozen2 snapshot and this report; see pass 4. |
| The DoC row's “0 / 0 / 0 / 0 / 0” was asserted, not probed. Section G had no CoAP probe. The reviewer ran one and found the claim true, but by this site's rule an “at all” claim must never come from a probe that was not run. | Accepted. DoC and a bare-CoAP contrast row are now in section G. The phrase “DNS over CoAP” matches 0 papers; 20 mention CoAP as the IoT protocol; a bare DoC matches 2 and both are homographs (a US government department, a table symbol). The row now says the zero is a run probe and shows its working. |
| The page never mentions IPv6, AAAA or record types, and its own instrument is silently A-only. The opening box said 75 names “had an address at all” where it means “had an A record”; a name with only AAAA or an HTTPS RR is indistinguishable from one that does not resolve. | Accepted — a real content gap, not just wording. The box now says “IPv4 address”; the script's docstring states the A-only limit and why it matters; a new run takeaway gives it a paragraph; “which record types, and which address family” is now an item on the reporting checklist, with the corpus rates behind it (AAAA 26.6%, CNAME 30.7%, SVCB/HTTPS 3.3% of the 244 — dual-stack is the minority practice here). Section G2 of the report prints them. |
The published script ignores the TC bit. With EDNS0 deliberately absent, a UDP answer caps at 512 bytes; a truncated answer would have been recorded as the resolver's complete set, manufacturing partial and disjoint verdicts. The page's own checklist tells readers to report UDP-versus-TCP fallback while its instrument could not see the condition that forces it. | Accepted. parse_answers now reads the TC bit, query() returns it, and the per-resolver line prints TRUNCATED (TC set, answer incomplete). The docstring explains why the script flags rather than retries. Zero truncations in the published run — but that is now a measured zero. The checklist item gained the TC question and the corpus rate (9.0% of the 244 mention truncation or TCP fallback at all). |
build_query() sat outside the try in query(), so an unencodable name raised despite the docstring's “never raises” contract. | Accepted, moved inside, tested with an IDN. |
| Cloudflare's 12.4% was quoted from the APNIC post but was not among the needles the external check verifies. | Accepted; it is now the fifth of six APNIC needles and passes. |
Files table said verify_dns_figures.mjs checks 29 needles; it checks 31. | Accepted, corrected, and the row now describes the pypdf fallback and the pointer-not-value ledger. |
| The ethics lead explained the pattern as “no human subjects”, above the page's own table showing 16 interview-or-survey and 11 user-study papers in the population. | Accepted. Softened to a plausible reading with the counter-evidence named in the same sentence. |
| Scope note said “5,859 papers with extracted full text” against the methodology section's “4 of 5,859 have none”. | Accepted; the note now gives 5,855 readable and says the 4 count as negatives. |
| Spamhaus was named in the passive-DNS table with an em-dash instead of a count; it is not a fold family. | Accepted; removed from the row and its home in the 8-paper “other feeds” row is stated. |
| “15 of them say so in the title” — the report says title or slug. | Accepted, corrected. |
| The review snapshots are now three generations deep (passes 1–3 read frozen1, pass 5 read frozen2, live is neither), so “the reviewers read the same frozen snapshot” is no longer literally true. | Accepted as a process finding. The log's snapshot paragraph names which pass read which snapshot, and every change made between them is in this log. Not re-frozen a third time: another round of review is not planned, and a snapshot nobody reads is not worth the claim. |
A parked/sentinel A record (domaincontrol.com → 127.0.0.1 from all three) counts as “identical” agreement. | Rejected as a page change, recorded as a limit. It is true and mildly interesting, but the script measures whether resolvers agree, not whether the answer is useful, and adding sentinel detection would be a different tool. Noted here so the next person does not rediscover it as a bug. |
Files
| Path | What |
|---|---|
scripts/dns_fold.mjs | The fold. Ordered families, keyed exceptions, one guarded family (Rapid7), 85 self-tests, residue printed by the report. |
scripts/report_dns.mjs | Every corpus figure with its denominator. Exits 1 if the corpus contracts or the fold self-tests fail. --list a|b|bonly|aonly|pop|web, --quotes <re>. |
scripts/verify_dns_figures.mjs | 31 per-paper needles against paper.cols.txt, with a pypdf fallback and the route labelled per needle (one is PDF-only). Prints a WEAK NEEDLE warning for any needle short enough to match by accident, the normalisation record, and a non-corpus figure block that names artefacts rather than values — an earlier version restated the values and every one of them went stale inside a single review cycle. |
scripts/external_checks_dns.sh + scripts/dnschk/ | Every external fact, re-runnable. |
scripts/dns_snip.mjs | Prints the sentence around a regex in a paper, whitespace collapsed. How the quote rewrites above were made. |
scripts/build_dns_codeblock.mjs | Regenerates the page's <code> block from the run output. |
pages/resolver_disagreement.py | The published script. |
out/dns/ | report.txt, verify.txt, external.txt, resolver_run.txt, resolver_run.json, bonly_audit_raw.txt, tool_candidates.txt, tranco100.txt. |
provenance/design/dns.txt · Last modified: by karel.kubicek.claude