| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| design:dns [2026/08/27 23:21] – Generic (fable) review applied. Worst finding: 'What to report' claimed the extraction measures which resolver a paper used, which the provenance page says in bold it cannot — the 42.2% is a tool-version rate, and the page now publishes no resolver-identi karel.kubicek.claude | design:dns [2026/09/25 03:03] (current) – Is-this-your-page row: squatted, parked, expired or dangling names and WHOIS/RDAP registration data -> Security:Domain abuse. Authored by Claude. karel.kubicek.claude |
|---|
| | whether to crawl, scan, or unpack an app at all | [[Design:Automated measurements]] | | | whether to crawl, scan, or unpack an app at all | [[Design:Automated measurements]] | |
| | who owns a name (WHOIS, RDAP, the Public Suffix List) | not here — see [[Design:Website classification]] and [[Design:IP classification]]. Those answer registry questions, not resolution questions, and this page's tool inventory excludes them on purpose | | | who owns a name (WHOIS, RDAP, the Public Suffix List) | not here — see [[Design:Website classification]] and [[Design:IP classification]]. Those answer registry questions, not resolution questions, and this page's tool inventory excludes them on purpose | |
| | | whether a name is a squat, parked, expired and re-registered, or a dangling record someone else can claim — and what WHOIS and RDAP still tell you about who registered it | [[Security:Domain abuse]] | |
| | the ethics of probing other people's resolvers | [[Practices:Ethics]], then [[#Active DNS measurement is scanning]] below | | | the ethics of probing other people's resolvers | [[Practices:Ethics]], then [[#Active DNS measurement is scanning]] below | |
| |
| **RIPE Atlas** appears in **75** papers corpus-wide and **24** of the 244 here — and **21** of those 24 are IMC papers, which is another way of saying the same thing as the venue table. It is not in the membership rule because most of the 75 use it for traceroute, not DNS. But it is the standard way to ask the same DNS question from thousands of vantage points, and DNS is one of its native measurement types: {[randall2021_home]} localises interception with it, {[moura2019_cache]} probes recursive resolvers worldwide with it, {[aldalky2019_look]} uses it for globally distributed probes, and {[randall2020_trufflehunter]} uses it to emulate geographically distributed users filling resolver caches. {[bhaskar2022_many]}, by contrast, does **not** use RIPE Atlas — it sends packets from its own vantage point, which is exactly why source-address choice is the variable it can manipulate. | **RIPE Atlas** appears in **75** papers corpus-wide and **24** of the 244 here — and **21** of those 24 are IMC papers, which is another way of saying the same thing as the venue table. It is not in the membership rule because most of the 75 use it for traceroute, not DNS. But it is the standard way to ask the same DNS question from thousands of vantage points, and DNS is one of its native measurement types: {[randall2021_home]} localises interception with it, {[moura2019_cache]} probes recursive resolvers worldwide with it, {[aldalky2019_look]} uses it for globally distributed probes, and {[randall2020_trufflehunter]} uses it to emulate geographically distributed users filling resolver caches. {[bhaskar2022_many]}, by contrast, does **not** use RIPE Atlas — it sends packets from its own vantage point, which is exactly why source-address choice is the variable it can manipulate. |
| |
| **Generic scanners** — ZMap and XMap (112 papers), ZGrab (31), Scapy (33) — appear in 38 of the 244. ZMap is how you find open resolvers; it is not a DNS toolkit. [[Design:Automated measurements]] covers the scan branch generally. | **Generic scanners** — ZMap and XMap (110 papers), ZGrab (32), Scapy (33) — appear in 37 of the 244. ZMap is how you find open resolvers; it is not a DNS toolkit. Those first two counts are the **same paper sets** [[Programming:Internet scanning]] publishes as ZMap 94 + XMap 16 and ZGrab 32; the two pages use different folds and were reconciled paper-by-paper on 2026-09-17 ([[provenance:design:dns]]). [[Design:Automated measurements]] covers the scan branch generally. |
| |
| ===== Five ways a DNS measurement goes wrong ===== | ===== Five ways a DNS measurement goes wrong ===== |
| ===== Active DNS measurement is scanning ===== | ===== Active DNS measurement is scanning ===== |
| |
| Sending queries to resolvers you do not own is a scan, and it has a failure mode the rest of the scan branch does not: **an open resolver will amplify whatever you send it at somebody else.** Kührer et al. {[khrer2015_going]} //"find up to 20 million open resolvers in the weekly IPv4 scans in 2015"//, and **58 of the 244** papers here match a full-text probe for amplification or reflection (**15** of them say so in the title or the slug). If your measurement queries open resolvers, you are one misconfigured source address away from being the attack. | Sending queries to resolvers you do not own is a scan, and it has a failure mode the rest of the scan branch does not: **an open resolver will amplify whatever you send it at somebody else.** Kührer et al. {[kuhrer2015_going]} //"find up to 20 million open resolvers in the weekly IPv4 scans in 2015"//, and **58 of the 244** papers here match a full-text probe for amplification or reflection (**15** of them say so in the title or the slug). If your measurement queries open resolvers, you are one misconfigured source address away from being the attack. |
| |
| The DNS population states more about ethics than the corpus average on three of four fields, and **less** on the one that names an ethics board. A plausible reading is that this is work which mitigates harm operationally and mostly has no human subjects to take to an IRB — but 16 of the 244 are tagged ''interview-or-survey'' and 11 ''user-study'', so that is a tendency here, not a property: | The DNS population states more about ethics than the corpus average on three of four fields, and **less** on the one that names an ethics board. A plausible reading is that this is work which mitigates harm operationally and mostly has no human subjects to take to an IRB — but 16 of the 244 are tagged ''interview-or-survey'' and 11 ''user-study'', so that is a tendency here, not a property: |
| | Ververis et al., PoPETs 2025, //Path to Encrypted DNS with DDR// {[ververis2025_path]} | Where the encrypted-DNS question is now, and how thin the evidence still is. | | | Ververis et al., PoPETs 2025, //Path to Encrypted DNS with DDR// {[ververis2025_path]} | Where the encrypted-DNS question is now, and how thin the evidence still is. | |
| |
| Also worth your time, by topic: {[lu2019_over]} and {[chhabra2021_over]} on the cost and performance of encrypted DNS; {[li2024_worldwide]} on its reachability; {[khrer2015_going]} on open resolvers; {[aldalky2019_look]} on ECS behaviour; {[moura2019_cache]} on TTL and {[randall2020_trufflehunter]} on what a cache leaks; {[liu2023_dial]} on the scale of NXDOMAIN traffic; {[nosyk2023_extended]} on Extended DNS Errors (RFC 8914), which give you a machine-readable reason for a failure instead of a bare SERVFAIL; {[dong2024_exploring]} on the HTTPS resource record; {[hounsel2020_comparing]} on what DoT and DoH do to page-load time; {[ashiq2025_decoding]} on automated DNSSEC error diagnosis; and {[xia2026_starlink]} for DNS used as the instrument to measure something else entirely. | ==== Four current RFCs to measure ==== |
| | |
| | The four documents below are current Proposed Standards in the [[https://www.rfc-editor.org/rfc-index/|RFC Editor index]] (checked 2026-09-17). They are here as measurement guidance, not as a protocol reading list. |
| | |
| | **[[https://www.rfc-editor.org/info/rfc9460/|RFC 9460]], Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) (November 2023, Proposed Standard).** The HTTPS RR is not another spelling for A/AAAA or CNAME: it lets a client discover service endpoints and connection parameters before connecting, including an apex alias where CNAME cannot be used. For a web measurement, query and retain both SVCB (type 64) and HTTPS (type 65) RRsets alongside A/AAAA, including AliasMode versus ServiceMode, target names, priorities, parameters and fallback. Only **3.3% of the 244** papers mention SVCB/HTTPS, so {[dong2024_exploring]} belongs in this gap: a pipeline that records only addresses cannot tell whether a service used the newer binding or legacy resolution path. |
| | |
| | **[[https://www.rfc-editor.org/info/rfc9567/|RFC 9567]], DNS Error Reporting (April 2024, Proposed Standard).** This is the companion to [[https://www.rfc-editor.org/info/rfc8914/|RFC 8914]]: an authoritative server can advertise a report channel in EDNS0, and a validating resolver can turn a resolvability or validation error into a TXT report query whose QNAME carries the failed QTYPE/name and Extended DNS Error. When your checklist asks what you did on SERVFAIL, record the RCODE, EDE and EDNS options separately, and distinguish the original lookup from any ''_er'' report query. In a deployment study, measure both report-channel advertisement and report-query arrival, rather than treating end-user error counts as the whole reporting mechanism. |
| | |
| | **[[https://www.rfc-editor.org/info/rfc9520/|RFC 9520]], Negative Caching of DNS Resolution Failures (December 2023, Proposed Standard; updates RFC 2308, RFC 4035 and RFC 4697).** This is the document behind failure mode 3: it makes caching of resolution failures, including DNSSEC validation failures, mandatory and extends the no-aggressive-requery rule beyond NS at a failed zone's parent to all query types and ancestor zones. For a repeated-query experiment, record the resolver, name/type/class, transport, RCODE/EDE, retry timing and failure-cache age; run a fresh-name or fresh-resolver control and do not count a second SERVFAIL as an independent upstream observation. Sweep inter-query delays across the RFC's 1-second minimum and 5-minute maximum cache bounds: a repeated failure may be cached, not another authoritative response. |
| | |
| | **[[https://www.rfc-editor.org/info/rfc9606/|RFC 9606]], DNS Resolver Information (RESINFO) (June 2024, Proposed Standard).** This extends the DDR/DNR discovery family the page calls the frontier: a client can query the RESINFO RR at ''resolver.arpa'' (or the resolver's authentication domain) to learn capability key/value pairs such as ''qnamemin'', ''exterr'' and ''infourl''. Probe it with RD clear, require an authoritative answer, and retain the exact RRset per resolver and vantage. Do not conflate it with NSID (RFC 5001): **NSID answers who responded; RESINFO answers what the resolver can do**. The first is an identity signal for interception; the second is a capability signal for resolver selection and measurement interpretation. |
| | |
| | Also worth your time, by topic: {[lu2019_over]} and {[chhabra2021_over]} on the cost and performance of encrypted DNS; {[li2024_worldwide]} on its reachability; {[kuhrer2015_going]} on open resolvers; {[aldalky2019_look]} on ECS behaviour; {[moura2019_cache]} on TTL and {[randall2020_trufflehunter]} on what a cache leaks; {[liu2023_dial]} on the scale of NXDOMAIN traffic; {[nosyk2023_extended]} on Extended DNS Errors (RFC 8914), which give you a machine-readable reason for a failure instead of a bare SERVFAIL; {[dong2024_exploring]} on the HTTPS resource record; {[hounsel2020_comparing]} on what DoT and DoH do to page-load time; {[ashiq2025_decoding]} on automated DNSSEC error diagnosis; and {[xia2026_starlink]} for DNS used as the instrument to measure something else entirely. |
| |
| ===== Use in publications ===== | ===== Use in publications ===== |
| |
| Figures from ''scripts/report_dns.mjs'' over the 5,859-paper extraction. Every count is of papers, with its denominator in the table header or the sentence. The tool fold is ''scripts/dns_fold.mjs'' (85 self-tests, 2 unmapped strings out of 976 candidate tuples); it names its off-topic families rather than discarding them silently, because a loose enough candidate sweep for ''hnsd'' and ''resolvectl'' also catches every speech-recognition tool in the corpus. | Figures from ''scripts/report_dns.mjs'' over the 5,859-paper extraction. Every count is of papers, with its denominator in the table header or the sentence. The tool fold is ''scripts/dns_fold.mjs'' (85 self-tests, 2 unmapped strings out of 974 candidate tuples); it names its off-topic families rather than discarding them silently, because a loose enough candidate sweep for ''hnsd'' and ''resolvectl'' also catches every speech-recognition tool in the corpus. |
| |
| ==== What the instrument families look like ==== | ==== What the instrument families look like ==== |
| | dnssec-tool | 3 | 3 | yes | | | dnssec-tool | 3 | 3 | yes | |
| | open-resolver-census | 1 | 1 | yes | | | open-resolver-census | 1 | 1 | yes | |
| | scanner-generic (ZMap, ZGrab, Scapy) | 156 | 38 | no | | | scanner-generic (ZMap, ZGrab, Scapy) | 154 | 37 | no | |
| | vantage-platform (RIPE Atlas 75, MobileAtlas 2) | 77 | 24 | no | | | vantage-platform (RIPE Atlas 75, MobileAtlas 2) | 77 | 24 | no | |
| |
