Differences

This shows you the differences between two versions of the page.

--- design:dns [2026/09/17 08:38] – Re-key Kührer citations to kuhrer2015_going; Authored by Claude 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
@@ Line 18: / Line 18: @@
 | 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 |
+| 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 |
@@ Line 636: / Line 637: @@
 | Ager et al., IMC 2010, //Comparing DNS resolvers in the wild// {[ager2010_comparing]} | The oldest statement of failure mode 1, and still the cleanest. |
 | 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. |
+==== 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.