Internet-Draft Multiple Algorithm Rules in DNSSEC July 2023
Huque, et al. Expires 23 January 2024 [Page]
Internet Engineering Task Force
4035, 6840, 8624 (if approved)
Intended Status:
Standards Track
S. Huque
P. Thomassen
V. Dukhovni
Google LLC

Multiple Algorithm Rules in DNSSEC


This document restates the requirements on DNSSEC signing and validation and makes small adjustments in order to allow for more flexible handling of configurations that advertise multiple Secure Entry Points (SEP) with different signing algorithms via their DS record or trust anchor set. The adjusted rules allow both for multi-signer operation and for the transfer of signed DNS zones between providers, where the providers support disjoint DNSSEC algorithm sets. In addition, the proposal enables pre-publication of a trust anchor in preparation for an algorithm rollover, such as of the root zone.

This document updates RFCs 4035, 6840, and 8624.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

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

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 23 January 2024.

Table of Contents

1. Introduction and Motivation

The Domain Name System Security Extensions (DNSSEC) [RFC4033] [RFC4034] [RFC4035] add data origin authentication and integrity protection to the Domain Name System (DNS), by having DNS zone owners (or their operators) crytographically sign their zone data.

Current specifications [RFC4035][RFC6840] require that a zone be signed with each signing algorithm listed in a zone's DS RRset or appearing via its trust anchors. This poses a problem for (at least) the following cases:

The above issues are not just a theoretical problem. Real situations in the field have occurred where the existing requirements have posed an obstacle to DNSSEC deployment and operations.

That said, the existing signing requirements are well motivated: When a zone's DS RRset or trust anchor set includes multiple DNSKEY algorithms, an attacker who can strip all the supported RRSIGs from a signed response from that zone, leaving just the unsupported signatures, must not be able to disable validation for that zone, effectively downgrading the zone to "insecure". The rules therefore ensure the downgrade resistance of DNSSEC when only some, but not all, of a zone's DS RRset or trust anchor set DNSKEY algorithms are supported by a validating resolver.

This document proposes modifications of the signing and validation rules to accommodate additional use cases, without compromising the security guarantees given by DNSSEC.

2. Proposed Updates to RFCs

The heart of the issue is that even though any one acceptable signature suffices for validation, the signer cannot, in the general case, know which particular signing algorithm(s) the validator will support; and hence, providing a "large enough set" (read: all of them) is the approach that had been taken so far.

This is set down in Section 2.2 of [RFC4035]:

There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any).

In the following, two different ways of amending this existing specification are described. Both methods advocate that signers adopt a more liberal approach to the requirement of signatures by algorithm sets. The minimal approach provides cautionary advice to zone owners about the selection of appropriate algorithm sets. The comprehensive approach more precisely defines which algorithms are safe to use in this way, and additionally places some of the burden on validating resolvers to ensure this safety.

2.1. Minimal Approach

The most straightforward proposal is to relax the rule quoted from RFC 4035 by changing the MUST to a SHOULD, and state that there are valid configurations where this rule could be disregarded.

This approach puts the burden on the zone owners/ signers to only select suitably strong and well supported algorithms (such as algorithms 8 and 13). It does not require any new changes to validating resolvers - they just have to follow the clarifying rule in RFC 6840 that any valid authentication path is acceptable. It thus represents a minimal approach to achieving the goals outlined in the abstract.

If zone owners do not carefully select such a set of widely supported algorithms, this can cause problems. For example, if they choose 7 as one of the algorithms, it may cause validators to return SERVFAIL under certain circumstances.

More explicitly, a zone that is using such an algorithm as its sole signing algorithm is (correctly) treated as insecure by resolvers that do not support that algorithm. When attempting to transfer the domain to another DNS provider through a multi-signer setup with a supported algorithm, affected resolvers will return SERVFAIL when presented with the unsupported signature only. Zone owners and signers thus must take great care to not leave a validating resolver without a valid supported path when transitioning e.g. from algorithm 7 to 13.

2.2. Comprehensive Approach

This approach establishes a mechanism allowing the signer to determine which RRSIGs can be skipped, without risking validation failures. It does not require all algorithms' RRSIGs to be present, while ensuring that the set of signatures provided is still "large enough" for reliable DNSSEC operation, so that robust multi-signer operation and TA pre-publication are made possible, without risking validation failures.

