Differences

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

--- design:dns [2026/08/27 23:15] – Figures re-check applied: drop the dnsdb.info A record (it rotated between two runs an hour apart) and correct the Rapid7 guard's tuple count. 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 4: / Line 4: @@
 <WRAP important>
-**A DNS answer is a property of the query, not only of the name.** It depends on which resolver you asked, where you asked from, what your source port happened to be, and what was already in a cache. In a run on 2026-08-27 from one machine, Google, Cloudflare and Quad9 **did not all return the same addresses for 29 of the 75** Tranco top-100 names that had an address at all (38.7%), and for **8** of those no two of the three shared a single address. Another **25 of the 100** had no A record at the apex at all. Details and the script are in [[#Measure your own resolver dependence]].
+**A DNS answer is a property of the query, not only of the name.** It depends on which resolver you asked, where you asked from, what your source port happened to be, and what was already in a cache. In a run on 2026-08-27 from one machine, Google, Cloudflare and Quad9 **did not all return the same addresses for 29 of the 75** Tranco top-100 names that had an IPv4 address at all (38.7%), and for **10** of those no two of the three shared a single address. Another **25 of the 100** have no A record at the apex at all. Details and the script are in [[#Measure your own resolver dependence]].
 </WRAP>
-Everything below about "the literature" is a claim about **seven venues** — CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf and IEEE S&P, 2010–2026, **5,859** papers with extracted full text. EuroS&P, ACSAC, RAID, AsiaCCS, CHI and SOUPS are not in it, and neither is the DNS-operations literature (DNS-OARC, RIPE, IETF). A DNS venue survey would look different; see [[Literature:Corpus]] for what this corpus is and is not.
+Everything below about "the literature" is a claim about **seven venues** — CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf and IEEE S&P, 2010–2026, **5,859** extracted papers (full text is readable for 5,855 of them; the other 4 count as negatives in every full-text probe below). EuroS&P, ACSAC, RAID, AsiaCCS, CHI and SOUPS are not in it, and neither is the DNS-operations literature (DNS-OARC, RIPE, IETF). A DNS venue survey would look different; see [[Literature:Corpus]] for what this corpus is and is not.
 ===== Is this your page? =====
@@ 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 84: / Line 85: @@
 | **Rapid7 Open Data** (Sonar FDNS / RDNS) | 8 | **Still live**, contrary to what a 2022-era memory will tell you: ''sonar.fdns_v2'' last updated 2026-08-23, ''sonar.rdns_v2'' 2026-08-26. The **host has moved**: every path under ''opendata.rapid7.com'' now 301s to ''sonardata.rapid7.com''. | Bulk forward and reverse DNS over the IPv4 space. |
 | **ICANN CZDS** / zone files | 3 | Current. Per-TLD application. | The authoritative list of registered names in participating zones. It is the denominator a "we resolved the top 1M" study does not have. |
-| **Active DNS Project**; **360 / 114DNS**; **Spamhaus**; **DNS Observatory** | 2 / 4 / — / 1 | Various. | Regional and vendor feeds; the Chinese feeds are the only route to some of that namespace. |
+| **Active DNS Project**; **360 / 114DNS**; **DNS Observatory** | 2 / 4 / 1 | Various. | Regional and vendor feeds; the Chinese feeds are the only route to some of that namespace. Spamhaus's passive-DNS API and seven other one-off feeds fold into the 8-paper "other passive-DNS feeds" row above rather than getting their own. |
 ==== Where you ask from ====
@@ Line 90: / Line 91: @@
 **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 =====
@@ Line 96: / Line 97: @@
 ==== 1. The answer depends on which resolver you asked ====
-This is the oldest finding on the page and it has never stopped being true. Ager et al. {[ager2010_comparing]} sent the same queries to the local resolver, Google and OpenDNS from 60-plus vantage points in 2010 and found that //"the answers to the DNS resolvers differ in terms of subnets for approximately 2,000 out of our 10,000 host names. In half of these cases, the returned IP addresses even belong to different ASs and countries."//((Quoted with whitespace normalised: both the .cols rendering and a pypdf re-extraction of the PDF render the figures as 2 , 000 and 10, 000, and hyphenate dif- fer across a line break. Checked 2026-08-27; see [[provenance:design:dns]].)) Sixteen years later the run in [[#Measure your own resolver dependence]] gets **38.7%** not-identical on a 75-name comparable set, with **10.7%** of them sharing no address between any pair of resolvers.
+This is the oldest finding on the page and it has never stopped being true. Ager et al. {[ager2010_comparing]} sent the same queries to the local resolver, Google and OpenDNS from 60-plus vantage points in 2010 and found that //"the answers to the DNS resolvers differ in terms of subnets for approximately 2,000 out of our 10,000 host names. In half of these cases, the returned IP addresses even belong to different ASs and countries."//((Quoted with whitespace normalised: both the .cols rendering and a pypdf re-extraction of the PDF render the figures as 2 , 000 and 10, 000, and hyphenate dif- fer across a line break. Checked 2026-08-27; see [[provenance:design:dns]].)) Sixteen years later the run in [[#Measure your own resolver dependence]] gets **38.7%** not-identical on a 75-name comparable set, with **13.3%** of them sharing no address between any pair of resolvers.
 Two mechanisms do most of it. CDNs and GeoDNS answer according to where they think you are, and **EDNS Client Subnet** (RFC 7871 — note it is **Informational**, not a standard) is how a public resolver tells them. Al-Dalky et al. {[aldalky2019_look]} measured how resolvers actually use it and found the behaviour is not uniform: //"3382 out of 4147 resolvers in the CDN dataset send 100% of their A and AAAA queries with an ECS option"//, and that //"103 recursive resolvers, or over half of all recursive resolvers we could study"//, //"don't control caching based on scope at all"// — they reuse a cached response outside the prefix it was scoped for — a caching bug that hands the wrong client the wrong answer. Anycast does the rest; [[Design:IP classification]] covers why geolocating an anycast address is meaningless.
@@ Line 134: / Line 135: @@
 | **DoH** — DNS over HTTPS | RFC 8484, October 2018, Proposed Standard | 0 / 0 / 23 / 16 / 9 | The one the browsers deployed. The most-measured of the encrypted transports and still the default assumption. |
 | **DoQ** — DNS over QUIC | RFC 9250, May 2022, Proposed Standard | 0 / 0 / 4 / 1 / 1 | Standardised, barely measured: **6** of the 244 mention it at all (10 across the whole 5,859). An open area, not a settled method. |
-| **DoC** — DNS over CoAP | RFC 9953, **March 2026**, Proposed Standard | 0 / 0 / 0 / 0 / 0 | Five months old at the time of writing and **not measured in this corpus at all**. It targets constrained IoT networks, so it is unlikely to matter for a web crawl — but it is on the transport list now, and a page that omitted it would be describing 2024. |
+| **DoC** — DNS over CoAP | RFC 9953, **March 2026**, Proposed Standard | 0 / 0 / 0 / 0 / 0 | Five months old at the time of writing. The zero is a **run probe, not an assumption**: the phrase "DNS over CoAP" appears in no paper in the corpus, and the 20 that mention CoAP at all mean the IoT protocol (a bare DoC matches two papers and both are homographs — a US government department and a table symbol). It targets constrained networks, so it is unlikely to reach a web crawl; it is here because a table headed "what is actually current" that omitted a five-month-old standardised transport would be describing 2024. |
 | **ODoH** — Oblivious DoH | RFC 9230, June 2022, **Experimental** | 0 / 0 / 5 / 4 / 2 | Experimental in the RFC sense as well as the deployment sense. Do not describe it as a deployed default. |
 | **DDR** — Discovery of Designated Resolvers | RFC 9462, November 2023, Proposed Standard (with DNR, RFC 9463) | 0 / 0 / 0 / 0 / 1 | The frontier, and the answer to "how does a client find an encrypted resolver at all". **Exactly one paper in this corpus measures it.** |
@@ Line 168: / Line 169: @@
 ===== 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). 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 — which is the pattern you would expect from work that mitigates harm operationally and does not go to an IRB because it has no human subjects:
+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:
 ^ Field ^ DNS population (241 empirical of the 244) ^ Whole corpus (5,118 empirical) ^
@@ Line 196: / Line 197: @@
 </WRAP>
-A DNS methods section is complete when a replicator can answer all of these. The extraction has a field for only the first two, and the table above is how often those are answered (**50.8%** and **42.2%**); for the rest the schema has no field, so this list is a standard, not a measurement:
+A DNS methods section is complete when a replicator can answer all of these. **Almost none of it is measurable from the extraction, and the one item that matters most is the least measurable.** The table above measures two things that are only adjacent to this list: whether a paper named a **vantage location** (50.8%), which is the "where from" item, and whether it named **any tool version at all** (42.2%), which is not about resolvers. For **which resolver** — the first and most important item — the schema has no field, and a full-text probe for resolver IP literals is an upper bound on mentions, not on use. **This page therefore publishes no reporting rate for resolver identification**, and you should distrust any page that does. The list below is a standard, not a measurement:
   * **Which resolver**, by address and by name, including whether it was your own recursive server, the system resolver, or a public one. If more than one, which for which measurement.
   * **Where from** — the source addresses and networks, and whether they were datacenter or residential ([[Design:Crawling location]]).
-  * **The transport** — Do53 over UDP or TCP, DoT, DoH, DoQ — and whether you fell back.
+  * **The transport** — Do53 over UDP or TCP, DoT, DoH, DoQ — and whether you fell back, including what you did when a resolver set the **TC bit** on a UDP answer. Only **9.0%** of the 244 mention truncation or TCP fallback at all.
+  * **Which record types, and which address family.** A study that queries A only and a study that queries A and AAAA produce different "did not resolve" sets, and neither is wrong until you fail to say which you did. **26.6%** of the 244 mention AAAA, **30.7%** CNAME, and **3.3%** the SVCB/HTTPS record — so dual-stack is the minority practice here, not the default.
   * **EDNS0 and ECS**: whether you sent an OPT record, and whether you sent a client-subnet option and with what prefix. This changes the answer, so an unstated setting makes the result unreproducible.
   * **Query rate and retry policy**, and what you did on SERVFAIL and timeout. A timeout silently recorded as "no record" is the most common way a DNS dataset acquires a systematic hole.
@@ Line 223: / Line 225: @@
 Python 3.8+, standard library only: no dnspython, no dig, nothing to install.
+**This script queries A records only.** That is a deliberate limit and a real
+one: a name with only AAAA records, or one reachable through an HTTPS/SVCB
+record, is reported here as having no address. If your study is dual-stack,
+query both families and report both -- "the name did not resolve" and "the name
+has no IPv4 address" are different findings and this script can only tell you
+the second.
 What it reports, per name:
-  * the A-record set each resolver returned
+  * the A-record set each resolver returned, and whether the answer was
+    truncated (TC set) rather than complete
   * whether all resolvers agree, agree on the /24, or disagree outright
   * the TTL each resolver returned, and the TTL on an immediate second query
@@ Line 300: / Line 310: @@
 def parse_answers(buf, txid):
-    """Return (rcode, [(ttl, ip), ...]) for the A records in a response."""
+    """Return (rcode, truncated, [(ttl, ip), ...]) for the A records in a response.
+    The TC (truncation) bit matters here and is easy to skip. This script sends
+    no EDNS0 OPT record on purpose (see build_query), so a UDP response is
+    capped at 512 bytes; a resolver with more addresses than fit sets TC and
+    returns a partial answer. Recording that as the resolver's complete set
+    would manufacture "partial" and "disjoint" verdicts out of nothing. When TC
+    is set the result is flagged rather than silently trusted -- a real
+    measurement would retry over TCP, which this script deliberately does not
+    do, because the point is to show you the condition, not to paper over it.
+    """
     if len(buf) < 12:
         raise ValueError("short response")
@@ Line 307: / Line 327: @@
         raise ValueError("transaction id mismatch: possible off-path answer")
     rcode = flags & 0x0F
+    truncated = bool(flags & 0x0200)
     off = 12
     for _ in range(qd):
@@ Line 318: / Line 339: @@
             out.append((ttl, socket.inet_ntoa(buf[off:off + 4])))
         off += rdlen
-    return rcode, out
+    return rcode, truncated, out
 def query(server, name, timeout=3.0):
     """One UDP query. Returns a dict; never raises."""
-    txid, pkt = build_query(name, txid=None)
     sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
     started = time.time()
     deadline = started + timeout
     try:
+        # Inside the try: an unencodable name must return a dict like every
+        # other failure, not raise. The docstring promises that.
+        txid, pkt = build_query(name, txid=None)
         sock.sendto(pkt, (server, 53))
         # Accept only a datagram from the address we asked. This does not make
@@ Line 347: / Line 370: @@
             if peer[0] == server:
                 break
-        rcode, answers = parse_answers(data, txid)
+        rcode, truncated, answers = parse_answers(data, txid)
         return {"ok": True, "rcode": RCODE.get(rcode, str(rcode)),
+                "truncated": truncated,
                 "rtt_ms": round((time.time() - started) * 1000, 1),
                 "ttls": [t for t, _ in answers],
@@ Line 354: / Line 378: @@
     except Exception as exc:                       # timeout, refused, malformed
         return {"ok": False, "error": f"{type(exc).__name__}: {exc}",
+                "truncated": False,
                 "rtt_ms": round((time.time() - started) * 1000, 1),
                 "ttls": [], "ips": []}
@@ Line 521: / Line 546: @@
                 elif ttl2 == ttl1:
                     cached = f"  (2nd query TTL {ttl2}: unchanged)"
+            trunc = "  TRUNCATED (TC set, answer incomplete)" if a.get("truncated") else ""
             print(f"    {label:<12} {a['rcode']:<9} {a['rtt_ms']:>6.1f} ms  "
-                  f"ttl={ttl1:<6} {', '.join(a['ips']) or '(no A record)'}{cached}")
+                  f"ttl={ttl1:<6} {', '.join(a['ips']) or '(no A record)'}{cached}{trunc}")
         record.append({"name": name, "verdict": v, "first": first, "second": second})
         print()
@@ Line 570: / Line 596: @@
 <code>
 # resolvers: Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9)
-# names: 100   run at 2026-08-27T22:56:27Z
+# names: 100   run at 2026-08-27T23:17:26Z
-gstatic.com   -> disjoint
+googleapis.com   -> disjoint
-    Google       NOERROR     36.6 ms  ttl=300    172.217.208.120, 172.217.208.94  (2nd query TTL 300: unchanged)
+    Google       NOERROR     39.5 ms  ttl=300    74.125.29.103, 74.125.29.104, ...
-    Cloudflare   NOERROR     22.0 ms  ttl=90     74.125.29.120, 74.125.29.94  (2nd query TTL 22: served from cache)
+    Cloudflare   NOERROR     10.1 ms  ttl=172    172.217.208.103, 172.217.208.104, ...
-    Quad9        NOERROR    122.9 ms  ttl=160    142.250.154.120, 142.250.154.94
+    Quad9        NOERROR     14.3 ms  ttl=165    192.178.183.103, 192.178.183.104, ...
 summary A: all 100 names
   identical        46   46.0%
-  partial          21   21.0%
+  partial          19   19.0%
-  disjoint          8    8.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          21   28.0%
+  partial          19   25.3%
-  disjoint          8   10.7%
+  disjoint         10   13.3%
   NOT identical    29   38.7%   <- the headline: at least one resolver disagreed with another
 </code>
-Four things to take from it, none of which is a claim about the Internet — it is one machine, one instant, three resolvers, one hundred names:
+Five things to take from it, none of which is a claim about the Internet — it is one machine, one instant, three resolvers, one hundred names:
-  - **The number to quote is "not identical", not "disjoint".** 29 of the 75 comparable names (**38.7%**) got answers that were not all the same. Only **8** were fully disjoint, meaning no two of the three resolvers shared a single address — ''gstatic.com'' above is one, three different Google ranges from three resolvers. Quoting the disjoint figure as though it meant "any disagreement" understates it by more than half; quoting "any disagreement" as though it meant disjoint overstates it by more than three times. The script prints both and says which to use.
+  - **The number to quote is "not identical", not "disjoint".** 29 of the 75 comparable names (**38.7%**) got answers that were not all the same. **10** were fully disjoint: no two of the three resolvers shared a single address. Quoting the disjoint figure as though it meant "any disagreement" understates it by two thirds; quoting "any disagreement" as though it meant disjoint overstates it by three times. The script prints both and says which to use.
+  - **And "not identical" is the stable one.** This list was run three times over ninety minutes. ''identical'' came back **46** every time and ''no-A-record'' **25** every time, so ''not identical'' was **29** every time — but the split between ''partial'' and ''disjoint'' moved (28/0, then 21/8, then 19/10) as CDN mappings churned under the measurement. A figure that moves by a factor of three between runs an hour apart is not a figure to build an argument on; the one that did not move is.
   - **25 of the 100 names have no A record at the apex.** They are CDN and infrastructure zones. A pipeline that resolves and drops failures loses them silently.
-  - **Summary B is the denominator.** Summary A over all names mixes "resolvers disagree" with "there was nothing to disagree about".
+  - **This is IPv4 only.** The script asks for A records, so "no address" here means "no IPv4 address" — a name reachable only over IPv6, or through an HTTPS/SVCB record, is indistinguishable from one that does not resolve. **26.6%** of the 244 papers mention AAAA at all. If your study is dual-stack, that is a design decision you have to make and report, and this run does not make it for you.
   - **Read the verdict logic before trusting any of this.** The first version of this script intersected all three resolvers' answer sets at once, so two resolvers agreeing exactly and a third differing came out as //disjoint// — the opposite of what the word means. It mislabelled **17 of 28** names on the first run, and this page published the wrong figure until a reviewer caught it. The comparison is now pairwise and ''%%--self-test%%'' checks it against ten cases including that one. If you extend the script to more resolvers, keep the comparison pairwise.
@@ Line 611: / Line 638: @@
 | 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 =====
-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 ====
@@ Line 627: / Line 666: @@
 | dnssec-tool | 3 | 3 | 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 |