Network Working Group H. Duan Internet-Draft HKUST(GZ) Intended status: Informational L. Xu Expires: 2 January 2027 A. Perrig ETH Zurich 1 July 2026 DNS Work Amplification: Problem Statement, Terminology, and Taxonomy draft-duan-dnsop-work-amplification-00 Abstract Recursive DNS resolvers are expected to bound the amount of "work" performed when answering a client query. DNS specifications discuss such bounds but leave key concepts, accounting rules, and safe limits underspecified. This leeway has led to divergent implementations and makes systematic bounding difficult, contributing to denial-of-service attacks that amplify resolver work and harm different DNS components. This document describes the problem space of DNS work amplification. It defines terminology for discussing work performed during a single resolution instance, develops a taxonomy of work-amplification vulnerabilities along resource and mechanism axes, and analyses where existing DNS specifications leave amplification-relevant behavior underspecified. The document is descriptive: it does not itself specify protocol changes or operational requirements. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 2 January 2027. Duan, et al. Expires 2 January 2027 [Page 1] Internet-Draft DNS Work Amplification July 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Potential Victims . . . . . . . . . . . . . . . . . . . . 7 3.2. Example Attack Scenarios . . . . . . . . . . . . . . . . 8 4. Taxonomy of Work-Amplification Vulnerabilities . . . . . . . 9 4.1. Scope and Limitations of the Taxonomy . . . . . . . . . . 9 4.2. Resource Amplification Labels . . . . . . . . . . . . . . 9 4.3. Mechanism Labels . . . . . . . . . . . . . . . . . . . . 10 4.4. Example Mapping of Known Attacks . . . . . . . . . . . . 11 5. Analysis of Amplification Vectors and Specification Enablers . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Conventions for RFC References in this Section . . . . . 12 5.2. Selection and Structure of Issues . . . . . . . . . . . . 13 5.3. Work budgeting and accounting . . . . . . . . . . . . . . 13 5.4. Alias processing and restart logic . . . . . . . . . . . 15 5.5. Delegation traversal and nameserver discovery . . . . . . 16 5.6. Retry, failover and concurrency . . . . . . . . . . . . . 17 5.7. Response content and section semantics . . . . . . . . . 18 5.8. DNSSEC validation and proof semantics . . . . . . . . . . 19 5.9. Cache admission, relevance and maintenance . . . . . . . 20 5.10. Extension-induced secondary resolution . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. Implementation Status . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Duan, et al. Expires 2 January 2027 [Page 2] Internet-Draft DNS Work Amplification July 2026 1. Introduction DNS specifications have long warned that resolvers need to bound the amount of work performed per client query in order to avoid runaway loops and chain reactions (see [RFC1034] and [RFC1035]). In practice, a single resolution can exercise multiple interacting mechanisms —- alias processing, delegation traversal, retries and failover, caching, DNSSEC validation, etc. Many RFCs specify functional behavior but leave resource-relevant properties underspecified or inconsistently defined: which internal actions are counted toward a bound, whether and when counters reset, what defaults are safe, and what constitutes relevant data for resolvers to process. Over the past several years, a series of disclosures and research results have shown that _protocol-compliant but adversarially crafted authoritative zones and query/response patterns_ can drive disproportionate resource consumption during resolution, stressing DNS infrastructure. Examples include published attacks such as NXNSAttack [AFEK2020-NXNSATTACK], TsuNAME [MOURA2021-TSUNAME], KeyTrap [HEFTRIG2024-KEYTRAP], and CAMP [DUAN2024-CAMP]. The underlying amplification potential is largely inherent to DNS design: resolution may legitimately require multiple upstream transactions, may traverse delegation structures, may restart at aliases, and may validate cryptographic proofs, etc. Specification gaps and non-uniform guidance further increase this underlying complexity by making worst-case behavior harder to predict and by encouraging divergent accounting and limit choices across implementations. This document addresses this class of availability vulnerability, referred to here as *work amplification*. A work-amplification vulnerability allows an attacker to trigger disproportionate resource consumption —- such as outbound resolver queries, on-wire bytes, CPU, or resolver state —- during the processing of a single client query (i.e., one resolution instance). In this document, _work_ is the resources consumed while processing one resolution instance and is treated as a vector of resource dimensions (Section 4). Work amplification differs from classic _traffic reflection and amplification_ attacks. Reflection primarily amplifies on-wire bytes delivered to an external victim and typically relies on source-address spoofing; mitigations such as anti-spoofing and response rate limiting address that threat. Work amplification primarily stresses DNS components and nearby infrastructure by amplifying their internal work (e.g., query load, validation CPU, and per-transaction state), and can be effective even without spoofing. Reflection mitigations are therefore insufficient on their own; bounding work requires explicit budgets, accounting rules, and Duan, et al. Expires 2 January 2027 [Page 3] Internet-Draft DNS Work Amplification July 2026 operational anomaly handling. This document is complementary to existing BCP guidance for reflection mitigation (e.g., [BCP38], [BCP84], and [BCP140]). The goals of this document are: * to define a terminology for discussing DNS work amplification, including the notions of resolution instance, resolver query, work budget, and budget exhaustion; * to develop a two-axis taxonomy of work-amplification vulnerabilities along resource and mechanism dimensions; and * to identify where existing DNS specifications leave amplification-relevant behavior (such as bounding, accounting, and safe defaults) underspecified, without prescribing remedies. Protocol fixes and operational mitigation guidance are out of scope for this document. Those topics are addressed in the companion document draft-dnsop-work-amplification-bcp. This document does not attempt to catalogue implementation bugs that rely on malformed packets or memory corruption. Those issues are important, but they are orthogonal to the protocol-level behaviors considered here. 2. Terminology Unless otherwise noted, the terms in this section are used in the sense described in [RFC9499]. * *Client query:* A DNS query received by a resolver from a stub resolver or other downstream client. * *Resolver:* A DNS component that performs resolution on behalf of a client query. This includes full recursive resolvers and forwarders that themselves perform recursion. * *Authoritative server:* A DNS server that is authoritative for at least one zone and answers queries for names within that zone. * *Resolution instance:* The entire resolution process undertaken by a resolver in response to a single client query. A resolution instance encompasses all resolver queries, alias-induced restarts, delegation traversal steps, auxiliary lookups (e.g., nameserver address fetches and DNSSEC chain construction), retries, and transport fallback operations. Duan, et al. Expires 2 January 2027 [Page 4] Internet-Draft DNS Work Amplification July 2026 A resolver can _coalesce_ multiple identical client queries (including client retransmissions) onto a single in-flight resolution instance; in that case the work budget applies to the shared instance. * *Resolver query:* A DNS query emitted by a resolver to another resolver or authoritative server during a resolution instance. This includes queries for nameserver addresses (A/AAAA), DNSKEY/DS/NSEC* records, and any queries triggered by extension processing. Retransmissions and retries are counted as separate resolver queries. * *Restart:* The act of continuing a resolution instance for the _same client query_ while changing the current target name due to alias processing (e.g., following a CNAME or DNAME). In RFC 1034 terms, this corresponds to the resolver algorithm's alias handling: substituting a new name for the current name being resolved and re-entering the search procedure at the new target name. The resolver can reuse cached state across restarts, but each restart represents additional work that is accounted for. * *Delegation step:* A transition within a resolution instance where the resolver processes a referral at a zone cut and updates its candidate authoritative server set for a child zone. In RFC 1034 terms, this corresponds to processing an NS RRset and updating the resolver's list of candidate servers ("SLIST") for the next zone cut. Each delegation step represents additional work that is accounted for. * *Work budget:* A per-resolution-instance set of counters that collectively bound the amount of work the resolver performs. * *Budget exhaustion:* The event that occurs when *any* work-budget counter reaches its configured limit. When budget exhaustion occurs, the resolver stops expanding the resolution instance. The resolver typically returns an appropriate error to the client (typically SERVFAIL); under severe overload, a resolver may shed load by dropping responses. * *Max-work event:* A client query and associated upstream response pattern that causes a resolver to exhaust its work budget under the configured limits. * *Work-amplification vulnerability:* A protocol behavior or feature interaction that allows an attacker, via protocol-compliant authoritative data and/or query patterns, to cause disproportionate resource consumption (queries, bytes, CPU, or state) while processing a single client query. Amplification Duan, et al. Expires 2 January 2027 [Page 5] Internet-Draft DNS Work Amplification July 2026 potential is often exacerbated when specifications omit, loosen, or inconsistently define the bounds and accounting rules needed to make worst-case behavior predictable. 3. Threat Model Work amplification becomes exploitable when an adversary can both (1) influence the authoritative data and server behaviors consulted during a resolution instance so that a resolver following protocol rules performs unusually large work, and (2) trigger resolution instances that exercise those behaviors at one or more target resolvers. Accordingly, this document assumes an attacker with the following core capabilities: * *Adversarial authoritative inputs:* the attacker can publish and serve protocol-compliant DNS data for one or more zones and can choose response behaviors that remain within protocol syntax. This includes crafting delegations, aliases, glue (or the absence of glue), DNSSEC material, and record sets that induce additional dependency lookups. It also includes response patterns that influence resolver control flow (e.g., selective omission of optional data, returning referrals, and controlled use of truncation) while remaining syntactically valid. * *Triggering resolution:* the attacker can cause client queries to be sent to one or more target resolvers for names whose resolution depends on the adversarial inputs. This may be achieved by sending queries directly, embedding attacker-controlled names in web resources or email, or leveraging clients that use the target resolvers. Some amplification vectors can also be triggered by querying existing misconfigured zones; attacker-controlled zones make worst-case behavior reliable and repeatable. Depending on the scenario, the attacker may additionally have: * *Distributed clients:* enough sources to sustain a desired request rate or to evade per-client limits. * *Multiple cooperating authoritative servers/zones:* the ability to spread an amplification pattern across multiple zones or servers, which can bypass some per-upstream operational limits. Duan, et al. Expires 2 January 2027 [Page 6] Internet-Draft DNS Work Amplification July 2026 * *Source-address spoofing:* while not required for work amplification, spoofing can hinder attribution and can bypass some per-client defences in deployments where spoofing remains possible. Work amplification can be exacerbated by packet loss and delay (benign or adversarial), because retries and failover can amplify work. This document does not assume an on-path adversary; on-path manipulation is out of scope except insofar as it resembles loss/ delay that a resolver may experience in normal operation. Off-path side-channel attacks against DNS resolution (e.g., SAD DNS [MAN2020-SADDNS]) are out of scope as an independent threat, but amplified resolution work can compose with such side channels by enlarging the observable surface (more queries, retries, and state transitions) that off-path observers can probe. 3.1. Potential Victims Depending on the attack construction, different DNS components can be the _primary_ victim (the component whose resources are intentionally exhausted). Other components may act as _amplifiers_ or experience collateral damage. This document distinguishes the following common victim roles: * *Target resolver (primary victim):* a recursive or forwarding resolver is directly targeted. The attacker sends client queries that cause the resolver to consume disproportionate CPU (including DNSSEC validation), recursion state, cache resources, and/or outbound query capacity. * *Target authoritative server (primary victim):* an authoritative server is targeted by inducing many resolvers to generate amplified resolver queries toward it. The attacker typically uses attacker-controlled authoritative infrastructure to publish an amplification pattern that requires resolvers to fetch many dependencies (e.g., nameserver-address lookups) from the victim. * *Uninvolved third-party server (primary victim):* a server that is not under the attacker’s control and not otherwise part of the intended resolution can become the primary victim if resolvers are induced to direct dependency lookups to it by name (e.g., NS targets under the victim’s zone) or by address (e.g., glue addresses pointing at the victim). The victim is often an authoritative server but can also be any DNS-speaking service reachable at the induced address. Duan, et al. Expires 2 January 2027 [Page 7] Internet-Draft DNS Work Amplification July 2026 * *Adjacent infrastructure and clients (collateral victims):* work amplification can saturate links, overload stateful middleboxes (e.g., NATs, firewalls, load balancers), increase latency, and cause budget-exhaustion errors for benign clients. The most common primary targets are resolvers that perform the amplified resolution work and authoritative servers that receive the resulting amplified resolver queries. In these cases, we refer to the attack as self-amplification. This distinguishes the attack from conventional reflective amplification, where third-party servers send amplified responses to a spoofed victim address. 3.2. Example Attack Scenarios The taxonomy in Section 4 abstracts attacks into resource and mechanism categories. This section provides non-exhaustive end-to-end scenarios, organised by the primary victim role (Section 3.1). Many scenarios have secondary victims (e.g., authoritative servers receive expanded queries). 1. *Target resolver (resolver as primary victim).* An attacker operates one or more authoritative zones and publishes well-formed content that forces a resolver into expensive control flow. By inducing clients to resolve names in those zones (or querying directly), the attacker causes the target resolver to follow alias chains, traverse multiple delegations, perform QNAME-minimisation probes, fetch nameserver addresses, and validate DNSSEC material. The resolver expands the resolution instance until the configured work budgets are exhausted, degrading service for other clients. 2. *Target authoritative server (authoritative as primary victim).* An attacker publishes a delegation in an attacker-controlled zone whose NS targets are names under the victim authoritative server’s zone (e.g., ns1.victim.example, ns2.victim.example, ...), with little or no glue. The attacker then sends initiating client queries to many resolvers. Each resolver must resolve the NS target names to addresses, sending many A/AAAA resolver queries to the victim authoritative server. Aggregated across many resolvers, the victim receives amplified query load that is disproportionate to the attacker’s initiating traffic. 3. *Uninvolved third-party server and infrastructure stress.* This scenario resembles Scenario 2, but the amplified dependency traffic is directed at an external victim that is not authoritative for the attacker’s zone. The attacker induces resolvers to send dependency traffic to a victim that is not under the attacker’s control, for example by providing Duan, et al. Expires 2 January 2027 [Page 8] Internet-Draft DNS Work Amplification July 2026 in-bailiwick glue that points to a victim IP address or by referencing many random names under a victim zone. The induced traffic can overload the victim server even though its responses do not influence the attacker- controlled zone’s correctness. When combined with loss or delay, retries, failover, and transport fallback can further increase outbound queries, wire bytes, and connection state, stressing links and stateful devices along the path. 4. Taxonomy of Work-Amplification Vulnerabilities This section defines the two-axis classification used throughout this document. Each vulnerability is labelled with one or more *resource amplification labels* and *mechanism labels* as defined below. By separating _what_ resource is amplified from _how_ it is amplified, we avoid overlapping categories and provide a stable basis for both protocol clarifications and operational mitigations. 4.1. Scope and Limitations of the Taxonomy The two axes are intended to be orthogonal: the resource axis (R) describes _what_ resource is amplified, while the mechanism axis (M) describes _how_ amplification is induced. Because the same mechanism can amplify multiple resources (for example, delegation traversal can drive both resolver queries and wire bytes), individual vulnerabilities are typically labelled with a non-empty subset of each axis. Treating the two axes independently keeps the categories non-overlapping at the axis level even when individual labels co- occur in concrete attacks. The label sets in the following two subsections are not claimed to be exhaustive. An issue is included when it has been observed in deployed resolver behavior, demonstrated in published research, or discussed in prior IETF or operational work; emerging mechanisms and unobserved compositions are likely to require additional labels in future revisions. The taxonomy is descriptive, not prescriptive: the goal is to give readers a stable vocabulary for discussing work- amplification vulnerabilities rather than to enumerate every possible vector. 4.2. Resource Amplification Labels * *R1 - Resolver-query amplification:* A client query triggers an excessive number of resolver queries during a resolution instance, including nameserver-address lookups, DNSSEC-related lookups, and transport retries. R1 covers both the count of resolver queries and the concurrency of outstanding resolver queries. Duan, et al. Expires 2 January 2027 [Page 9] Internet-Draft DNS Work Amplification July 2026 * *R2 - Wire bytes amplification:* A client query results in disproportionate bytes on the wire, either upstream (resolver to authoritative) or downstream (authoritative to resolver or resolver to client). Examples include responses with large RRsets, many RRsets, repeated retries and TCP fallback due to truncation. * *R3 - Computation amplification:* The amount of CPU or wall-clock time spent by the resolver is disproportionately high. Parsing large responses, following complex rewrite patterns and cryptographic DNSSEC validations drive R3. * *R4 - State amplification:* A query causes the resolver to allocate disproportionate in-memory state—either per-resolution structures (e.g., per-instance dependency tracking) or longer- lived cache state. R4 often accompanies R1-R3 when large numbers of RRsets are processed or stored. NOTE: R1 and R2 are intentionally distinct axes. Many attacks amplify both, but they can occur independently: a single oversized response can trigger R2 without many resolver queries, while many small resolver queries (e.g., for dependencies) can trigger R1 without large responses. Implementations typically account for both dimensions. 4.3. Mechanism Labels * *M1 - Alias and restart semantics:* Amplification enabled by aliasing and restart behavior. CNAME and DNAME chains can trigger multiple restarts. Common underspecified aspects include limits on chain length, loop detection, and how work budgets are applied across restarts. * *M2 - Delegation traversal and nameserver discovery:* Issues arising from delegation and referral processing. Examples include glueless referrals, out-of-bailiwick nameserver names, and deep or cyclic delegation structures. Missing limits on delegation depth or the number of nameserver addresses to fetch contribute directly to amplification. This label also covers query-name probing behavior during delegation traversal, such as QNAME minimisation ([RFC9156]), which can increase resolver queries for deep names if not bounded. * *M3 - Server selection, retries and concurrency:* Amplification from query retry and failover logic. Underspecified retry limits and concurrency policies can cause explosive growth in outstanding queries when resolvers attempt to contact multiple servers or fall back to other transports or protocols. Duan, et al. Expires 2 January 2027 [Page 10] Internet-Draft DNS Work Amplification July 2026 * *M4 - Response content multiplicity and section semantics:* Amplification enabled by large or numerous RRsets and by the handling of response sections (answer, authority, additional). Large RRsets, many RRsets, or records with many RDATA entries can inflate parsing, validation, and caching work. * *M5 - DNSSEC validation and proof semantics:* DNSSEC introduces additional queries (to fetch DNSKEY and DS RRsets) and cryptographic validation work. Underspecified aspects include whether DNSSEC queries count toward budgets, limits on cryptographic verification work, and bounding NSEC3 parameters and candidate key sets to mitigate algorithmic-complexity DNSSEC attacks. * *M6 - Cache admission, relevance and maintenance:* The rules governing what a resolver may cache, for how long, and when to evict entries are only partially defined. Attackers can fill caches with irrelevant or malicious records, causing memory exhaustion or eviction of useful data. Negative caching and bailiwick rules are also relevant here. * *M7 - Extension-induced secondary resolution:* New DNS extensions sometimes implicitly trigger additional lookups or state (for example, records that reference additional names that must be resolved, or transport and discovery mechanisms that initiate extra exchanges). If resource bounds are not clearly specified, these features can open new work-amplification vectors. Each vulnerability analysed in Section 5 is annotated with one or more resource and mechanism labels along with typical victims and preconditions. This labelling enables readers to map specification ambiguities to corresponding resource budgets and to determine which mitigations are most appropriate. 4.4. Example Mapping of Known Attacks This subsection provides an _informative_ mapping from a few well- known work-amplification attacks to the taxonomy in this document. The mapping is illustrative rather than exhaustive; individual attacks often have variants that exercise additional mechanisms. Duan, et al. Expires 2 January 2027 [Page 11] Internet-Draft DNS Work Amplification July 2026 +===========================+=================+==================+ | Attack (informative name) | Typical | Typical | | | resource labels | mechanism labels | +===========================+=================+==================+ | NXNSAttack | R1, R2 | M2, M3 | +---------------------------+-----------------+------------------+ | TsuNAME | R1 | M1, M2 | +---------------------------+-----------------+------------------+ | KeyTrap | R3 | M5 | +---------------------------+-----------------+------------------+ | CAMP | R1-4 | M1-4 | +---------------------------+-----------------+------------------+ Table 1 5. Analysis of Amplification Vectors and Specification Enablers This section connects the taxonomy in Section 4 to existing DNS specifications. Work amplification is often inherent to DNS design: recursive resolution deliberately combines delegation traversal, alias following, caching, retries, transport fallback, and (in many deployments) DNSSEC validation. Those mechanisms can legitimately require substantial work in some cases. The focus here is narrower: it identifies where _specification text and non-uniform guidance_ can make worst-case work harder to predict and harder to bound, and therefore make implementation and operational mitigations less systematic. Concretely, this section highlights places where RFCs: * do not clearly identify which work needs to be bounded for a single client query; * do not define what counts toward those bounds, or when counters reset; * do not provide (or align on) safe default limits; or * introduce feature interactions that change work without calling out the associated bounding and accounting implications. 5.1. Conventions for RFC References in this Section DNS behavior relevant to work amplification is specified across a large set of RFCs, and relevant text is often scattered. Reproducing all relevant material verbatim would be both impractical and potentially misleading without the original context. Duan, et al. Expires 2 January 2027 [Page 12] Internet-Draft DNS Work Amplification July 2026 For each issue below, this document therefore provides two reference lists: * *Primary normative anchors (complete within scope):* the RFC sections that most directly define the base protocol behavior for the issue. These are the first places implementers and reviewers should consult. * *Additional related documents (non-exhaustive):* other RFCs, BCPs, and active Internet-Drafts that refine the behavior, introduce related mechanisms, or provide operational guidance. Each issue discussion then explains (a) what the anchor text requires, (b) what is left to implementation or local policy, and (c) how that leeway can exacerbate the amplification vectors in Section 4. 5.2. Selection and Structure of Issues An issue (A-*) is included in this section when published specification text leaves leeway in bounding, accounting, or safe defaults that directly enables one or more of the resource and mechanism vectors catalogued in Section 4. Issues that arise solely from implementation defects (e.g., bugs in parsing or memory handling) are excluded; the focus is on specification-level ambiguity that propagates predictably across conformant implementations. The issues are grouped to mirror the mechanism axis (M1-M7) of the taxonomy: A-1 covers the cross-cutting work-budget framing, while A-2 through A-8 align with the alias, delegation, retry, response- content, DNSSEC, caching, and extension mechanisms respectively. This grouping lets readers move between an attack's mechanism labels and the specification anchors most relevant to clarifying it. The list of issues is not claimed to be exhaustive. As with the label sets in Section 4, additional issues are likely to be identified as new DNS extensions are deployed and as further work- amplification research is published; the issues here are the ones for which sufficient deployment or research evidence currently exists to motivate inclusion. 5.3. Work budgeting and accounting *Issue identifier:* A-1 *Primary normative anchors (complete within scope):* Duan, et al. Expires 2 January 2027 [Page 13] Internet-Draft DNS Work Amplification July 2026 * [RFC1034] §5.3.3 — describes the resolver top-level algorithm and notes that resolvers should bound the work performed for a single request, but does not formalise a complete accounting model. * [RFC1035] §7.1-§7.2 — sketch resolver implementation considerations, including a per-request work counter (§7.1) and query sending, server selection, and retry handling (§7.2), while leaving most accounting choices to implementations. *Additional related documents (non-exhaustive):* [RFC2181] (RRset handling and ranking), [RFC2308] (negative caching), [RFC4033]-[RFC4035] (DNSSEC), [RFC5155] and [RFC9276] (NSEC3 and operational guidance), [RFC7766] (DNS over TCP), [RFC8198] (aggressive use of DNSSEC-validated cache), [RFC8767] (serve-stale), [RFC9156] (QNAME minimisation), and [I-D.fujiwara-dnsop-dns-upper-limit-values] (upper-limit values). *What is specified:* The base DNS specifications ([RFC1034] §5.3.3 and [RFC1035] §7.1-§7.2) acknowledge that resolvers must place bounds on the work performed on behalf of a client query and sketch one approach (e.g., a per-request counter). They also define multiple mechanisms that can legitimately trigger additional resolver queries and processing. *What is left to implementation or policy:* The base specifications do not define a concrete _accounting model_ for work, including: * which internal actions are charged to the same budget as the client query (e.g., nameserver address discovery, DNSSEC validation fetches, retries and failover, transport fallback, QNAME-minimisation probes); * whether and when counters reset (e.g., on alias-induced restarts); * whether independent limits compose safely (e.g., separate limits for restarts, depth, and outstanding queries without an overall envelope); and * what safe defaults are for modern resolver deployments. These choices materially affect worst-case work and therefore vary across implementations. *Work-amplification relevance:* Duan, et al. Expires 2 January 2027 [Page 14] Internet-Draft DNS Work Amplification July 2026 When budgets are incomplete or inconsistently applied, an attacker can force expensive combinations of mechanisms (e.g., restarts * delegation traversal * retries * validation), increasing R1-R4 and enabling M1-M7. 5.4. Alias processing and restart logic *Issue identifier:* A-2 *Primary normative anchors (complete within scope):* * [RFC1034] §3.6.2 and §5.3.3 — describe CNAME processing and the resolver-algorithm restart step, but do not bound chain length or loop-handling work as part of a single client query's budget. * [RFC1035] §3.3.1 — defines CNAME RR semantics without specifying resolver-side restart accounting. * [RFC6672] §3 — defines DNAME substitution semantics and CNAME synthesis without specifying combined alias-chain bounds. *Additional related documents (non-exhaustive):* [RFC2181] (clarifications), [RFC8020] (NXDOMAIN termination under empty non-terminals), and resolver-implementation guidance and limits such as [I-D.fujiwara-dnsop-dns-upper-limit-values]. *What is specified:* Alias records (CNAME and DNAME) intentionally redirect resolution and can cause the resolver to restart its search for a different name while still answering the original client query. *What is left to implementation or policy:* Specifications do not provide consistent, protocol-level guidance on: * bounding alias chain length and alias-induced restarts _as part of_ a single client query’s work; * detecting and handling alias loops across administrative boundaries; * how restarts interact with other bounds (depth, outstanding queries, timeouts); and * whether partial state can be reused safely across restarts (which in practice affects whether work is repeated). Duan, et al. Expires 2 January 2027 [Page 15] Internet-Draft DNS Work Amplification July 2026 *Work-amplification relevance:* Alias chains and loops can multiply resolver queries (R1) and state tracking (R4), and can be composed with delegation traversal (M2) and retries (M3). Ambiguous or non-uniform restart accounting can make these worst cases larger. Cyclic CNAME and NS dependencies, as in the TsuNAME phenomenon [MOURA2021-TSUNAME], illustrate how alias and delegation interactions in deployed zones can amplify queries to authoritative servers. 5.5. Delegation traversal and nameserver discovery *Issue identifier:* A-3 *Primary normative anchors (complete within scope):* * [RFC1034] §4.3 and §5.3.3 — describe the delegation model and iterative search, including nameserver-address discovery, but do not bound dependent-lookup fan-out per client query. * [RFC1035] §3.3.11 (NS RR semantics) and §4.1 (message sections) — define the on-wire encoding of referrals and additional-section glue without prescribing resolver-side admission or fetch limits. * [RFC2181] §5.4.1 and §6 — clarify RRset ranking, zone cuts, and glue handling, but leave out-of-bailiwick and missing-glue policy to resolver implementations. *Additional related documents (non-exhaustive):* [RFC9156] (QNAME minimisation) and operational guidance on bailiwick and glue handling (e.g., [RFC2181] and DNSOP operational documents). *What is specified:* Delegation traversal is fundamental to DNS. Referrals provide NS RRsets, and resolvers may need to obtain IP addresses for nameservers (via glue or by resolving nameserver names). *What is left to implementation or policy:* Specifications leave substantial leeway that affects worst-case work, including: * how aggressively to pursue nameserver address discovery when glue is missing or inconsistent (including out-of-bailiwick and cyclic cases); Duan, et al. Expires 2 January 2027 [Page 16] Internet-Draft DNS Work Amplification July 2026 * how to bound and account for the resulting dependent lookups as part of the client query's budget; * how to bound "fan-out" across multiple nameservers and multiple referral steps; and * how QNAME minimisation changes the number and structure of delegation queries, and how those extra queries are bounded and coalesced. *Work-amplification relevance:* Delegation traversal and nameserver discovery are a primary source of resolver-query fan-out (R1) and wire bytes (R2) and interact strongly with restarts (M1) and retries/failover (M3). NXNSAttack [AFEK2020-NXNSATTACK] is a concrete instance of this fan-out, in which glueless delegations to many nameserver names force resolvers to issue dependent A/AAAA queries. Such delegation fan-out can compose with alias restarts (M1), retries (M3), and DNSSEC validation (M5) to reach high query counts per client query. 5.6. Retry, failover and concurrency *Issue identifier:* A-4 *Primary normative anchors (complete within scope):* * [RFC1034] §5.3.3 — describes server selection and the resolver's behavior after timeouts in the iterative algorithm, but does not prescribe concrete concurrency or retry budgets. * [RFC1035] §7.2 — provides resolver implementation considerations including request retry handling, while leaving timing, fan-out, and failover policy to implementations. *Additional related documents (non-exhaustive):* [RFC7766] (DNS over TCP). *What is specified:* Resolvers retry queries on timeouts and may query multiple servers for robustness ([RFC1034] §5.3.3 and [RFC1035] §7.2). Modern resolvers also implement parallelism for performance and transport fallback (e.g., UDP to TCP). *What is left to implementation or policy:* Duan, et al. Expires 2 January 2027 [Page 17] Internet-Draft DNS Work Amplification July 2026 Specifications do not define interoperable guidance for: * concurrency limits (outstanding resolver queries) as part of a per-query budget; * retry timing, backoff, and failover policies under adversarial load; * whether and how to coalesce identical in-flight work across multiple client queries; and * how to bound transport fallback behavior (e.g., repeated TCP fallback to unresponsive servers). *Work-amplification relevance:* Retry and failover logic can turn loss, delay, or adversarial response patterns into additional resolver queries (R1) and state (R4). Under stress, naive retry policies can also cause "query storms" that amplify impact on upstream authoritative infrastructure. 5.7. Response content and section semantics *Issue identifier:* A-5 *Primary normative anchors (complete within scope):* * [RFC1035] §4.1-§4.2 — define DNS message format and the semantics of Question, Answer, Authority, and Additional sections, but do not bound per-response processing work. * [RFC2181] §5.4.1 — defines RRset ranking and credibility rules but leaves cache-admission limits to implementations. * [RFC2181] §6 — clarifies zone cuts and glue handling without bounding admission of large or repeated additional-section data. *Additional related documents (non-exhaustive):* [RFC6891] (EDNS(0)), [RFC8482] (minimal ANY responses), [RFC7766] (TCP fallback), and DNSOP guidance on response minimisation and truncation behavior. *What is specified:* Duan, et al. Expires 2 January 2027 [Page 18] Internet-Draft DNS Work Amplification July 2026 DNS messages have Answer, Authority, and Additional sections ([RFC1035] §4.1-§4.2), and specifications describe how resolvers interpret and cache data from those sections, including glue handling and basic credibility rules ([RFC2181] §5.4.1 and §6). *What is left to implementation or policy:* Specifications do not provide consistent guidance on: * bounding the amount of processing for large but well-formed responses (record multiplicity, section size, name compression effects); * which kinds of Additional or Authority data are "relevant enough" to admit into cache or to act upon during the current resolution; * how to treat repeated or inconsistent data across multiple responses in the same resolution instance; and * how EDNS(0) buffer sizes and response truncation interact with query retry and TCP fallback budgets. *Work-amplification relevance:* Large responses and permissive acceptance rules increase bytes processed and stored (R2/R4) and can induce additional follow-up work (M4/M6), especially when combined with caching behavior. 5.8. DNSSEC validation and proof semantics *Issue identifier:* A-6 *Primary normative anchors (complete within scope):* * [RFC4033] §3, [RFC4034] §2 (DNSKEY), §3 (RRSIG), and §5 (DS), and [RFC4035] §5 — define the DNSSEC trust model and the validator's chain-of-trust construction, which drives additional fetches and cryptographic work without bounding per-query validation cost. * [RFC5155] §5 and §10.3 — define NSEC3 hash calculation and the iteration-count guidance that together determine validation cost. * [RFC9276] — provides operational guidance for NSEC3 iteration counts but does not normatively bound per-query validation work. *Additional related documents (non-exhaustive):* Duan, et al. Expires 2 January 2027 [Page 19] Internet-Draft DNS Work Amplification July 2026 [RFC6840] (DNSSEC operational practices), [RFC8198] (aggressive use of DNSSEC-validated cache), and documents describing algorithmic complexity attacks against DNSSEC validation (informative). *What is specified:* Validating resolvers ([RFC4035] §5) perform additional fetches (e.g., DNSKEY/DS/NSEC*) and cryptographic work (e.g., RRSIG verification) to establish authenticity and denial of existence. *What is left to implementation or policy:* DNSSEC specifications and operational guidance do not fully align on: * how much validation work is acceptable per client query and how to account for it in a unified budget; * safe default bounds for attacker-controlled parameters (e.g., number of candidate keys, signature multiplicity, and NSEC3 iteration cost); and * how validation work interacts with caching (including whether expensive intermediate results are cached and reused). *Work-amplification relevance:* DNSSEC validation can dominate CPU work (R3) and can drive additional resolver queries (R1). Key-set amplification, key-tag collision, and expensive denial-of-existence proofs are examples of M5-style vectors; KeyTrap [HEFTRIG2024-KEYTRAP] illustrates the algorithmic-complexity dimension of M5. 5.9. Cache admission, relevance and maintenance *Issue identifier:* A-7 *Primary normative anchors (complete within scope):* * [RFC2181] §5.4.1-§5.4.2 — define RRset credibility ranking and ordering rules used during cache admission, but leave admission limits and replacement policy to implementations. * [RFC2308] §3 and §5 — define negative caching of name and type errors, without prescribing detailed eviction or replacement policy. *Additional related documents (non-exhaustive):* Duan, et al. Expires 2 January 2027 [Page 20] Internet-Draft DNS Work Amplification July 2026 [RFC1034] (caching discussion), [RFC8198] (aggressive use), [RFC8767] (serve-stale), and operational guidance on cache sizing and eviction behavior. *What is specified:* Caching is fundamental for performance. RFCs ([RFC2181] §5.4.1-§5.4.2 and [RFC2308] §3, §5) describe credibility and negative caching and leave detailed cache policy (admission, eviction, replacement) to implementations. *What is left to implementation or policy:* Specifications do not normatively define: * what constitutes _relevant data to process and cache_ for a given response and recursion context (especially for Additional-section data); * limits on cache insertion work per response (e.g., record multiplicity across names and types); * how to account for cache maintenance work (eviction, replacement, memory pressure) in the presence of adversarially crafted names; and * how to prevent attacker-controlled names from forcing repeated cache misses (e.g., via cache flooding and eviction attacks). *Work-amplification relevance:* Cache admission and maintenance affect state and memory (R4) and can turn a small number of adversarial responses into sustained work via repeated misses, churn, and eviction overhead (M6/M7). 5.10. Extension-induced secondary resolution In this document, an *extension* (in the A-8 sense) is a DNS mechanism that induces additional outgoing resolver queries _beyond the direct resolution path_. Examples include HTTPS/SVCB target resolution (where processing a record triggers follow-up lookups for the target name) and custom EDNS options or new RR types whose processing triggers secondary lookups. Core resolution mechanisms that already have a dedicated issue are explicitly out of A-8 scope: CNAME/DNAME chasing is discussed under A-2 (alias processing), delegation traversal — including glueless referrals and nameserver fan-out — is discussed under A-3, and DNSSEC chain-of-trust construction (including RRSIG/DS fetches) is discussed under A-6. Duan, et al. Expires 2 January 2027 [Page 21] Internet-Draft DNS Work Amplification July 2026 A-8 concerns the _additional_ work an extension introduces on top of those core mechanisms. *Issue identifier:* A-8 *Primary normative anchors (complete within scope):* * [RFC6891] §6 — defines the EDNS(0) OPT pseudo-RR and option-code framework that extension specifications use, but does not bound the work induced by individual options. *Additional related documents (non-exhaustive):* [RFC9460] (SVCB/HTTPS records), [RFC9156] (QNAME minimisation), [RFC8767] (serve-stale), [RFC7766] (TCP), and future DNSOP extension documents. *What is specified:* DNS has an extension culture: the EDNS(0) framework ([RFC6891] §6) and new RR types frequently add processing steps and sometimes require additional lookups or validation. *What is left to implementation or policy:* Extension specifications do not always make explicit: * whether a feature introduces additional resolver queries (including "secondary" resolutions triggered by record processing); * how those queries are charged to per-query budgets and concurrency limits; and * what safe defaults and failure modes are when those budgets are exhausted. *Work-amplification relevance:* Unaccounted extension-induced work can bypass otherwise effective bounds (M7), and can be composed with other mechanisms (e.g., SVCB/ HTTPS address fetches plus retries, or privacy probes plus delegation fan-out). Duan, et al. Expires 2 January 2027 [Page 22] Internet-Draft DNS Work Amplification July 2026 6. Security Considerations This entire document concerns security of the DNS against work-amplification attacks. By describing terminology, a taxonomy, and specification gaps that affect work amplification, this document aims to clarify the attack surface. Readers translating this analysis into mitigations face trade-offs: * Budget exhaustion may cause resolvers to return SERVFAIL for legitimate complex queries; tuning limits and monitoring for false positives involves trade-offs between security and availability. * Strict alias and delegation limits may break badly configured but non-malicious zones; correcting such configurations at the zone is generally preferable to weakening limits. * Per-upstream fairness and rate limiting may allow a malicious nameserver to consume its share of resolver resources while legitimate queries are slowed; fairness algorithms benefit from monitoring and adjustment. * Some mitigations, such as dropping large additional sections, may interfere with future legitimate protocols that rely on these sections. * Amplification can never be completely eliminated: an adversary can always consume some resolver resources by issuing queries. The goal is to make amplification predictable and bounded. 7. IANA Considerations This document has no IANA actions. It does not define any new DNS resource record types, EDNS options or protocol registries. 8. Privacy Considerations This document does not introduce any new mechanisms for collecting or processing personal data. It describes behaviors that affect resource consumption. The analysis does not reveal client identities or change privacy properties beyond those already inherent in the DNS. General DNS privacy guidance (e.g., QNAME minimisation and encrypted transports) is relevant when mitigations are deployed but is outside the scope of this document. 9. References 9.1. Normative References Duan, et al. Expires 2 January 2027 [Page 23] Internet-Draft DNS Work Amplification July 2026 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, . [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, . [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840, DOI 10.17487/RFC6840, February 2013, . Duan, et al. Expires 2 January 2027 [Page 24] Internet-Draft DNS Work Amplification July 2026 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, . [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, November 2016, . [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, July 2017, . [RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, "Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January 2019, . [RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC 9156, DOI 10.17487/RFC9156, November 2021, . [RFC9276] Hardaker, W. and V. Dukhovni, "Guidance for NSEC3 Parameter Settings", BCP 236, RFC 9276, DOI 10.17487/RFC9276, August 2022, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . 9.2. Informative References [AFEK2020-NXNSATTACK] Afek, Y., Bremler-Barr, A., and L. Shafir, "NXNSAttack: Recursive DNS Inefficiencies and Vulnerabilities", USENIX Security 2020, August 2020. [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000, . Duan, et al. Expires 2 January 2027 [Page 25] Internet-Draft DNS Work Amplification July 2026 [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004, . [BCP140] Abley, J. and W. Maton, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, October 2008, . [DUAN2024-CAMP] Duan, H., Bearzi, M., Vieli, J., Basin, D., Perrig, A., Liu, S., and B. Tellenbach, "CAMP: Compositional Amplification Attacks against DNS", USENIX Security 2024, 2024. [HEFTRIG2024-KEYTRAP] Heftrig, E., Schulmann, H., Vogel, N., and M. Waidner, "The Harder You Try, The Harder You Fail: The KeyTrap Denial-of-Service Algorithmic Complexity Attacks on DNSSEC", ACM CCS 2024, 2024. [I-D.fujiwara-dnsop-dns-upper-limit-values] Fujiwara, K. and Y. Thessalonikefs, "Upper limit values for DNS", Work in Progress, Internet-Draft, draft- fujiwara-dnsop-dns-upper-limit-values-05, 9 February 2026, . [MAN2020-SADDNS] Man, K., Qian, Z., Wang, X., Zheng, X., Huang, Y., and H. Duan, "DNS Cache Poisoning Attack Reloaded: Revolutions with Side Channels", ACM CCS 2020, November 2020. [MOURA2021-TSUNAME] Moura, G. C. M., "TsuNAME: The Impact of Misconfigured DNS Loops on Authoritative Name Servers", ACM IMC 2021, November 2021. [RFC8767] Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data to Improve DNS Resiliency", RFC 8767, DOI 10.17487/RFC8767, March 2020, . [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, . Duan, et al. Expires 2 January 2027 [Page 26] Internet-Draft DNS Work Amplification July 2026 [SP26-RPROF] Xu, L., Duan, H., Cai, Z., and A. Perrig, "Resolve the Unresolved: Systematic Work Profiling for DNS Resolvers", IEEE S&P 2026, 2026. Appendix A. Implementation Status This section is to be removed before publication as an RFC. Resolver implementations vary in their existing protections, such as maximum alias-chain length, maximum recursion depth, per-client rate limits, query coalescing, and DNSSEC validation limits. However, implementations differ in accounting (what counts toward which limit), in how limits interact with restarts, and in default values. Systematic work-profiling of deployed resolvers [SP26-RPROF] has begun to characterise this variation empirically and to surface worst-case work distributions that the per-implementation defaults above do not directly expose. This document does not currently track implementation conformance. A future revision may include an implementation report if such tracking is considered useful by the working group. Authors' Addresses Huayi Duan HKUST(GZ) No.1 Du Xue Rd, Nansha District Guangzhou 511453 China Email: huayiduan@hkust-gz.edu.cn Liwen Xu ETH Zurich Universitätstrasse 6 CH-8092 Zürich Switzerland Email: liwen.xu@inf.ethz.ch Adrian Perrig ETH Zurich Universitätstrasse 6 CH-8092 Zürich Switzerland Email: adrian.perrig@inf.ethz.ch Duan, et al. Expires 2 January 2027 [Page 27]