Algorithm-Split DNSSEC: KSK/ZSK Algorithm Separation

Internet-Draft	Algorithm-Split DNSSEC	June 2026
Stenstam	Expires 29 December 2026	[Page]

Abstract

Post-quantum DNSSEC signature algorithms have much larger keys and/or signatures than the elliptic-curve algorithms in common use today. For any such algorithm the apex DNSKEY RRset grows, since it carries the key material; the open question is whether the rest of the zone has to grow with it. A key-signing key (KSK) signs only the apex DNSKEY RRset, so its signature size is nearly irrelevant; a zone-signing key (ZSK) signs every other RRset, so keeping its signatures small is what keeps ordinary responses small. Confining a large algorithm to the KSK, and using a small-signature algorithm for the ZSK, keeps the cost of the large algorithm contained in the DNSKEY RRset.¶

This document specifies the changes that 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 relies on ordinary ZSK rotation to bound the residual exposure of the ZSK algorithm; 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. This document updates RFC 4035 and RFC 6840.¶

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 with it 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.¶

The deeper motivation is to decouple two requirements that a single zone algorithm is forced to satisfy at once. A KSK and a ZSK protect very different things and are exposed in very different ways, yet today both must be the same algorithm, so that algorithm has to satisfy the union of both roles' constraints. In practice the binding constraint is the ZSK's: the algorithm must produce signatures small enough that ordinary responses do not overflow common UDP size limits. That "ZSK property" -- small signatures -- ends up dictating the algorithm for the KSK as well, even though the property that actually matters for a KSK is a different one: strength great enough that the key need never be rolled merely because its algorithm has become too weak. A KSK signs only the apex DNSKEY RRset, so its signature size is nearly irrelevant; what matters is its longevity as a trust anchor. Today the small-signature requirement of the ZSK role effectively caps the strength available to the KSK role.¶

Algorithm splitting removes that coupling. For the first time it becomes possible to choose each key's algorithm for the property that matters most in that key's role -- a strong, long-lived (for example post-quantum) algorithm for the KSK, whose large signatures are confined to the DNSKEY RRset, and a small-signature algorithm for the ZSK, whose signatures appear on every RRset. Seen this way, the primary effect of this document is not that the ZSK becomes weaker; it is that the KSK is, for the first time, allowed to be much stronger than the "fits in a UDP response" constraint would otherwise permit.¶

This document specifies three changes that together enable this deployment pattern:¶

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.¶
A bounded ZSK rotation cadence (Section 4). Rolling the ZSK at an appropriate cadence bounds the window in which a break of the ZSK algorithm could be exploited. For the intended deployment, in which the ZSK algorithm is itself PQ-safe, this is an ordinary rotation schedule; the cadence becomes a tighter security parameter only in the fallback case where the ZSK algorithm is weaker than the KSK algorithm (for example a classical ZSK during the transition).¶
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 work together. Part 1 makes the deployment pattern possible; part 2 bounds the residual exposure of the ZSK algorithm; part 3 makes the resulting transport profile efficient. The safety of the relaxation in Part 1 rests on the structural asymmetry between the KSK and ZSK roles (see Section 8), which holds independently of the cadence; Part 2 then bounds whatever residual exposure remains. Part 3 is a pure efficiency optimization that a resolver may implement or ignore.¶

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.¶

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 alone; it does not assume any particular character for either algorithm. In the intended deployment both algorithms are post-quantum -- a strong, long-lived KSK algorithm paired with a ZSK algorithm whose signatures are small enough to be acceptable on every RRset in the zone. The profile applies equally in a transitional deployment where the KSK algorithm is post-quantum but the ZSK algorithm is still a classical elliptic-curve algorithm. As the set of standardized post-quantum signature algorithms grows, the profile is expected to admit an increasing range of ZSK choices; the strength of the chosen ZSK algorithm 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.¶

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.¶

This relaxation is defined structurally, in terms of the parent DS and apex DNSKEY contents alone, and does not depend on which algorithms appear in K. A validator MAY nonetheless apply a stricter local policy -- for example, accepting the relaxation only when the KSK algorithm is in an operator-configured set. This is additive local caution, not a change to the acceptance rule defined here, and is analogous to the algorithm denylists validators may already maintain; like the classifier of Section 5, it is best expressed as a compiled-in default that the operator can override.¶

4. Part 2: Bounded ZSK Rotation Cadence

4.1. What the Cadence Bound Does