For the case of a multi-signer setup with two generally supported algorithms (such as 8 and 13), the scheme requires only one of the two signatures. Similarly, when pre-publishing a trust anchor, associated signatures don't need to be published immediately, provided that the existing TA's algorithm is generally supported.

2.2.1. Updates to RFC 8624

The notion of UNIVERSAL signing algorithms is introduced, and defined as follows:

  • The information contained in the table of [RFC8624] Section 3.1 is transferred into a to-be-erected IANA registry, and a boolean column is added with the heading "universal validation support". Signing algorithms where this column is TRUE are called "UNIVERSAL".

  • "MUST NOT sign" algorithms can never be UNIVERSAL. "MUST validate" is a prerequisite for UNIVERSAL. Changes that affect whether an algorithm is UNIVERSAL require standards action.

  • Algorithms 8 and 13 are the only algorithms initially declared UNIVERSAL.

Also, new terminology is established for algorithms in "MUST NOT sign" status: these are designated as "INSECURE" algorithms.

As soon as a "MUST validate" algorithm is known or expected to have declining validation support, it should be moved to status "MUST NOT sign" (which removes the UNIVERSAL label if present, and renders the algorithm INSECURE). Therefore, this document updates algorithms 5 and 7 to "MUST NOT sign".

The following algorithms are thus INSECURE: 1, 3, 5, 6, 7, 12

2.2.2. Signer Requirements

  1. Signers must sign with at least one UNIVERSAL algorithm if at least one UNIVERSAL algorithm is present in the DS RRset or trust anchor set. Other signatures are OPTIONAL.
  2. Absent any UNIVERSAL algorithms in the DS RRset or trust anchor set, signers MUST sign with all algorithms listed.

2.2.3. Validator Requirements

  1. When the DS RRset or trust anchor set for a zone includes an unsupported INSECURE algorithm, validators MUST treat the zone as unsigned, even if the DS RRset or trust anchor set lists another supported algorithm.
  2. Otherwise, validators MUST accept any valid path.

Implementing these rules requires validating resolvers to keep a record of unsupported INSECURE algorithms, so that the zone's security status can be established upon inspection of a DS record or TA set.

Any otherwise supported by default algorithms that are disabled by the resolver operator as a matter of local policy SHOULD also be considered "INSECURE" unless explicitly configured as "unsupported". The choice should be made with care. Disabling an algorithm to "INSECURE" downgrades zones signed with the disabled algorithm, while disabling it as "unsupported" risks making some zones "bogus", if it was used as the only signing algorithm by one of the signers in a multi-signer, multi-algorithm setup.

2.2.4. Discussion

It is observed that both signers and validators need to know only one of the concepts "UNIVERSAL" and "INSECURE". To use several signing algorithms, signers only need to know which algorithms are UNIVERSAL, while validators only need to know which are INSECURE. This limits the implementation effort.

The new validation requirements enable stable multi-signer setups using UNIVERSAL algorithms as well as robust provider transfers and algorithm upgrades from INSECURE to UNIVERSAL algorithms (such as algorithm 7 to 13), without risking SERVFAIL responses in the event that a resolver no longer supports one of the algorithms (e.g. 7). For a detailed discussion, see Security Considerations (Section 4.2).

DNS operators in a multi-signer setup are free to limit their responses to serve signatures for one UNIVERSAL algorithm only. This one signature is sufficient to provide a valid path everywhere.

When a UNIVERSAL algorithm is in use, signatures of other algorithms are not required. DNS providers are thus free to introduce additional (non-INSECURE) algorithms without forcing other participating providers to do the same.

For zones with trust anchors, when there is a trust anchor with a UNIVERSAL algorithm, it is permissible to introduce a new trust anchor for a different algorithm before introducing the corresponding DNSKEY and RRSIGs into the zone. (Of course, they need to be added before the old trust anchor is removed.)

If the added trust anchor is also for a UNIVERSAL algorithm, it is permissible to eventually switch to returning just the RRSIGs for the new algorithm, without an intermediate dual-signing period. If the new trust anchor is not yet UNIVERSAL, a dual signing period is required in order to complete the algorithm rollover.

In typical cases, particularly in the case of the root zone, both algorithms will be UNIVERSAL. In a hypothetical emergency situation where only the new algorithm is UNIVERSAL and the old was just downgraded to INSECURE, the new signatures would need to be introduced immediately. A short dual signing period would then be required for continuity. Resolvers would be expected to defer disabling the old algorithm until after the root zone rollover is completed.

