DNSOP Working Group J. Stenstam Internet-Draft The Swedish Internet Foundation Updates: 4035, 6840 (if approved) 12 June 2026 Intended status: Standards Track Expires: 14 December 2026 Algorithm-Split DNSSEC: KSK/ZSK Algorithm Separation with Bounded ZSK Cadence draft-johani-dnsop-dnssec-alg-split-00 Abstract Post-quantum DNSSEC signature algorithms have much larger keys and/or signatures than the elliptic-curve algorithms in common use today. Signing an entire zone with such an algorithm inflates every signature in the zone. A natural transition strategy applies a large algorithm only to the key-signing key (KSK), which signs only the apex DNSKEY RRset, while the bulk of the zone continues to be signed with a smaller zone-signing key (ZSK). This document specifies the three changes that, taken together, make this pattern safe and practical: (1) it relaxes the DNSSEC signing rule that requires a zone to be signed with every algorithm present in the apex DNSKEY RRset, so that an algorithm used only by a key- signing key need not be applied to the rest of the zone; (2) it imposes a bounded ZSK rotation cadence as the security parameter that compensates for the asymmetric strength of the two algorithms; and (3) it specifies how a resolver can use the algorithm number in the parent's DS RRset to recognize a likely-oversized DNSKEY RRset and select a transport suitable for large responses, avoiding the truncate-then-retry round trip. The three parts are interdependent and constitute a single proposal. This document updates RFC 4035 and RFC 6840. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-johani-dnsop-dnssec-alg- split/. Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (mailto:dnsop@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dnsop/. Subscribe at https://www.ietf.org/mailman/listinfo/dnsop/. Stenstam Expires 14 December 2026 [Page 1] Internet-Draft Algorithm-Split DNSSEC June 2026 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 14 December 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. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Part 1: Distinct Algorithms for the KSK and the ZSK . . . . . 5 3.1. The Current Rule . . . . . . . . . . . . . . . . . . . . 5 3.2. The Change (Signer Side) . . . . . . . . . . . . . . . . 5 3.3. The Change (Validator Side) . . . . . . . . . . . . . . . 6 4. Part 2: Bounded ZSK Rotation Cadence . . . . . . . . . . . . 7 4.1. Why a Cadence Bound Is Required . . . . . . . . . . . . . 7 4.2. The Requirement . . . . . . . . . . . . . . . . . . . . . 8 4.3. The Parent's Signature on the Child DS Is Part of the Argument . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Part 3: DS Algorithm Number as a Size Signal for the DNSKEY RRset . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. The Truncation Round Trip . . . . . . . . . . . . . . . . 9 5.2. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 9 Stenstam Expires 14 December 2026 [Page 2] Internet-Draft Algorithm-Split DNSSEC June 2026 5.3. Identifying Large Algorithms . . . . . . . . . . . . . . 10 5.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 10 6. The Root Zone . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Root KSK . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Root ZSK . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Root ZSK Rotation Cadence . . . . . . . . . . . . . . . . 12 6.4. Transport for Root Queries . . . . . . . . . . . . . . . 12 7. Operational Considerations . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8.1. Why the Completeness Relaxation Is Safe . . . . . . . . . 13 8.2. Threat Model for the Transition . . . . . . . . . . . . . 14 8.3. Cross-Zone Dependency . . . . . . . . . . . . . . . . . . 15 8.4. Transport Signal . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction DNSSEC signature and key sizes are about to grow substantially. The post-quantum signature algorithms standardized by NIST -- ML-DSA [FIPS204] and SLH-DSA [FIPS205], with FN-DSA and others to follow -- have public keys and signatures that are one to two orders of magnitude larger than the elliptic-curve algorithms (ECDSA, Ed25519) in common use today. Signing an entire zone with such an algorithm inflates every RRSIG in the zone and every signed response. A natural transition strategy is to apply a large (for example, post- quantum) algorithm only where its cost is bounded -- the key-signing key (KSK), which signs only the apex DNSKEY RRset -- while continuing to sign the bulk of the zone with a smaller ZSK. The DNSKEY RRset is then the only large object in the zone; ordinary query responses remain small. Asymmetric key strength between the KSK and ZSK is already common operational practice. Operators routinely deploy RSA zones with a longer (i.e. stronger) KSK and a shorter ZSK, trading larger DNSKEY- RRset signatures for smaller signatures on the rest of the zone. The KSK/ZSK strength asymmetry proposed by this document is the same operational pattern; the only difference is that the asymmetry crosses the algorithm-number boundary rather than a key-length boundary within a single algorithm. It is that crossing -- not the strength asymmetry itself -- that interacts with the completeness rule of [RFC4035] and motivates the updates in this document. Stenstam Expires 14 December 2026 [Page 3] Internet-Draft Algorithm-Split DNSSEC June 2026 This document specifies three changes that together enable this deployment pattern: 1. Distinct algorithms for the KSK and the ZSK (Section 3). DNSSEC's current signing rules require a zone to be signed with every algorithm present in the apex DNSKEY RRset. This document relaxes that rule for an algorithm used solely by a key-signing key, so that a large KSK algorithm need not be applied to every RRset in the zone. 2. A bounded ZSK rotation cadence (Section 4). When the KSK and ZSK use different algorithms of different strengths, the security of the zone depends not on algorithmic completeness but on limiting the useful lifetime of any ZSK an adversary might break. This document requires the ZSK to be rolled at a cadence appropriate to the threat estimate against the ZSK algorithm, and expects that cadence to tighten over time. 3. Using the DS algorithm number to signal a large DNSKEY RRset (Section 5). Because the parent's DS RRset carries the child KSK's algorithm number, a resolver can recognize from the DS alone that the child's DNSKEY RRset is likely to exceed common UDP response-size limits, and query it over a transport suitable for large responses (TCP, DoT, DoQ, or another) directly -- avoiding a truncated UDP response and the consequent retry. The three parts are interdependent and constitute a single proposal. Part 1 makes the deployment pattern possible; part 2 is the security parameter that makes part 1 safe; part 3 makes the resulting transport profile efficient. Implementations that adopt only some of these changes either lose efficiency (omitting part 3) or weaken the security argument (omitting part 2). 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses "key-signing key" (KSK) and "zone-signing key" (ZSK) in the operational sense of [RFC6781]: a KSK is a key whose role is to sign the apex DNSKEY RRset and which is referenced by a DS record at the parent, while a ZSK signs the other RRsets of the zone. This KSK/ZSK distinction is operational; the DNSSEC protocol itself does not require it, and the Secure Entry Point (SEP) bit is advisory rather than normative. The normative conditions in this document do Stenstam Expires 14 December 2026 [Page 4] Internet-Draft Algorithm-Split DNSSEC June 2026 not rely on the SEP bit; instead, they are expressed in terms of the algorithms present in the parent DS RRset and the apex DNSKEY RRset (see Section 3). 3. Part 1: Distinct Algorithms for the KSK and the ZSK 3.1. The Current Rule Section 2.2 of [RFC4035], as restated in Section 5.11 of [RFC6840], governs which algorithms must be used to sign a zone. On the signer side: "The zone MUST also be signed with each algorithm (though not each key) present in the DNSKEY RRset." In other words, every RRset in the zone must carry a signature from each algorithm appearing in the apex DNSKEY RRset. If the apex DNSKEY RRset contains a large-algorithm KSK and a small- algorithm ZSK, this rule requires every RRset in the zone to carry a large-algorithm signature, which defeats the purpose of confining the large algorithm to the KSK. 3.2. The Change (Signer Side) This document updates the signer-side requirement of [RFC4035] and [RFC6840] as follows. A zone MAY be signed under the following _algorithm-split profile_. Let K be the set of algorithms appearing in the parent DS RRset for the zone, and let Z be a non-empty set of algorithms disjoint from K (K and Z share no algorithm). The profile holds when: * The apex DNSKEY RRset of the zone contains at least one key of each algorithm in K and at least one key of each algorithm in Z. * The apex DNSKEY RRset MUST be signed by every algorithm in K. It MAY additionally be signed by one or more algorithms in Z. * Every non-DNSKEY authoritative RRset in the zone MUST be signed by every algorithm in Z and MUST NOT be required to be signed by any algorithm in K. Within this profile, the algorithms in K play the role of KSK algorithms and the algorithms in Z play the role of ZSK algorithms. K and Z are disjoint by definition; no single algorithm can simultaneously serve as a KSK algorithm and a ZSK algorithm in this profile. The profile is defined entirely in terms of the contents of the parent DS RRset and the apex DNSKEY RRset, so that compliance can be checked without reference to the (advisory) SEP bit. Stenstam Expires 14 December 2026 [Page 5] Internet-Draft Algorithm-Split DNSSEC June 2026 The common steady-state case has |K| = |Z| = 1 (a single KSK algorithm A and a single ZSK algorithm B, with A != B). |K| > 1 corresponds to a KSK-algorithm rollover (the zone is transitioning between two KSK algorithms, both of which appear in the parent DS RRset and the apex DNSKEY RRset during the rollover window). |Z| > 1 corresponds to a ZSK-algorithm rollover (every non-DNSKEY RRset carries a signature from each old and new ZSK algorithm during the rollover window). A ZSK-algorithm rollover under this profile is no easier and no harder than the existing ZSK-algorithm rollover for an all-ZSK zone, and its size cost is the same. The profile is defined in terms of algorithm separation and strength asymmetry alone; it does not assume any particular character for either algorithm. In the most-discussed near-term deployment, the KSK algorithm is post-quantum and the ZSK algorithm is a classical elliptic-curve algorithm, but the profile applies equally when both KSK and ZSK algorithms are post-quantum -- in particular when the ZSK algorithm is a post-quantum scheme whose signatures are small enough to be acceptable on every RRset in the zone but whose long-term security margin is insufficient for a KSK that rolls slowly. As the set of standardized post-quantum signature algorithms grows, the profile is expected to admit an increasing range of ZSK choices whose strength against future cryptanalysis informs only the cadence requirement of Section 4, not the structural shape of the profile itself. A zone that does not match this profile remains subject to the existing completeness rule of [RFC4035] Section 2.2 and [RFC6840] Section 5.11. 3.3. The Change (Validator Side) This document also updates the validator-side behavior of [RFC4035] and [RFC6840]. When a validator processes a zone whose parent DS and apex DNSKEY RRsets match the algorithm-split profile of the preceding section, with KSK-algorithm set K and ZSK-algorithm set Z, the validator: * MUST validate the apex DNSKEY RRset using a signature of some algorithm in K (the algorithms present in the parent DS RRset), as required by the existing chain-of-trust rules. * MUST validate non-DNSKEY RRsets of the zone using signatures of some algorithm in Z. * MUST NOT treat the zone as Bogus solely because non-DNSKEY RRsets lack signatures of any algorithm in K. Stenstam Expires 14 December 2026 [Page 6] Internet-Draft Algorithm-Split DNSSEC June 2026 A validator that supports some algorithm in K but no algorithm in Z treats the zone as it would any zone whose data signatures are in an unsupported algorithm (see Section 5.2 of [RFC4035]). A validator that supports no algorithm in K treats the delegation as Insecure, as today. The validator-side update is essential. Without it, a strict reading of the existing completeness rules would cause a conforming validator to mark every algorithm-split zone as Bogus. Implementations that support this document MUST therefore implement the relaxation on both the signer and validator sides. 4. Part 2: Bounded ZSK Rotation Cadence 4.1. Why a Cadence Bound Is Required Under the algorithm-split profile of Section 3, the KSK and ZSK algorithms are not peers. For readability the rest of this section describes the steady-state case |K| = |Z| = 1 with KSK algorithm A and ZSK algorithm B; the argument extends directly to rollover windows where K or Z is larger, in which case every algorithm in K plays the role of A and every algorithm in Z plays the role of B. The KSK algorithm A and the ZSK algorithm B occupy distinct positions in a fixed chain of trust: 1. The parent DS RRset, validated by the parent's own chain of trust, authenticates the child's KSK (algorithm A). 2. The KSK signs the apex DNSKEY RRset, authenticating the ZSK (algorithm B) as key material. 3. The ZSK signs the non-DNSKEY RRsets of the zone. An adversary who breaks algorithm B can forge signatures that validate against a currently published ZSK, but cannot substitute a ZSK of their own choosing without forging an algorithm-A signature on the apex DNSKEY RRset. The adversary's forgery window is therefore bounded by the lifetime of any individual ZSK. This bound is what compensates for algorithm B being weaker than algorithm A. Without a normative bound on ZSK lifetime, this argument has no force: a long-lived ZSK gives a future adversary an unbounded opportunity to exploit a cryptanalytic advance against algorithm B. The completeness rule of [RFC4035] did not by itself prevent this scenario either -- [RFC6840] Section 5.11 permits a validator to validate using any single supported algorithm -- but it did make an algorithm-A signature available on every RRset, so a validator that Stenstam Expires 14 December 2026 [Page 7] Internet-Draft Algorithm-Split DNSSEC June 2026 supported A _could_ choose to require it. The algorithm-split profile of Section 3 removes that option: under the profile, non- DNSKEY RRsets carry only algorithm-B signatures, and no validator can fall back to A. An explicit cadence bound on B must take its place. 4.2. The Requirement A zone signed under the algorithm-split profile of Section 3 MUST roll its ZSK at a cadence T appropriate to the current threat estimate against algorithm B. T is intentionally not a fixed value in this document, because the appropriate value depends on cryptanalytic progress and on the deployment of cryptographically relevant quantum computers (CRQCs), neither of which can be predicted at the time of writing. The appropriate value of T is a matter of operator security policy. It is informed by external threat tracking -- for example, the post- quantum cryptanalysis guidance of the IETF (notably the Crypto Forum Research Group) and of national bodies such as NIST's post-quantum cryptography project -- rather than fixed by this document. Operationally, T is expressed as the ZSK effectivity period and realized using the established key-rollover machinery of [RFC6781] and the rollover-timing parameters of [RFC7583]; what the algorithm- split profile adds is only that this period is now a security parameter compensating for the strength asymmetry between algorithms A and B, not merely an operational-convenience interval as in [RFC6781]. As an initial guideline, operators of algorithm-split zones SHOULD begin with T no greater than one month, and SHOULD be prepared to reduce T to one week or less as threat estimates against algorithm B sharpen. Operators SHOULD treat T as a tunable policy parameter rather than a static configuration value. Signing implementations (including BIND, Knot, Cascade, and others) are expected to encode per-algorithm minimum cadences as policy and to refuse to operate a zone under the algorithm-split profile with a ZSK lifetime exceeding those minima. Such policies are out of scope for this document, which only requires that _some_ appropriate cadence be enforced. Stenstam Expires 14 December 2026 [Page 8] Internet-Draft Algorithm-Split DNSSEC June 2026 4.3. The Parent's Signature on the Child DS Is Part of the Argument The chain-of-trust argument in Section 4 assumes that the parent's DS RRset is authentic. That authenticity rests on the key with which the parent signs the child's DS RRset -- typically the parent's ZSK, though a parent operating with a CSK signs with that key instead. If an adversary can forge that signature, the adversary can substitute the child's DS, and thereby the child's KSK; the child's algorithm-A protection then provides no benefit. This is a general property of DNSSEC: a zone is no more trustworthy than the weakest link between it and the trust anchor. The relevant property of the parent is therefore the strength of the key signing the child DS RRset against the threat -- a function of both that key's algorithm and the cadence at which the parent rolls it. A parent that signs with a strong algorithm needs to roll only at the normal operational cadence; a parent that signs with a weaker algorithm needs to roll faster, to bound the window in which a future cryptanalytic break against that algorithm could be exploited. Either way, the obligation is on the parent's own configuration, independent of whether any particular child uses the algorithm-split profile. Section 6 discusses the special case of the root zone. 5. Part 3: DS Algorithm Number as a Size Signal for the DNSKEY RRset 5.1. The Truncation Round Trip When a resolver validates a delegation, it retrieves the child's DNSKEY RRset. If the KSK uses a large algorithm, the DNSKEY RRset together with its RRSIG commonly exceeds the EDNS(0) UDP response size that has become a de facto ceiling in much of the deployed base (frequently 1232 octets). A UDP query for such a DNSKEY RRset returns a truncated response with the TC bit set, and the resolver must repeat the query over a connection-oriented transport. This costs an extra round trip and a handshake on the first validation of the zone. 5.2. Resolver Behavior A resolver that has obtained a child's DS RRset MAY use the algorithm number(s) in that DS RRset to decide how to query the child DNSKEY RRset. If the resolver recognizes a DS algorithm as one whose keys and signatures are large enough that the DNSKEY RRset is likely to exceed its UDP response-size limit, the resolver SHOULD query the DNSKEY RRset directly over a transport it expects to handle a large response, rather than first attempting UDP and incurring a truncated response. Stenstam Expires 14 December 2026 [Page 9] Internet-Draft Algorithm-Split DNSSEC June 2026 This document deliberately does not name a specific transport. A resolver may use TCP, DNS-over-TLS, DNS-over-QUIC, or any other transport it considers suitable for large responses. The choice of transport is a local matter and is expected to evolve as the transport landscape evolves; this document defines the _signal_ but not the response to it. This is a local optimization. It changes neither the wire format nor the validation outcome. A resolver that does not implement it simply experiences the existing UDP-then-fallback behavior. 5.3. Identifying Large Algorithms To apply this signal a resolver needs to map an algorithm number to the property "the DNSKEY RRset is likely too large for UDP." A compiled-in default set of algorithm numbers that are classified as "large" is a reasonable starting point, and resolver implementations are expected to ship such a default reflecting the algorithms known at the time of release. A compiled-in default is not sufficient on its own. Until the set of post-quantum DNSSEC algorithms in operational use has stabilized -- a process that will include experimentation, including through the experimental algorithm range suggested by [I-D.johani-dnsop-dnssec-alg-experimental-range] -- resolver implementations SHOULD provide a configuration mechanism that allows the operator to override the compiled-in classification. 5.4. Limitations The DS algorithm number reflects the KSK algorithm only. The signal is reliable when the KSK is the large component of the DNSKEY RRset, which is exactly the deployment of Section 3. If a zone instead paired a small KSK algorithm with a large ZSK algorithm, the DNSKEY RRset could still be large while the DS signaled a small algorithm; the signal would be a false negative and the resolver would fall back to the existing UDP-then-fallback behavior. A false positive (treating a small DNSKEY RRset as large) causes only an unnecessary use of a large-capable transport and never affects correctness. Stenstam Expires 14 December 2026 [Page 10] Internet-Draft Algorithm-Split DNSSEC June 2026 6. The Root Zone The root zone is the most exposed zone in DNSSEC: its KSK is a trust anchor for the entire namespace, and its ZSK signs the DS RRsets of every TLD. The mechanisms of this document apply to the root zone with particular force. This section is a worked example: it illustrates how Section 3, Section 4, and Section 5 apply at the root, and recommends a deployment profile. The normative requirements of Section 3 and Section 4 continue to apply; the recommendations in this section are non-normative, with the exception of the resolver-transport recommendation in Section 6.4, which restates a SHOULD applicable to resolvers generally. 6.1. Root KSK The root KSK SHOULD use a post-quantum algorithm with conservative security properties. Hash-based signature schemes such as those of [FIPS205] are well-suited to this role because their security rests on the hash function alone, with no algebraic structure to attack. Concrete instantiations such as SLH-DSA-128s offer small public keys and very long-lived security at the cost of large signatures -- a trade-off that is acceptable for a key whose signature appears only on the apex DNSKEY RRset. 6.2. Root ZSK The root ZSK SHOULD also use a post-quantum algorithm, but one with smaller signatures than the root KSK algorithm. The algorithm-split profile of Section 3 does not require the ZSK algorithm to be classical; it requires only that it differ from the KSK algorithm. Selecting a post-quantum ZSK algorithm with comparatively smaller signatures (examples in the current literature include some multivariate constructions, with MAYO as one candidate among others) keeps DS responses and other root-zone responses within a manageable size envelope while still providing post-quantum integrity for root zone data. Naming a specific algorithm is out of scope for this document; the recommendation is that the root ZSK algorithm be (a) post-quantum and (b) substantially smaller in signature size than the root KSK algorithm. Stenstam Expires 14 December 2026 [Page 11] Internet-Draft Algorithm-Split DNSSEC June 2026 6.3. Root ZSK Rotation Cadence The root zone has on the order of a thousand delegations and a small, well-resourced operational team; its ZSK rotation cadence is not limited by signing throughput. Given the root's role as the apex of every DNSSEC trust chain, and the cross-dependency discussed in Section 4, the strength of the key signing DS RRsets in the root zone is a security parameter of every zone in the tree. That strength is the combination of the algorithm used and the cadence at which the key is rolled. The root zone operators have historically chosen and managed the root ZSK with this combined strength in mind, and are expected to continue doing so as threat estimates evolve. 6.4. Transport for Root Queries The root zone is a special case for the DS-based size signal of Section 5: by construction it has no parent, so no DS RRset exists from which a resolver could learn that the root's KSK uses an algorithm with large signatures. The size-signal logic of Section 5 therefore does not apply to root queries. This document takes a forward-looking position: well in advance of any rollover of the root zone to a PQ-safe algorithm with large signatures, resolvers SHOULD adopt a transport suitable for large responses (TCP, DoT, DoQ, or another) for all queries to the root zone, rather than UDP/53. Resolvers make relatively few distinct queries to the root zone in steady state, so the per-query cost of doing this for all root queries is small in aggregate, and the transition to a large-signature root then becomes operationally invisible to resolvers that have already moved their root traffic off UDP/53. A coordinated truncation event affecting the entire resolver population at the moment of a root rollover to a large-signature algorithm is thereby avoided. A consequence of the preceding paragraph is that the size constraints on the root zone are largely a question of cache and bandwidth, not of UDP truncation. The root MAY therefore use larger DS-RRset signatures than would be acceptable for a zone served predominantly over UDP. 7. Operational Considerations The large DNSKEY RRset of an algorithm-split zone is retrieved and validated once per DNSKEY-TTL per resolver and then cached; subsequent queries for ordinary zone data return small, ZSK-signed responses that fit comfortably in UDP. The large object is thus a once-per-TTL-per-cache cost, which Section 5 further reduces by avoiding the truncated-UDP round trip. Stenstam Expires 14 December 2026 [Page 12] Internet-Draft Algorithm-Split DNSSEC June 2026 Rolling a large KSK transiently enlarges the DNSKEY RRset further, as it must hold both the outgoing and incoming KSKs during the rollover. Operators should account for this when sizing transport expectations. A validator that does not support the KSK algorithm cannot follow the DS-based chain of trust and treats the delegation as Insecure, exactly as for any rollout of a new algorithm. Deploying a large or post-quantum KSK therefore has the same backward-compatibility profile as introducing any new DNSSEC algorithm. The ZSK rotation cadence required by Section 4 interacts with cache TTLs, key-management automation, and HSM throughput. Operators adopting the algorithm-split profile SHOULD verify that their operational pipeline can sustain the required cadence before deploying the profile. 8. Security Considerations 8.1. Why the Completeness Relaxation Is Safe The DNSSEC algorithm-completeness rule of [RFC4035] Section 2.2 and [RFC6840] Section 5.11 exists to prevent algorithm-downgrade attacks in deployments where multiple algorithms play _peer_ roles: each algorithm is independently capable of authenticating zone data, and an attacker who breaks the weaker of two peers can forge data and strip signatures from the stronger one. Completeness ensures that every RRset is independently protected under every algorithm a validator might choose, and operator policy can require validation under the strongest available algorithm. In the algorithm-split profile of Section 3, the KSK-side and ZSK- side algorithms are _not_ peers. They occupy distinct, structurally asymmetric roles in a fixed chain of trust, derived in Section 4: an adversary who breaks the ZSK algorithm cannot substitute a ZSK of their own choosing without also forging a KSK-algorithm signature on the apex DNSKEY RRset. The peer-role attack that completeness was designed to prevent does not apply, because the algorithms are not peers. This eliminates peer-substitution downgrade outright. It does not, however, preserve the residual forgery-window bound that completeness afforded even outside the peer-role case; the relaxation trades that absolute guarantee (a forgery under the weaker algorithm cannot validate at all) for a time-bounded one (such a forgery validates only within a single ZSK's lifetime). The next paragraph describes that residual guarantee, and Section 4 restores it by other means. The safety claim of this document is therefore a claim about the combination, not about the relaxation in isolation. Stenstam Expires 14 December 2026 [Page 13] Internet-Draft Algorithm-Split DNSSEC June 2026 What completeness _did_ provide, even outside the peer-role case, was an unforgeable upper bound on the lifetime of an attacker's forgery window: a non-DNSKEY RRset signed under both algorithms gave an A-supporting validator the option to require an A signature and thereby refuse any B-only forgery. The algorithm-split profile removes that fallback. The cadence requirement of Section 4 takes its place: instead of being prevented by signature redundancy, the forgery window is bounded by ZSK lifetime. The safety argument for this document is therefore _structural asymmetry plus bounded ZSK lifetime_. This is why Section 3 and Section 4 are inseparable. 8.2. Threat Model for the Transition In the most-discussed near-term transition, algorithm A is post- quantum (or otherwise expected to be long-lived) and algorithm B is a traditional algorithm such as ECDSA or Ed25519. The remainder of this section uses that instance as the worked example; the analysis carries over to the more general case where algorithm B is post- quantum but with a shorter security margin than algorithm A. The most relevant threat in the near-term case is the future arrival of a cryptographically relevant quantum computer capable of breaking algorithm B. Under that threat: * Long-term data integrity guarantees for non-DNSKEY RRsets are not provided by this document; an attacker with a CRQC can forge ZSK- signed data within the window of a published ZSK's lifetime. The Section 4 cadence bounds this window. * Long-term trust-anchor integrity _is_ provided, because the KSK algorithm (A) is chosen to resist a CRQC. A validator with a stable algorithm-A trust anchor retains the ability to detect substituted KSKs across time. * The combination is therefore appropriate as a transition strategy: it exercises large-key handling, transport, and operational tooling, and protects the longest-lived element (the trust anchor), while acknowledging that bulk-zone integrity against a CRQC requires algorithm B to also be post-quantum (as discussed for the root in Section 6). Stenstam Expires 14 December 2026 [Page 14] Internet-Draft Algorithm-Split DNSSEC June 2026 8.3. Cross-Zone Dependency Section 4 establishes that a child zone in the algorithm-split profile is no more secure than the parent's signature on its DS RRset. This is a general DNSSEC property and not a novel weakness, but the algorithm-split profile makes it operationally visible: a child KSK that uses a strong post-quantum algorithm can give the misleading impression that the child is post-quantum-secure end-to- end, when in fact the parent's DS-signing key -- typically a classical ZSK -- remains the binding strength of the chain until the parent itself transitions. The operational implication: a parent whose children adopt the algorithm-split profile SHOULD treat the strength of its DS-signing key (algorithm and rotation cadence together) as a security parameter of those children, not solely of itself. 8.4. Transport Signal The DS-based size signal of Section 5 is a transport optimization with no effect on validation. A misjudgment about an algorithm's size results only in an unnecessary use of a large-capable transport, or in a fallback to the existing UDP-then-fallback behavior; it cannot affect whether data validates. 9. IANA Considerations This document requires no IANA action. Section 3 and Section 4 update the signing and validation rules of [RFC4035] and [RFC6840], and Section 5 is a resolver-side local optimization. 10. References 10.1. Normative References [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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Stenstam Expires 14 December 2026 [Page 15] Internet-Draft Algorithm-Split DNSSEC June 2026 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840, DOI 10.17487/RFC6840, February 2013, . 10.2. Informative References [FIPS204] National Institute of Standards and Technology (NIST), "Module-Lattice-Based Digital Signature Standard", FIPS 204, August 2024, . [FIPS205] National Institute of Standards and Technology (NIST), "Stateless Hash-Based Digital Signature Standard", FIPS 205, August 2024, . [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, . [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, "DNSSEC Key Rollover Timing Considerations", RFC 7583, DOI 10.17487/RFC7583, October 2015, . [I-D.johani-dnsop-dnssec-alg-experimental-range] Stenstam, J., "Experimental and Private-Use Ranges in the DNSSEC Algorithm Numbers Registry", Work in Progress, Internet-Draft, draft-johani-dnsop-dnssec-alg- experimental-range-00, 12 June 2026, . Acknowledgments The author acknowledges that Ondřej Surý arrived independently at the idea of splitting the KSK and ZSK algorithms, and thanks him for substantive discussions on this topic during RIPE 92. The author also thanks Joe Abley (Cloudflare), Christian Elmerot (Cloudflare), Peter Thomassen (deSEC), and Erik Bergström (Swedish Internet Foundation) for valuable insights and suggestions. Author's Address Stenstam Expires 14 December 2026 [Page 16] Internet-Draft Algorithm-Split DNSSEC June 2026 Johan Stenstam The Swedish Internet Foundation Email: johan.stenstam@internetstiftelsen.se Stenstam Expires 14 December 2026 [Page 17]