The safety of the completeness relaxation rests on the structural asymmetry between the KSK and ZSK roles, derived in Section 8: an adversary who breaks the ZSK algorithm cannot substitute a ZSK of their own without also forging a KSK-algorithm signature. That argument holds regardless of how often the ZSK is rolled. What the rotation cadence adds is a bound on the residual exposure -- the window during which a break of the ZSK algorithm could be used to forge data that validates against a currently published ZSK.¶

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:¶

The parent DS RRset, validated by the parent's own chain of trust, authenticates the child's KSK (algorithm A).¶
The KSK signs the apex DNSKEY RRset, authenticating the ZSK (algorithm B) as key material.¶
The ZSK signs the non-DNSKEY RRsets of the zone.¶

The effect of the split is that the KSK -- the trust anchor for the zone, referenced by the parent DS -- can be given a stronger, longer-lived algorithm than was previously possible, because its signature size no longer has to fit the constraints of the ZSK role. The ZSK is not made weaker by this; it keeps whatever strength it would have had anyway. What changes is that the ZSK signature no longer has a same-strength KSK-algorithm signature sitting alongside it on every RRset.¶

An adversary who breaks the ZSK algorithm can forge signatures that validate against a currently published ZSK, but cannot substitute a ZSK of their own choosing without forging a KSK-algorithm signature on the apex DNSKEY RRset -- which the upgraded KSK is chosen to resist. The adversary's forgery window is therefore bounded by the lifetime of any individual ZSK. Bounding that lifetime is the role of the rotation cadence.¶

This is not a new obligation invented by this document. The completeness rule of [RFC4035] never prevented this scenario on its own: [RFC6840] Section 5.11 already permits a validator to validate using any single supported algorithm. What completeness did do was make a second-algorithm signature available on every RRset, so a validator that supported it could choose to require it. The algorithm-split profile makes that fallback unnecessary rather than unavailable: the ZSK is held at a strength the operator already trusts, and its exposure is bounded by ordinary rotation instead of by signature redundancy.¶

4.2. The Requirement

A zone signed under the algorithm-split profile of Section 3 SHOULD roll its ZSK at a cadence T appropriate to the threat estimate against the ZSK algorithm. T is intentionally not a fixed value in this document, because the appropriate value depends on the chosen ZSK algorithm and on cryptanalytic progress, neither of which can be fixed at the time of writing. The safety of the completeness relaxation does not depend on this cadence (it rests on the structural argument of Section 8); the cadence bounds the residual exposure of the ZSK algorithm, and matters most in the fallback case below.¶

For the intended deployment, in which the ZSK algorithm is itself PQ-safe (see Section 3), the appropriate cadence is an ordinary rotation schedule -- the months-scale intervals that current operational practice already supports -- because the ZSK algorithm is not expected to be broken within the operational lifetime of any individual key. The cadence becomes a tighter security parameter only in the fallback case where the ZSK algorithm is materially weaker than the KSK algorithm (for example a classical ZSK retained during the transition); there, T should be reduced as the threat estimate against that algorithm sharpens.¶

The appropriate value of T is a matter of operator security policy, 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].¶

Signing implementations (including BIND, Knot, Cascade, and others) are expected to encode per-algorithm minimum cadences as policy and may 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 recommends that some appropriate cadence be applied.¶

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 KSK-algorithm 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.¶

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.¶

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.¶

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.¶

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: the parent DS authenticates the KSK, the KSK authenticates the ZSK, and the ZSK signs zone data. 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 -- and the KSK algorithm is, under this profile, chosen to be strong precisely because the split frees it from the ZSK's size constraint. The peer-role downgrade that completeness was designed to prevent therefore does not apply: the algorithms are not peers, and the algorithm protecting the chain-of-trust step is the stronger of the two, not the weaker. This structural argument is the basis for the safety of the relaxation, and it holds independently of how often the ZSK is rolled.¶

The relaxation does change one thing. Where every RRset previously carried signatures from every DNSKEY-RRset algorithm, a validator that supported the stronger algorithm could choose to require it on zone data and thereby refuse any forgery made under a weaker one. Under the split, zone data carries only ZSK-algorithm signatures, so that particular fallback is no longer available. Its place is taken by bounding the ZSK's exposure through rotation (Section 4): the ZSK is held at a strength the operator already trusts, and the window in which a break of it could be exploited is bounded by the ZSK lifetime rather than by signature redundancy. For the intended PQ-safe ZSK this is an ordinary rotation schedule.¶

8.2. What the Validator Can and Cannot Verify