3. IANA Considerations

The minimal approach (Section 2.1) has no IANA actions.

When the comprehensive approach (Section 2.2) is taken, this section will need to be updated to describe the construction of the new IANA registry for the implementation status and requirements of DNSSEC signing algorithms.

4. Security Considerations

4.1. Minimal approach

The minimal approach requires the zone owner and signer(s) to take great care in order to not break working setups by entering a multi-signer setup. In particular, when transferring a zone to another DNS provider and switching from e.g. algorithm 7 to 13 in the process, resolvers that do no longer support algorithm 7 will expect a valid path for algorithm 13. If the response only contains an RRSIG for algorithm 7, the result will be SERVFAIL.

The minimal approach is thus only workable in cases where the multi-signer setup involves universally supported algorithms exclusively. As the set of universally supported algorithms evolves over time, zone owners and signers need to monitor developments and upgrade algorithms before validation support for the involved algorithms is declining and SERVFAIL looms.

4.2. Comprehensive approach

4.2.1. Algorithm Transitions

The new validation requirements guarantee that when a zone is in a multi-signer setup with two algorithms, the security level is the same as it would be if the zone was in a single-signer setup using the weakest of them (from the resolver's perspective). This resolves undue SERVFAIL issues that could occur with certain algorithm combinations under the previous rules.

For example, a zone using only algorithm 7 is treated as insecure by resolvers that do not support this algorithm. (This is as before.) When transferring the domain to another provider via a multi-signer setup with algorithm 13, however, the zone's security status will now remain "insecure", as the DS RRset still includes INSECURE algorithm 7. The presence of algorithm 13 is inconsequential at this point. Only once algorithm 7 is removed, the zone turns secure.

This rule prevents validation breakage when the resolver encounters an unsupported RRSIG from an outdated algorithm, and instead acknowledges the fact that the signer is using an algorithm that is in "MUST NOT sign" status, which (depending on resolver support) might render the zone insecure. This allows for glitch-free algorithm upgrades, with the security status of the zone changing only once the transition is complete.

Resolvers supporting both algorithms retain full validation throughtout the transition. In case of a permanent multi-signer setup, the zone maintainer needs to upgrade the INSECURE algorithm to a UNIVERSAL one in order to restore universal validation.

4.2.2. Time Dependency of UNIVERSAL Algorithms

The same situation occurs when an algorithm is removed from the set of UNIVERSAL algorithms. In this case, the algorithm will enter "MUST NOT sign" status and become INSECURE. If the zone continues to use the INSECURE algorithm, it will continue to fully validate with supporting resolvers, while non-supporting resolvers will treat the zone as insecure until the algorithm is replaced.

Conversely, when an algorithm is added to the set of UNIVERSAL ones, signers MAY begin to return signatures for just that algorithm. This is, in fact, not a problem, as resolvers do not need to know the concept of UNIVERSAL; they just need to support that algorithm (or, typically, explicitly classify it as INSECURE). A problem could only occur if the corresponding RRSIG was not supported by a non-negligible population of resolvers; however, in that case labeling the algorithm as UNIVERSAL would have been premature. Determining universal support cannot be solved on the protocol level, and it is the community's responsibility to only advance an algorithm to UNIVERSAL when safe enough, i.e. when the population of resolvers lacking support is deemed negligible.

Resolvers dropping support for INSECURE algorithms (e.g. 7) without implementing this specification will produce SERVFAIL responses for multi-signer setups involving the disabled algorithm. Implementation of the new validation rules is thus advised as soon as support for an algorithm is dropped.

4.3. Variable Key Size Algorithms

Since algorithm 8 supports variable key sizes, multi-signer configurations involving 8 and 13 should take care to employ an RSA keylength that is computationally infeasible to attack.

5. Acknowledgements

The minimal proposal in this draft was originally proposed in [ICANN-TALK] by Shumon Huque at the ICANN73 DNSSEC and Security workshop.

The comprehensive approach was originally proposed by Peter Thomassen and Viktor Dukhovni after discussions on the problem space with Edward Lewis, Jakob Schlyter, Johan Stenstam, Shumon Huque, Steve Crocker, and Duane Wessels.

6. Normative References

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, , <>.
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, , <>.
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, , <>.
Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840, DOI 10.17487/RFC6840, , <>.
Wouters, P. and O. Sury, "Algorithm Implementation Requirements and Usage Guidance for DNSSEC", RFC 8624, DOI 10.17487/RFC8624, , <>.
Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D. Blacka, "Multi-Signer DNSSEC Models", RFC 8901, DOI 10.17487/RFC8901, , <>.

7. Informative References

Wisser, U. and S. Huque, "DNSSEC Automation", <>.
Huque, S., "RFC Adjustments for Multi-Signer", <>.

Appendix A. Current Multiple Algorithm Rules

This section discusses the multi-algorithm requirements on signers and validators, as specified by the original DNSSEC specification and in effect until updated by this document. It is included for purely informational purposes and context.

A.1. Signing Requirements

In addition to the last paragraph of [RFC4035] Section 2.2 quoted earlier, Section 5.11 of [RFC6840] clarifies:

A signed zone MUST include a DNSKEY for each algorithm present in the zone's DS RRset and expected trust anchors for the zone.

While it might seem tempting, relaxing this rule without any further adjustments may not be safe depending on the algorithm combination involved. In particular, when using an algorithm that is not universally supported among the resolver population (such as algorithm 7) together with a supported one (such as algorithm 13), resolvers may return SERVFAIL under certain circumstances. Zone owners and signers thus would have to take great care to not leave a validating resolver without a valid supported path in such situations, e.g. when transitioning from algorithm 7 to 13.

More explicitly, when the sole signing algorithm used by a zone is not supported by a given resolver, the resolver will (correctly) treat that zone as unsigned. However, when attempting to transfer the domain to another DNS provider through a multi-signer setup with a supported algorithm, affected resolvers presented with the unsupported signature only will not be able to distinguish this situation from a downgrade-to-insecure attack where the second signature has been stripped, and will return SERVFAIL.

Although unstated in that document, the above rule prevents this kind of downgrade-to-insecure attack by requiring RRSIGs for all advertised algorithms; a validator can thus assume that something is wrong when supported signatures are missing. As a side effect, the rule also protects against downgrade-to-weaker attacks, so that an attacker cannot undetectably strip away signatures by a stronger algorithm from signed DNS responses. This property is not a core guarantee of DNSSEC (see below).

A.2. Validator Requirements

In general, when a validating resolver supporting any of the algorithms listed in a given zone's DS record or TA set responds to a query without the CD flag set, it may not treat that zone as insecure, but must return either validated data (AD=1) or RCODE=2 (SERVFAIL). For this purpose, any valid path suffices; the validator may not apply a "logical AND" approach to all advertised algorithms.

Accordingly, Section 5.11 of DNSSEC Clarifications [RFC6840] states:

This requirement applies to servers, not validators. Validators SHOULD accept any single valid path. They SHOULD NOT insist that all algorithms signaled in the DS RRset work, and they MUST NOT insist that all algorithms signaled in the DNSKEY RRset work.

At first glance, the assertions that (1) the signer provide signatures for all advertised algorithms while (2) the resolver shall be content with just one seems somewhat contradictory. However, the role of the RRSIG rules is to ensure that the resolver will find a valid path (using a "logical OR" strategy), regardless of which particular algorithm(s) it supports, and thus be able to distinguish reliably between "all is in order" (validated data) and a downgrade-to-insecure attack (SERVFAIL).

A.3. Incompatible Use Cases

The above rules are incompatible with certain use cases:

  • They are impractical to satisfy if DNS providers deployed in a multi-signer configuration are using different signing algorithms. By extension, it also means that multi-signer techniques cannot be employed to non-disruptively transfer a signed zone from one DNS provider to another if the providers use differing algorithms.

  • The rules further collide with the conflicting goal of pre-publishing the new trust anchor during a zone's algorithm rollover, while introducing the new algorithm into the zone only later in the process.

  • Furthermore, for online signers attempting to deploy multiple algorithms, producing signatures for several algorithms also imposes a significant computational burden, unless a selective algorithm negotiation mechanism is also developed.

As the above rules present a severe limitation for these use cases, this document proposes to relax them in a way so that the set of signatures provided is still "large enough" to ensure reliable DNSSEC operation, while facilitating the above use cases.

Authors' Addresses

Shumon Huque
415 Mission Street, 3rd Floor
San Francisco, CA 94105
United States of America
Peter Thomassen
Viktor Dukhovni
Google LLC