The time-bounded guarantee of Section 4 rests on the zone operator actually rolling the ZSK at an appropriate cadence. A validator cannot verify this: nothing in the DS RRset, the DNSKEY RRset, or the signatures reveals how often the ZSK is rolled, or whether it is ever rolled at all. The relaxation therefore asks the validator to accept ZSK-signed data on the strength of an operator obligation it cannot check.¶

This is not a new property introduced by this document. A validator has never been able to observe an operator's key-rotation behaviour, and in practice a large fraction of signed zones roll their keys rarely or never -- historically because rolling was perceived as difficult or risky, and operationally because nothing forces it. The absolute forgery-window bound that completeness is sometimes credited with was, for those zones, already unrealised: it required both that the operator maintain genuine multi-algorithm coverage and that a validator choose to demand the stronger algorithm. Against that real-world baseline, a diligently rolled ZSK under Section 4 is stronger, not weaker, than the prevailing practice.¶

8.3. The ZSK Need Not Be the Weak Link

Some of the language in Section 4, and the threat model below, analyses the demanding case in which the ZSK algorithm is materially weaker than the KSK algorithm -- typically a classical ZSK (ECDSA, Ed25519) paired with a post-quantum KSK. The intended deployment is not that case. The expectation is that the ZSK algorithm is itself post-quantum, with a security margin comparable to the long-lived classical keys (such as 2048-bit or larger RSA) that are, in practice, rarely or never rolled today -- chosen for the "ZSK property" of small signatures rather than for a short security horizon.¶

When the ZSK is that strong, the cadence recommendation of Section 4 is a conservative margin rather than the sole barrier to forgery, and the net effect of the profile is almost entirely on the other side of the split: it lets the KSK, for the first time, be chosen for strength and longevity instead of being held down to the ZSK's size constraint. The proposal is better understood as a gain in trust-anchor strength than as a concession in ZSK strength. (The cross-zone dependency of Section 8.5 still applies: until a zone's parent transitions, the strength of the parent's DS-signing key, not the child's KSK, caps the chain.)¶

8.4. Threat Model for the Transition

In the intended deployment both the KSK and the ZSK use PQ-safe algorithms (the KSK a strong, long-lived one; the ZSK one with small signatures). Against the arrival of a cryptographically relevant quantum computer (CRQC), both the trust anchor and bulk zone data are then protected, and the ZSK rotation cadence is an ordinary schedule that bounds residual exposure as a margin.¶

The more demanding case is a transitional one, in which the KSK has already been upgraded to a PQ-safe algorithm but the ZSK is still a classical algorithm such as ECDSA or Ed25519. It is worth working through explicitly, because a profile that is safe here is safe a fortiori when the ZSK is also PQ-safe. The relevant threat is a CRQC capable of breaking the classical ZSK algorithm. Under that threat:¶

Long-term data integrity for non-DNSKEY RRsets is not provided in this transitional case; 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, which is why the cadence matters most in exactly this case.¶
Long-term trust-anchor integrity is provided, because the KSK algorithm is chosen to resist a CRQC. A validator with a stable PQ-safe trust anchor retains the ability to detect substituted KSKs across time.¶
The combination is therefore appropriate even as an early transition step: it upgrades the longest-lived element (the trust anchor) first, and exercises large-key handling, transport, and operational tooling, while full protection of bulk zone data against a CRQC follows once the ZSK is also PQ-safe (as discussed for the root in Section 6).¶

8.5. 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.6. 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.¶

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, <https://www.rfc-editor.org/rfc/rfc4035>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC6840]: Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840, DOI 10.17487/RFC6840, February 2013, <https://www.rfc-editor.org/rfc/rfc6840>.

10.2. Informative References

[FIPS204]: National Institute of Standards and Technology (NIST), "Module-Lattice-Based Digital Signature Standard", FIPS 204, August 2024, <https://csrc.nist.gov/pubs/fips/204/final>.
[FIPS205]: National Institute of Standards and Technology (NIST), "Stateless Hash-Based Digital Signature Standard", FIPS 205, August 2024, <https://csrc.nist.gov/pubs/fips/205/final>.
[RFC6781]: Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, <https://www.rfc-editor.org/rfc/rfc6781>.
[RFC7583]: Morris, S., Ihren, J., Dickinson, J., and W. Mekking, "DNSSEC Key Rollover Timing Considerations", RFC 7583, DOI 10.17487/RFC7583, October 2015, <https://www.rfc-editor.org/rfc/rfc7583>.
[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, <https://datatracker.ietf.org/doc/html/draft-johani-dnsop-dnssec-alg-experimental-range-00>.