RFC 6781
DNSSEC Operational Practices, Version 2
DNSSEC Operational Practices, Version 2 💖
RFC 6781 is the spec you need for running DNSSEC day to day, and I'm obsessed 😭🎀
- Stream: IETF (Internet Engineering Task Force) 🌸
- Authors: O. Kolkman, W. Mekking, and R. Gieben. Kolkman and Mekking are from NLnet Labs, and Gieben is from SIDN Labs 👑
- Category: Informational, so it's published for info and it's not a standards-track spec 🔍
- ISSN: 2070-1721 🧾
- Date: December 2012 📅
- Obsoletes: RFC 4641 🦋
- Updates: nothing listed 🫶
Abstract
Okay so this doc is all about how to actually run the DNS with security extensions (DNSSEC) without it going sideways 💅 The main audience is zone administrators who are deploying DNSSEC, aka the people in charge of the zones 🧚
It's giving operations. It covers the stuff you deal with around keys and signatures in the DNS: making keys, storing them, generating signatures, doing key rollovers, and the policies that go with all of it 🔑
This one obsoletes RFC 4641 because it covers more operational ground and has more up-to-date requirements on key sizes and DNSSEC operations 🎀
Status of This Memo
This is not an Internet Standards Track spec. It's published for informational purposes only 🌸
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community ✨ It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document approved by the IESG is a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for that 🔥
For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6781 💜
Copyright Notice
Copyright (c) 2012 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, as in effect on the date it was published (http://trustee.ietf.org/license-info). Please read these carefully, because they spell out your rights and restrictions for this document 🧐 Code Components pulled from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🖤
Heads up: this document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Without an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🚨
Table of Contents
1. Introduction ....................................................4
1.1. The Use of the Term 'key' ..................................5
1.2. Time Definitions ...........................................6
2. Keeping the Chain of Trust Intact ...............................6
3. Key Generation and Storage ......................................7
3.1. Operational Motivation for Zone Signing Keys and
Key Signing Keys ...........................................8
3.2. Practical Consequences of KSK and ZSK Separation ..........10
3.2.1. Rolling a KSK That Is Not a Trust Anchor ...........10
3.2.2. Rolling a KSK That Is a Trust Anchor ...............11
3.2.3. The Use of the SEP Flag ............................12
3.3. Key Effectivity Period ....................................12
3.4. Cryptographic Considerations ..............................14
3.4.1. Signature Algorithm ................................14
3.4.2. Key Sizes ..........................................14
3.4.3. Private Key Storage ................................16
3.4.4. Key Generation .....................................17
3.4.5. Differentiation for 'High-Level' Zones? ............17
4. Signature Generation, Key Rollover, and Related Policies .......18
4.1. Key Rollovers .............................................18
4.1.1. Zone Signing Key Rollovers .........................18
4.1.1.1. Pre-Publish Zone Signing Key Rollover .....19
4.1.1.2. Double-Signature Zone Signing Key Rollover 21
4.1.1.3. Pros and Cons of the Schemes ..............23
4.1.2. Key Signing Key Rollovers ..........................23
4.1.2.1. Special Considerations for RFC 5011
KSK Rollover ..............................26
4.1.3. Single-Type Signing Scheme Key Rollover ............26
4.1.4. Algorithm Rollovers ................................28
4.1.4.1. Single-Type Signing Scheme
Algorithm Rollover ........................32
4.1.4.2. Algorithm Rollover, RFC 5011 Style ........32
4.1.4.3. Single Signing Type Algorithm
Rollover, RFC 5011 Style ..................33
4.1.4.4. NSEC-to-NSEC3 Algorithm Rollover ..........34
4.1.5. Considerations for Automated Key Rollovers .........34
4.2. Planning for Emergency Key Rollover .......................35
4.2.1. KSK Compromise .....................................35
4.2.1.1. Emergency Key Rollover Keeping the
Chain of Trust Intact .....................36
4.2.1.2. Emergency Key Rollover Breaking
the Chain of Trust ........................37
4.2.2. ZSK Compromise .....................................37
4.2.3. Compromises of Keys Anchored in Resolvers ..........38
4.2.4. Stand-By Keys ......................................38
4.3. Parent Policies ...........................................39
4.3.1. Initial Key Exchanges and Parental Policies
Considerations .....................................39
4.3.2. Storing Keys or Hashes? ............................40
4.3.3. Security Lameness ..................................40
4.3.4. DS Signature Validity Period .......................41
4.3.5. Changing DNS Operators .............................42
4.3.5.1. Cooperating DNS Operators .................42
4.3.5.2. Non-Cooperating DNS Operators .............44
4.4. Time in DNSSEC ............................................46
4.4.1. Time Considerations ................................46
4.4.2. Signature Validity Periods .........................48
4.4.2.1. Maximum Value .............................48
4.4.2.2. Minimum Value .............................49
4.4.2.3. Differentiation between RRsets ............50
5. "Next Record" Types ............................................51
5.1. Differences between NSEC and NSEC3 ........................51
5.2. NSEC or NSEC3 .............................................52
5.3. NSEC3 Parameters ..........................................53
5.3.1. NSEC3 Algorithm ....................................53
5.3.2. NSEC3 Iterations ...................................53
5.3.3. NSEC3 Salt .........................................54
5.3.4. Opt-Out ............................................54
6. Security Considerations ........................................54
7. Acknowledgments ................................................55
8. Contributors ...................................................55
9. References .....................................................56
9.1. Normative References ......................................56
9.2. Informative References ....................................56
Appendix A. Terminology ...........................................59
Appendix B. Typographic Conventions ...............................61
Appendix C. Transition Figures for Special Cases of Algorithm
Rollovers .............................................64
Appendix D. Transition Figure for Changing DNS Operators ..........68
Appendix E. Summary of Changes from RFC 4641 ......................701. Introduction ✨
This doc explains how to run a DNS Security (DNSSEC)-enabled environment 🔐 It's for operators who already know the DNS (see RFC 1034 [RFC1034] and RFC 1035 [RFC1035]) and want to deploy DNSSEC (RFC 4033 [RFC4033], RFC 4034 [RFC4034], RFC 4035 [RFC4035], and RFC 5155 [RFC5155]). The focus is on serving authoritative DNS info, and it's aimed at zone owners, name server operators, registries, registrars, and registrants 🧚 It assumes there's no direct relationship between those folks and the operators of validating recursive name servers (validators) 🙈
Operators and sysadmins have been learning a ton from workshops and early real-world deployments about running the DNS with security extensions (DNSSEC) 🧠 This doc turns those lessons into practices for zone administrators 💅 The DNS Root has been signed since July 15, 2010, and now more than 80 secure delegations are provisioned in the root. But at the time of writing there's still relatively little production experience with DNSSEC below the Top-Level Domain (TLD) level 👀 So this document should explicitly not be seen as representing 'Best Current Practices' 🙅♀️ Instead, it describes the decisions that should be made when deploying DNSSEC, gives the choices available for each one, and provides some operational guidelines. It does not give strong recommendations. That might be the subject of a future version 🔮
Not Best Current Practices, just the decisions, the options, and some guidelines. Read it as a map, not a rulebook 🗺️
The procedures here are focused on maintaining signed zones, meaning signing and publishing zones on authoritative servers 📝 Maintenance stuff like re-signing or key rollovers is meant to be transparent to any verifying clients ✨
Here's the structure. Section 2 talks about why keeping the "chain of trust" intact matters 🔗 Key generation and storage are in Section 3, and the focus there is mostly on keeping the private part of the key(s) secure 🔒 Section 4 covers considerations about the public part of the keys 🔑 Sections 4.1 and 4.2 deal with rollover, or replacing keys 🔄 Section 4.3 looks at how parents handle their children's public keys so chains of trust stay intact 👨👩👧 Section 4.4 covers all kinds of timing issues around key publication ⏰ And Section 5 covers how to choose and use the NSEC or NSEC3 [RFC5155] Resource Record 💖
The typographic conventions are explained in Appendix B 📖
Since we're describing operational suggestions and there are no protocol specifications, the RFC 2119 [RFC2119] language doesn't apply to this document. We do quote other documents that include the RFC 2119 language, though 🙈
This document obsoletes RFC 4641 [RFC4641] 🦋
Part 1 of 15 is done, bestie 🎀 Part 2 is next and it's about to get spicy 🌶️🔥
1.1. The Use of the Term 'key' 🔑
Okay so, this doc assumes you already get asymmetric cryptography, aka public-key cryptography, which is the whole foundation DNSSEC is built on (see the definition of 'asymmetric cryptography' in RFC 4949 [RFC4949]) 💅. That means we're gonna use the word 'key' kinda loosely ✨. When it says 'a key is used to sign data', just know it's the private part of the key pair doing the signing 🔐. The public part gets published in the DNSKEY Resource Record (DNSKEY RR), and it's the public part that's used for signature verification 🫶.
1.2. Time Definitions ⏰
We're gonna be throwing around a few time-related terms, so here's the tea:
- Signature validity period: The period when a signature is valid 💖. It starts at the (absolute) time in the signature inception field of the RRSIG RR and ends at the (absolute) time in the expiration field of the RRSIG RR. The doc sometimes says 'validity period' too, and it means the exact same thing ✨.
- Signature publication period: The period when a signature is published 📣. It starts the first time the signature gets introduced into the zone, and it ends when the signature is removed or replaced with a new one. Here's the kicker: after you stop publishing an RRSIG in a zone, it can take a while before it's expired from caches and actually gone from the DNS 👀.
- Key effectivity period: The stretch of time a key pair is expected to be effective 🗓️. It's the time from the earliest inception time stamp to the last expiration date of any signature made with this key, no matter if the key got used in a messy, on-and-off way in between 🌸. A key effectivity period can span multiple signature validity periods, so it's literally bigger than one signature's lifetime 🦋.
- Maximum/Minimum Zone Time to Live (TTL): The max or min value of the TTLs across the complete set of RRs in a zone, which validators or resolvers use 🧚. Note that the minimum TTL is not the same thing as the MINIMUM field in the SOA RR 🙈. For more on that, check RFC 2308 [RFC2308] 🎀.
2. Keeping the Chain of Trust Intact 🔗
Okay, this part is SO important bestie 😭. Keeping a valid chain of trust matters because when the chain breaks, data gets marked as Bogus (as defined in RFC 4033 [RFC4033] Section 5), and that can make entire (sub)domains basically invisible to verifying clients 💀. So zone admins really need to realize that, from the verifying clients' point of view, their zone is one link in a chain of trust 🔥.
Like we mentioned in the intro, all these procedures are meant to make things like re-signing or key rollovers totally transparent to verifying clients out on the Internet ✨.
Also, admins have to remember that data published on an authoritative primary server won't be seen by verifying clients right away 🕰️. It can take some time to get transferred to other (secondary) authoritative name servers, and clients might be pulling data from caching non-authoritative servers 🙃. Here's the lowkey useful part: the delay before data shows up on the slave can be basically negligible when you're using NOTIFY [RFC1996] and Incremental Zone Transfer (IXFR) [RFC1995] 🚀. It gets longer when you use Authoritative (full) Zone Transfers (AXFRs) together with NOTIFY 📈. And it gets even longer if you're relying on full zone transfers that are based only on the SOA timing parameters for refresh 😬.
For verifying clients, it's a big deal that data from secured zones can be used to build chains of trust, no matter whether it came straight from an authoritative server, a caching name server, or some middle box 🎁. Zone admins can only make sure the data needed for verification can actually be obtained by carefully using the available timing parameters 💅.
Maintaining the chain of trust is a shared responsibility among the admins of every secured zone in the chain 🫂. This is most obvious during a 'key compromise', when you have to make a tradeoff between keeping the chain of trust valid and replacing the compromised keys ASAP 😤. Then zone admins have to pick: keep the chain of trust intact (which lets attacks happen with the compromised key), or deliberately break the chain and make secured subdomains invisible to security-aware resolvers (also see Section 4.2) 💔.
3. Key Generation and Storage 🗝️
This section is all about the stuff you need to think through when using keys 🧠. When you're designing an operational procedure for key generation and storage, you've got a few decisions to make:
- Do you differentiate between Zone Signing Keys and Key Signing Keys, or is one type of key enough? 🤔
- Are Key Signing Keys (likely) in use as trust anchors [RFC4033]? ⚓
- What timing parameters are allowed by your operational requirements? ⏱️
- What cryptographic parameters fit your operational need? 🔐
The next section walks through the considerations you need to take into account when making those choices 💖.
3.1. Operational Motivation for Zone Signing Keys and Key Signing Keys 🧩
Here's a fun fact: the DNSSEC validation protocol doesn't distinguish between different types of DNSKEYs at all 🙅♀️. Any reasons to split keys up are purely operational, since validators won't even notice the difference 🫠.
For operational reasons (more on those below), you can choose one or more keys to have the role of Key Signing Keys (KSKs) 👑. These keys will only sign the apex DNSKEY RRset in a zone 🏰. Other keys can sign all the other RRsets in a zone that need signatures, and those are called Zone Signing Keys (ZSKs) 🧚. When there's no KSK/ZSK split, meaning the keys are both KSK and ZSK, we call that a Single-Type Signing Scheme ✨.
If the two jobs are separated, then for pretty much any key management and zone signing method, the KSK gets used way less often than the ZSK 🌙. Once a DNSKEY RRset is signed with the KSK, all the keys in that RRset can be used as ZSKs 🎀. If something happens that makes a ZSK more likely to be compromised, you can just replace it with a ZSK rollover 🔄. The new RRset then gets re-signed with the KSK 💅.
Changing a key that's a Secure Entry Point (SEP) [RFC4034] for a zone can be a whole process 😩, because it involves third parties. If a key is only pointed to by a Delegation Signer (DS) [RFC4034] record in the parent zone, you have to finish the interaction with the parent and then wait for the updated DS record to show up in the DNS ⏳. If a key is configured as a trust anchor, you have to wait until you're confident that all the trust anchors have been replaced 🫣. And honestly, you might not be able to reach your whole user-base with info about the key rollover 🥲.
Assuming the SEP flag is set for KSKs, you can tell a KSK apart from a ZSK by looking at the flag field in the DNSKEY RR 🔍. If the flag field is an odd number, it's a KSK; otherwise, it's a ZSK 🧮.
Keys can also get compromised through theft or loss 🚨. For keys installed on file-systems of name servers connected to the network (e.g., for dynamic updates), that risk is pretty high 📡. Where keys are stored on Hardware Security Modules (HSMs) or kept off-line, the risk is way lower 🔒. But storing keys off-line or with tighter access control hurts your operational flexibility 😵💫. By splitting the KSK and ZSK functions, you can manage these risks while weighing the tradeoff against the costs 💜. For example, a KSK can be stored off-line or with tighter access control than ZSKs, which need to be readily available for day-to-day stuff like adding or deleting zone data 📝. A KSK on a smartcard kept in a safe, paired with a ZSK on a file-system that operators can access for routine use, might give better protection against key compromise without losing much flexibility 🦋. Also, some HSMs let you keep your keys online, which gives more protection while barely affecting flexibility 🙌. In those cases, a KSK-ZSK split isn't any more beneficial than a Single-Type Signing Scheme 🤷♀️.
It's worth mentioning that there's not much point in obsessively protecting the key if you don't protect the zone files, which also live on the file-systems 🙈.
Last but not least, there's a risk of cryptanalysis of the key material 🧪. The cost of that kind of analysis depends on the length of the key 📏. But cryptanalysis arguments don't give a strong motivation for a KSK/ZSK split 💅. Say you do split them, and the KSK effectivity period is X times the ZSK effectivity period 📆. For the KSK and ZSK to have the same resistance to cryptanalysis, the KSK needs to be X times stronger than the ZSK 💪. Since X will practically always be somewhere on the order of 10 to 100, the key sizes for symmetric keys only differ by about a byte 🤏. When you translate that to asymmetric keys, the size difference is still too tiny to justify a key split, since it only marginally affects packet size and signing speed 🧁.
The arguments for splitting ZSK and KSK are weakest when:
- the exposure to risk is low (e.g., when keys are stored on HSMs) 🔐;
- you can be certain that a key is not used as a trust anchor 🙅;
- maintaining the various keys can't be done through tools (it's prone to human error) 🫠; and
- the interaction through the child-parent provisioning chain (especially the timely appearance of a new DS record in the parent zone in emergency situations) is predictable 📬.
If the above arguments hold, then the costs of a KSK-ZSK split's operational complexity may outweigh the costs of operational flexibility, so a Single-Type Signing Scheme is a reasonable option 💖. In other cases, we advise that KSKs and ZSKs get separated 🫶.
3.2. Practical Consequences of KSK and ZSK Separation 🧾
A key that acts only as a Zone Signing Key gets used to sign all the data except the DNSKEY RRset in a zone, on a regular basis 🔁. When you need to roll a ZSK, you don't need any interaction with the parent 🙌. That means a ZSK can have a relatively short key effectivity period ⚡.
A key with only the Key Signing Key role is used to sign the DNSKEY RRs in a zone 👑. If you need to roll a KSK, you might have to interact with other parties 😬. That can include the administrators of the parent zone, or administrators of verifying resolvers that have that particular key configured as secure entry points 🏰. In the latter case, everyone relying on the trust anchor needs to roll over to the new key 🫠, and that process might come with stability costs if automated trust anchor rollover mechanisms (e.g., RFC 5011 [RFC5011]) aren't in place 😰. So the key effectivity period of these keys can and should be made much longer 🌈✨.
3.2.1. Rolling a KSK That Is Not a Trust Anchor 🔄
okay so there are three schools of thought on rolling a KSK that isn't a trust anchor, and y'all, people are NOT agreed 💀
- rotate it frequently and regularly (maybe every few months) so a key rollover stays a totally normal, routine thing your ops team does ✨
- rotate it frequently but irregularly 🎲 "frequently" still means every few months, because rollovers are a practiced, common routine. "irregular" means a big jitter, so third parties don't get attached to the key and start thinking "ooh, I should configure this as my trust anchor" 🙈
- only roll it when it's known or strongly suspected to be compromised, or alongside operator change policies, like when you need a new algorithm or new key storage 🔐
there's no widespread agreement on which school is best for different DNSSEC deployments, and that's the tea ☕ every time a non-anchor KSK gets rolled there's a stability cost, but it can be pretty low if the child and parent are communicating well. the thing is, the only fully reliable way to know if that communication is good is to test it periodically 🧪. so rolling a KSK with a parent only happens for two reasons: to test and verify the rolling system so you're ready for an emergency, and in the case of (preventing) an actual emergency 🚨
and finally, a zone admin usually can't be 100% sure the zone's KSK isn't being used as a trust anchor somewhere 😬. configuring trust anchors isn't the zone admin's job, but the validator admin who (wrongly) set one up might face stability costs when the zone admin rolls a KSK. not fair, but that's life 💅
3.2.2. Rolling a KSK That Is a Trust Anchor ⚓
the same ops concerns apply to KSKs that are used as trust anchors. if a trust anchor replacement goes wrong, the entire domain that the trust anchor covers goes Bogus until it gets fixed. yikes 😭
in a huge number of cases it's safe to assume your keys aren't being used as trust anchors 🙌. if a zone admin publishes a DNSSEC signing policy and/or a DNSSEC practice statement [DNSSEC-DPS], that policy or statement should be clear about whether trust anchors get taken into account. there can be cases where local policies force trust anchors onto mission-critical zones, like in enterprises where the enterprise domain's trust anchor is configured in the enterprise's validator 🏢. zone admins are expected to know when that's going on, so no excuses 🫶
you could argue that since it's hard to get every user of a trust anchor to swap an old one for a new one, a KSK that's a trust anchor should never be rolled unless it's known or strongly suspected to be compromised 🥺. basically the costs of a KSK rollover are prohibitively high because some users just can't be reached.
BUT 🛑, the "operational habit" argument applies to trust anchor reconfiguration at clients' validators too! if the key has a short effectivity period and the trust anchor config has to be revisited regularly, people are less likely to forget about it 🧠✨. honestly the costs for those users can be minimized by automating the rollover with RFC 5011 [RFC5011] and rolling the key regularly (and advertising that you're doing it), so that validating resolver operators put the right mechanism in place to handle these stability costs. in other words: budget for these costs instead of getting blindsided by them 💸
so the vibe is: it's preferable to roll KSKs that are expected to be used as trust anchors on a regular basis if and only if those rollovers can be tracked using standardized mechanisms (like RFC 5011 [RFC5011]) 🎀
3.2.3. The Use of the SEP Flag 🏳️
the so-called SEP [RFC4035] flag can tell keys apart: it marks the key meant to be the secure entry point into the zone when building chains of trust. basically, these are the keys that are (or will be) pointed to by parental DS RRs or configured as a trust anchor 👑.
the SEP flag doesn't play any role in validation itself, but people use it for operational stuff, like the rollover mechanism in RFC 5011 [RFC5011] 🔁. the common convention is to set the SEP flag on any key used for key exchanges with the parent and/or potentially used as a trust anchor. so it's suggested that the SEP flag be set on keys used as KSKs and not on keys used as ZSKs. but if you don't split KSK and ZSK at all (a Single-Type Signing Scheme), it's suggested that the SEP flag be set on all keys 🌈
Note: some signing tools assume a KSK/ZSK split and use the presence (or absence) of the SEP flag to decide which key signs the zone data. these tools may get confused when a Single-Type Signing Scheme is used 💀
3.3. Key Effectivity Period ⏳
generally speaking, the available key length sets an upper limit on the key effectivity period 📏. for all practical purposes it's enough to define the effectivity period based on purely operational requirements and then match the key length to that value. ignoring the operational side, a reasonable effectivity period for KSKs with corresponding DS records in the parent zone is on the order of two decades or longer 🕰️. so if you don't plan to test the rollover procedure, the key should be effective essentially forever and only rolled in an emergency.
if you go for a regular key rollover, a reasonable effectivity period for KSKs that have a parent zone is one year, meaning you intend to replace them after 12 months 📅. the key effectivity period is just a policy parameter, so don't treat it as a constant. for example, the real effectivity period might be a bit longer than 12 months, because not every action needed to finish the rollover could get done in time 🙃
this annual rollover gives both zone and validator admins an operational practice for rollovers 🎉. plus, in most environments a year is easy to plan around and communicate, so it's a whole vibe 🗓️
where keys are stored online and the exposure to compromise is pretty high, an intended effectivity period of a month is reasonable for Zone Signing Keys 🖥️.
okay now the important bit 📣: very short effectivity periods are theoretically possible, but when you replace keys you have to take the rollover considerations from Sections 4.1 and 4.4 into account 👀. key replacement lasts for a couple of Maximum Zone TTLs, depending on the rollover scenario. so a multiple of Maximum Zone TTL durations is a reasonable lower limit on the key effectivity period. forcing a shorter one will result in an unnecessary and inconvenient DNSKEY RRset published in the zone, and nobody wants that 😩
the reason the ZSK's effectivity period should be shorter than the KSK's comes down to operations: operators are more likely to have frequent read access to the ZSK than to the KSK 👀. so where the ZSK can't get the same level of protection as the KSK (like when zone keys are kept online), and the risk of unauthorized disclosure of the ZSK's private key isn't negligible (e.g., when HSMs aren't in use), the ZSK's effectivity period should be kept shorter than the KSK's 🔒.
and honestly, if the risk of loss, theft, or other compromise is the same for a ZSK and a KSK, there's little reason to pick different effectivity periods for them. and when there's no ZSK/KSK split at all, this whole argument is redundant 🙄
there are definitely cases where a Single-Type Signing Scheme with a long key effectivity period is a good choice 💖, for example where the costs and risks of compromise, and the costs and risks of having to do an emergency roll, are low 🌸
3.4. Cryptographic Considerations 🔐
3.4.1. Signature Algorithm ✍️
at the time of writing, there are three types of signature algorithms you can use in DNSSEC: RSA, Digital Signature Algorithm (DSA), and GOST 🧁. more algorithms are in the making. all three are fully specified in lots of freely available documents and are widely considered patent-free 🆓. creating signatures with RSA and DSA takes roughly the same time, but DSA is about ten times slower at signature verification 🐢. also, in the context of DNSSEC, DSA is limited to a max of 1024-bit keys, so keep that in mind 📉
we suggest RSA/SHA-256 as the preferred signature algorithm and RSA/SHA-1 as an alternative 🥇🥈. both have pros and cons. RSA/SHA-1 has been deployed for years, while RSA/SHA-256 has only just started getting deployed. on the flip side, if effective attacks on either algorithm show up, they're expected to hit RSA/SHA-1 first 👀. and RSA/MD5 should not be considered for use, because it will very likely be the first common-use signature algorithm targeted by an effective attack 🚫
at the time of publication, the SHA-1 hash is known to have cryptanalysis issues, and work is in progress to fix them 🛠️. using public-key algorithms based on hashes stronger than SHA-1 (e.g., SHA-256) is recommended, if those algorithms are available in implementations (see RFC 5702 [RFC5702] and RFC 4509 [RFC4509]) 💜
also, at the time of publication, digital signature algorithms based on Elliptic Curve (EC) Cryptography for DNSSEC (GOST [RFC5933], Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6605]) are being standardized and implemented ✨. EC has size benefits 📦. on the other hand, you have to balance that against the number of validating resolver implementations that won't recognize EC signatures and will therefore treat the zone as insecure 😬. beyond noting that tradeoff, we won't discuss it further 🫡
3.4.2. Key Sizes 🔑
Okay so this bit assumes RSA keys, like the section before it suggested 💅
bestie, DNSSEC signing keys should be big enough to dodge every known cryptographic attack for the whole effectivity period of the key 🛡️ Despite huge efforts, nobody has broken a regular 1024-bit key 😭 The best completed attack is estimated to be the equivalent of a 700-bit key. An attacker breaking a 1024-bit signing key would need to burn through phenomenal amounts of networked computing power, in a way that would not be detected, just to break a single key. 🕵️♀️ So it is estimated that most zones can safely use 1024-bit keys for at least the next ten years. (A 1024-bit asymmetric key has an approximate equivalent strength of a symmetric 80-bit key.) ✨
Depending on local policy (for example, owners of keys used as extremely high value trust anchors, or non-anchor keys that may be difficult to roll over), it may be advisable to use lengths longer than 1024 bits. 👑 Typically, the next larger key size used is 2048 bits, which has the approximate equivalent strength of a symmetric 112-bit key (RFC 3766 [RFC3766]). Signing and verifying with a 2048-bit key takes longer than with a 1024-bit key. The increase depends on software and hardware implementations, but public operations (such as verification) are about four times slower, while private operations (such as signing) are about eight times slower. 🐢
Another way to decide on key size is to remember that the effort it takes an attacker to break a 1024-bit key is the same, no matter how the key is used. 🧠 If an attacker can break a 1024-bit DNSSEC key, they can also break one of the many 1024-bit Transport Layer Security (TLS) [RFC5246] trust anchor keys currently installed in web browsers. If a DNSSEC key is worth less to the attacker than a TLS trust anchor, the attacker will spend their resources attacking the latter. 💰
It is possible that attackers will unexpectedly get much better at breaking keys, and that such an improvement would make it feasible to break 1024-bit keys but not 2048-bit keys. 😳 If that happens, it is likely there will be a huge amount of publicity, particularly because of the large number of 1024-bit TLS trust anchors built into popular web browsers. At that time, all 1024-bit keys (both ones with parent zones and ones that are trust anchors) can be rolled over and replaced with larger keys. 🔄
Earlier documents (including the previous version of this document) urged the use of longer keys in situations where a particular key was "heavily used". 🙃 That advice may have been true 15 years ago, but it is not true today when using RSA algorithms and keys of 1024 bits or higher. 💅
3.4.3. Private Key Storage 🗝️
It is preferred that, where possible, zone private keys and the zone file master copy that is to be signed be kept and used only in off-line, non-network-connected, physically secure machines. 🏰 Periodically, an application can be run to add authentication to a zone by adding RRSIG and NSEC/NSEC3 RRs. Then the augmented file can be transferred to the master.
When relying on dynamic update [RFC3007] or any other update mechanism that runs at a regular interval to manage a signed zone, be aware that at least one private key of the zone will have to reside on the master server, or reside on an HSM to which the server has access. 😬 This key is only as secure as the amount of exposure the server gets to unknown clients, and as the level of security of the host. Although not mandatory, one could administer a zone using a "hidden master" scheme to minimize the risk. 🫣 In this arrangement, the master name server that processes the updates is unavailable to general hosts on the Internet; it is not listed in the NS RRset. The name servers in the NS RRset are able to receive zone updates through IXFR, AXFR, or an out-of-band distribution mechanism, possibly in combination with NOTIFY or another mechanism to trigger zone replication. 📬
The ideal situation is a one-way information flow to the network, so tampering from the network is avoided. Keeping the zone master on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. For maximum security, the master copy of the zone file should be off-net and should not be updated based on an unsecured network-mediated communication. 🚨
The ideal situation may not be achievable because of economic tradeoffs between risks and costs. For instance, keeping a zone file off-line is not practical, and it will increase the costs of operating a DNS zone. So, in practice, the machines on which zone files are maintained will be connected to a network. 🌐 Operators are advised to take security measures to shield the master copy against unauthorized access, in order to prevent modification of DNS data before it is signed. 🛡️
Similarly, the choice of storing a private key in an HSM will be influenced by a tradeoff between various concerns:
- The risks that an unauthorized person has unnoticed read access to the private key.
- The remaining window of opportunity for the attacker.
- The economic impact of the possible attacks (for a TLD, that impact will typically be higher than for an individual user).
- The costs of rolling the (compromised) keys. (The cost of rolling a ZSK is lowest, and the cost of rolling a KSK that is in wide use as a trust anchor is highest.) 💸
- The costs of buying and maintaining an HSM.
For dynamically updated secured zones [RFC3007], both the master copy and the private key that is used to update signatures on updated RRs will need to be on-line. 🔌
3.4.4. Key Generation 🎲
Careful generation of all keys is a sometimes overlooked, but absolutely essential, element in any cryptographically secure system. 🥺 The strongest algorithms used with the longest keys are still of no use if an adversary can guess enough to shrink the likely key space so that it can be searched exhaustively. Technical suggestions for generating random keys can be found in RFC 4086 [RFC4086] and NIST SP 800-90A [NIST-SP-800-90A]. In particular, one should carefully assess whether the random number generator used during key generation adheres to these suggestions. Typically, HSMs tend to provide a good facility for key generation. 🔐
Keys with a long effectivity period are particularly sensitive, because they will represent a more valuable target and be subject to attack for a longer time than short-period keys. ⏳ It is preferred that long-term key generation occur off-line, in a manner isolated from the network via an air gap or, at a minimum, high-level secure hardware. 🧱
3.4.5. Differentiation for 'High-Level' Zones? 🤔
An earlier version of this document (RFC 4641 [RFC4641]) made a differentiation between key lengths for KSKs used for zones high in the DNS hierarchy and those used lower down.
This distinction is now considered irrelevant. 🙅♀️ Longer key lengths for keys higher in the hierarchy are not useful, because the cryptographic guidance is that everyone should use keys that no one can break. Also, it is impossible to judge which zones are more or less valuable to an attacker. An attack can only take place if the key compromise goes unnoticed and the attacker can act as a man-in-the-middle (MITM). For example, if example.com is compromised, and the attacker forges answers for somebank.example.com. and sends them out during a MITM, then when the attack is discovered it will be simple to prove that example.com has been compromised, and the KSK will be rolled. 🔍
4. Signature Generation, Key Rollover, and Related Policies 🦋
4.1. Key Rollovers 🔄
Regardless of whether a zone uses periodic key rollovers or only rolls keys in case of an irregular event, key rollovers are a fact of life when using DNSSEC. 🫶 Zone administrators who are in the process of rolling their keys have to take into account the fact that data published in previous versions of their zone still lives in caches. When deploying DNSSEC, this becomes an important consideration; ignoring data that may be in caches may lead to loss of service for clients. 😱
The most pressing example of this occurs when zone material signed with an old key is being validated by a resolver that does not have the old zone key cached. If the old key is no longer present in the current zone, this validation fails, marking the data Bogus. 💀 Alternatively, an attempt could be made to validate data signed with a new key against an old key that lives in a local cache, which also results in the data being marked Bogus.
The typographic conventions used in the diagrams below are explained in Appendix B. 🎀
4.1.1. Zone Signing Key Rollovers 🌸
If the choice to split ZSKs and KSKs has been made, then those two types of keys can be rolled separately, and ZSKs can be rolled without taking into account DS records from the parent or the configuration of such a key as the trust anchor. 🥳
For "Zone Signing Key rollovers", there are two ways to make sure that, during the rollover, data still cached can be verified with the new key sets, or newly generated signatures can be verified with the keys still in caches. 🧩 One scheme, described in Section 4.1.1.1, uses key pre-publication; the other uses double signatures, as described in Section 4.1.1.2. The pros and cons are described in Section 4.1.1.3. 💜
4.1.1.1. Pre-Publish Zone Signing Key Rollover 🎀
okay bestie, this section shows how to do a ZSK rollover without signing all the data in a zone twice 😭 It's called the "Pre-Publish key rollover" and it's lowkey iconic. If the old key gets compromised, the new key is already out there in the DNS, so the zone admin can switch over fast and yeet the compromised key from the zone 💅 Another big win is that the zone size doesn't double, which is not the case with the Double-Signature ZSK rollover.
A Pre-Publish key rollover from DNSKEY_Z_10 to DNSKEY_Z_11 has four stages ✨
------------------------------------------------------------
initial new DNSKEY new RRSIGs
------------------------------------------------------------
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_11(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10
DNSKEY_Z_11 DNSKEY_Z_11
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
------------------------------------------------------------
------------------------------------------------------------
DNSKEY removal
------------------------------------------------------------
SOA_3
RRSIG_Z_11(SOA)
DNSKEY_K_1
DNSKEY_Z_11
RRSIG_K_1(DNSKEY)
------------------------------------------------------------Figure 1: Pre-Publish Key Rollover
- initial: the zone starts out here. DNSKEY_K_1 is the Key Signing Key, and DNSKEY_Z_10 signs all the data in the zone, so it's the Zone Signing Key 🔑
- new DNSKEY: DNSKEY_Z_11 gets added to the key set 🌸 Nothing is signed with it yet, but that doesn't protect its public key from brute force attacks. The minimum length of this pre-roll phase is the time it takes for the data to propagate to the authoritative servers, plus the TTL value of the key set.
- new RRSIGs: now DNSKEY_Z_11 signs all the data in the zone, and every signature from DNSKEY_Z_10 is removed from the zone 🦋 DNSKEY_Z_10 stays published in the key set. That way, data that got loaded into caches during the "new DNSKEY" step can still be verified with key sets fetched from this version of the zone. The minimum time the key set with DNSKEY_Z_10 has to stay published is the time it takes for the zone data from the previous version to expire from old caches, meaning the time for this zone to propagate to all authoritative servers, plus the Maximum Zone TTL value of any of the data in the previous version of the zone.
- DNSKEY removal: DNSKEY_Z_10 gets removed from the zone 🧚 The key set, now only DNSKEY_K_1 and DNSKEY_Z_11, is re-signed with DNSKEY_K_1.
The scheme above can be simplified by always publishing the "future" key right after the rollover 💖 Here's how it looks with two rollovers. The future key is introduced in "new DNSKEY" as DNSKEY_Z_12, and then an even newer one, numbered 13, shows up in "new DNSKEY (II)":
initial new RRSIGs new DNSKEY
-----------------------------------------------------------------
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11
DNSKEY_Z_11 DNSKEY_Z_11 DNSKEY_Z_12
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
----------------------------------------------------------------
----------------------------------------------------------------
new RRSIGs (II) new DNSKEY (II)
----------------------------------------------------------------
SOA_3 SOA_4
RRSIG_Z_12(SOA) RRSIG_Z_12(SOA)
DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_11 DNSKEY_Z_12
DNSKEY_Z_12 DNSKEY_Z_13
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
----------------------------------------------------------------Figure 2: Pre-Publish Zone Signing Key Rollover, Showing Two Rollovers
Note that the key introduced during "new DNSKEY" isn't used for production yet 🌈 So its private key can be kept somewhere physically secure, and it doesn't need to be 'fetched' every time the zone gets signed 🔐
4.1.1.2. Double-Signature Zone Signing Key Rollover ✨
this section shows how to do a ZSK rollover with the double zone data signature scheme, which is aptly named "Double-Signature rollover" 👑
During the "new DNSKEY" stage, the new version of the zone file has to propagate to all authoritative servers, and the data sitting in (distant) caches has to expire. That takes at least the propagation delay plus the Maximum Zone TTL of previous versions of the zone 🕰️
A Double-Signature ZSK rollover has three stages 💅
----------------------------------------------------------------
initial new DNSKEY DNSKEY removal
----------------------------------------------------------------
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_10 DNSKEY_Z_10
DNSKEY_Z_11 DNSKEY_Z_11
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
----------------------------------------------------------------Figure 3: Double-Signature Zone Signing Key Rollover
- initial: the zone starts out here. DNSKEY_K_1 is the Key Signing Key, and DNSKEY_Z_10 signs all the data in the zone, so it's the Zone Signing Key 🔑
- new DNSKEY: DNSKEY_Z_11 gets introduced into the key set 🌷 All the data in the zone is signed with both DNSKEY_Z_10 and DNSKEY_Z_11. The rollover period has to keep going until all the data from version 0 of the zone (the version containing SOA_0) has been replaced on all secondary servers and has expired from remote caches. That takes at least the propagation delay plus the Maximum Zone TTL of version 0 of the zone.
- DNSKEY removal: DNSKEY_Z_10 gets removed from the zone, along with every signature made with it 🫶 The key set, now only containing DNSKEY_Z_11, is re-signed with DNSKEY_K_1 and DNSKEY_Z_11.
At every instance, RRSIGs from the previous version of the zone can be verified with the DNSKEY RRset from the current version, and the other way around too 🦋 The duration of the "new DNSKEY" phase and the period between rollovers should be at least the propagation delay to secondary servers plus the Maximum Zone TTL of the previous version of the zone.
Note that in this example we assumed, to keep things simple, that the zone wasn't modified during the rollover 🙈 In reality, new data can be introduced at any time during this period, as long as it's signed with both keys.
4.1.1.3. Pros and Cons of the Schemes 💜
- Pre-Publish key rollover: this rollover doesn't involve signing the zone data twice 🎉 Instead, the new key gets published in the key set before the actual rollover, which means it's available for cryptanalysis attacks. The small downside is that the process takes four stages. Also, the Pre-Publish scheme involves more parental work when used for KSK rollovers, as explained in Section 4.1.2.
- Double-Signature ZSK rollover: the catch here is that during the rollover the number of signatures in your zone doubles 😬 That may be prohibitive if you have very big zones. The upside is that it only takes three stages ⭐
4.1.2. Key Signing Key Rollovers ✨
okay so KSK rollovers follow the same vibe as ZSK rollovers 💅 but we can use a Double-Signature scheme to make sure old data (only the apex key set) in caches can still be verified with the new key set and the other way around 🫶 and since only the key set gets signed with a KSK, zone size considerations don't apply 🌸
ngl the big difference is that a KSK rollover needs the parent to be involved (and possibly trust anchors get replaced too) 😭 so you end up waiting around for that delay. main character energy of waiting 🙈
---------------------------------------------------------------------
initial new DNSKEY DS change DNSKEY removal
---------------------------------------------------------------------
Parent:
SOA_0 -----------------------------> SOA_1 ------------------------>
RRSIG_par(SOA) --------------------> RRSIG_par(SOA) --------------->
DS_K_1 ----------------------------> DS_K_2 ----------------------->
RRSIG_par(DS) ---------------------> RRSIG_par(DS) ---------------->
Child:
SOA_0 SOA_1 -----------------------> SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA)
DNSKEY_K_1 DNSKEY_K_1 ------------------>
DNSKEY_K_2 ------------------> DNSKEY_K_2
DNSKEY_Z_10 DNSKEY_Z_10 -----------------> DNSKEY_Z_10
RRSIG_K_1(DNSKEY) RRSIG_K_1 (DNSKEY) ---------->
RRSIG_K_2 (DNSKEY) ----------> RRSIG_K_2(DNSKEY)
---------------------------------------------------------------------
Figure 4: Stages of Deployment for a Double-Signature
Key Signing Key Rolloverhere's the play-by-play 🎀
- initial: the first version of the zone 🍓 the parental DS points to DNSKEY_K_1. before the rollover starts, the child has to check what the TTL is on the DS RR that points to DNSKEY_K_1. we need that during the rollover and call the value TTL_DS 🧚
- new DNSKEY: the zone admin makes a second KSK, DNSKEY_K_2 ✨ the key gets handed to the parent, and the child has to wait until a new DS RR pointing to DNSKEY_K_2 exists. once that DS RR is published on every server authoritative for the parent's zone, the zone admin waits at least TTL_DS so the old DS RR has expired from caches 💜
- DS change: the parent swaps DS_K_1 for DS_K_2 🦋
- DNSKEY removal: DNSKEY_K_1 is gone 👑
this whole scenario gives the child the job of keeping a valid chain of trust going 🫶 and it's built on the idea that the parent only has one DS RR (per algorithm) per zone. there's another option people have looked at 👀 using a trust relationship that's already set up, the interaction happens in-band, and the parent can signal when the child removes the keys. this one has periods where the parent has two DS RRs at the same time, and it's called a KSK Double-DS rollover, shown in Figure 5 🔥 it has some drawbacks for KSKs though, so we'll walk through the scheme first and then talk about those 💅
--------------------------------------------------------------------
initial new DS new DNSKEY DS removal
--------------------------------------------------------------------
Parent:
SOA_0 SOA_1 ------------------------> SOA_2
RRSIG_par(SOA) RRSIG_par(SOA) ---------------> RRSIG_par(SOA)
DS_K_1 DS_K_1 ----------------------->
DS_K_2 -----------------------> DS_K_2
RRSIG_par(DS) RRSIG_par(DS) ----------------> RRSIG_par(DS)
Child:
SOA_0 -----------------------> SOA_1 ---------------------------->
RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA) ------------------>
DNSKEY_K_1 ------------------> DNSKEY_K_2 ----------------------->
DNSKEY_Z_10 -----------------> DNSKEY_Z_10 ---------------------->
RRSIG_K_1 (DNSKEY) ----------> RRSIG_K_2 (DNSKEY) --------------->
--------------------------------------------------------------------
Figure 5: Stages of Deployment for a Double-DS
Key Signing Key Rolloverso when the child zone wants to roll 🦋 it tells the parent during the "new DS" phase and sends over the new key (or its DS) 💖 the parent publishes DS_K_1 and DS_K_2, pointing at DNSKEY_K_1 and DNSKEY_K_2 respectively. then during the rollover ("new DNSKEY" phase), which can kick off as soon as the new DS set has spread through the DNS, the child swaps DNSKEY_K_1 for DNSKEY_K_2 ✨ and if the old key has expired from caches, the parent can be told at the "DS removal" phase that the old DS record can be deleted 🧚
the downsides of this one 😭 during the "new DS" phase the parent can't check that DS_K_2 matches DNSKEY_K_2 using the DNS, because DNSKEY_K_2 isn't published yet. plus we end up with a "security lame" key (see Section 4.3.3) 💀 and last but not least, the child and parent have to talk in two steps. the "Double Signature" method only needs one interaction 🫶
4.1.2.1. Special Considerations for RFC 5011 KSK Rollover
the scenario above assumes the KSK isn't being used as a trust anchor and that validating name servers only depend on the parental DS record to establish the zone's security 🎀 if it's known that validating name servers have trust anchors configured, that has to be factored in. here we assume zone admins will deploy RFC 5011 [RFC5011] style rollovers 🌈
RFC 5011 style rollovers make key rollovers take longer 🥲 the key being removed has to be revoked first. so before the DNSKEY_K_1 removal phase, DNSKEY_K_1 has to stay published for one more Maximum Zone TTL with the REVOKE bit set 💜 the revoked key has to be self-signed, which means in this phase the DNSKEY RRset also gets signed with DNSKEY_K_1 ✨
4.1.3. Single-Type Signing Scheme Key Rollover
the rollover of a key in a Single-Type Signing Scheme has the same requirement as a KSK or ZSK rollover 🫶 during any stage, the chain of trust needs to keep validating for any combination of data in the zone, plus any data that might still be living in distant caches 🔥
there are two variants of this rollover 👑 and since people pick a Single-Type Signing Scheme for operational simplicity, we'll go through the most straightforward rollover scheme first 🧚
-------------------------------------------------------------------
initial new DNSKEY DS change DNSKEY removal
-------------------------------------------------------------------
Parent:
SOA_0 --------------------------> SOA_1 ---------------------->
RRSIG_par(SOA) -----------------> RRSIG_par(SOA) ------------->
DS_S_1 -------------------------> DS_S_2 --------------------->
RRSIG_par(DS_S_1) --------------> RRSIG_par(DS_S_2) ---------->
Child:
SOA_0 SOA_1 ----------------------> SOA_2
RRSIG_S_1(SOA) RRSIG_S_1(SOA) ------------->
RRSIG_S_2(SOA) -------------> RRSIG_S_2(SOA)
DNSKEY_S_1 DNSKEY_S_1 ----------------->
DNSKEY_S_2 -----------------> DNSKEY_S_2
RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) ---------->
RRSIG_S_2(DNSKEY) ----------> RRSIG_S_2(DNSKEY)
-------------------------------------------------------------------
Figure 6: Stages of the Straightforward Rollover
in a Single-Type Signing Scheme- initial: the parental DS points to DNSKEY_S_1, and every RRset in the zone is signed with DNSKEY_S_1 🍓
- new DNSKEY: a new key (DNSKEY_S_2) shows up, and all the RRsets get signed with both DNSKEY_S_1 and DNSKEY_S_2 ✨
- DS change: once the DNSKEY RRset with both keys has had time to reach distant caches (meaning the key set with only DNSKEY_S_1 has expired), the parental DS record can change 🦋
- DNSKEY removal: after the DS RRset containing DS_S_1 has expired from distant caches, DNSKEY_S_1 can come out of the DNSKEY RRset 👑
in this first variant, the new signatures and new public key get added to the zone 💖 once they've spread, the DS at the parent flips. if the old DS has expired from caches, the old signatures and old public key can be removed from the zone 🎀
okay but this rollover has a drawback 😩 it means double signatures over all data in the zone. so with zone size in mind 🙈 you can skip the signatures made with DNSKEY_S_2 at the "new DNSKEY" step. instead, the signatures made with DNSKEY_S_1 get replaced with signatures made with DNSKEY_S_2 in an extra stage between the "DS change" and "DNSKEY removal" steps: once the DS RRset containing DS_S_1 has expired from distant caches, the signatures can be swapped 🌸 and only after the new signatures made with DNSKEY_S_2 have propagated can the old public key DNSKEY_S_1 be removed from the DNSKEY RRset 💅
the second variant of the Single-Type Signing Scheme key rollover is the Double-DS rollover 🧚 in this one, a new DNSKEY goes into the key set and the new DS gets submitted to the parent. the new key isn't used to sign any RRsets yet. the signatures made with DNSKEY_S_1 get replaced with signatures made with DNSKEY_S_2 at the moment DNSKEY_S_2 and DS_S_2 have propagated 🦋
-----------------------------------------------------------------------
initial new DS new RRSIG DS removal
-----------------------------------------------------------------------
Parent:
SOA_0 SOA_1 -------------------------> SOA_2
RRSIG_par(SOA) RRSIG_par(SOA) ----------------> RRSIG_par(SOA)
DS_S_1 DS_S_1 ------------------------>
DS_S_2 ------------------------> DS_S_2
RRSIG_par(DS) RRSIG_par(DS) -----------------> RRSIG_par(DS)
Child:
SOA_0 SOA_1 SOA_2 SOA_3
RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_2(SOA) RRSIG_S_2(SOA)
DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1
DNSKEY_S_2 DNSKEY_S_2 DNSKEY_S_2
RRSIG_S_1 (DNSKEY) RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
-----------------------------------------------------------------------
Figure 7: Stages of Deployment for a Double-DS Rollover in a
Single-Type Signing Scheme4.1.4. Algorithm Rollovers 🦋
okay so there's a special kind of key rollover for switching signature algorithms 🔥. You might be adding a new one, removing an old one, or doing both. Extra steps are needed to keep integrity intact during this, so we'll do the generic case first and save the trust anchor and single-type key stuff for later 💅
There's a conservative approach and a liberal approach for algorithm rollover, and it all comes down to Section 2.2 of RFC 4035 [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).
The conservative approach reads this super strictly 👀. Every RRset needs a valid signature for every algorithm signaled by the zone apex DNSKEY RRset, and that includes RRsets sitting in caches. The liberal approach is looser and limits the rule to RRsets in the zone at the authoritative name servers. There's a reasonable argument that this is valid, because that section is a subsection of Section 2 ("Zone Signing") of RFC 4035 🧠
With the liberal approach, algorithm rollover is just as easy as a regular Double-Signature KSK rollover (Section 4.1.2) 💖 Note that the Double-DS KSK rollover method can't be used, since that would introduce a parental DS whose apex DNSKEY RRset hasn't been signed with the new algorithm 🙅
BUT, there are validator implementations known to follow the more conservative approach 😭 Doing a Double-Signature KSK algorithm rollover will temporarily make your zone look Bogus to them during the rollover. So this section lays out the stages of deployment and assumes the conservative approach 🫶
When adding a new algorithm, the signatures go first. After the TTL of the RRSIGs has expired and caches have dropped the old data covered by those signatures, the DNSKEY with the new algorithm can be added 🌸
After the new algorithm has been added, the DS record can be exchanged using Double-Signature KSK rollover ✨
When removing an old algorithm, the DS for that algorithm gets removed from the parent zone first, followed by the DNSKEY and the signatures in the child zone 💀
Figure 8 shows the steps:
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_K_1 ------------------------------------------------------->
RRSIG_par(DS_K_1) -------------------------------------------->
Child:
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
DNSKEY_K_2
DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10
DNSKEY_Z_11
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
new DS DNSKEY removal RRSIGs removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_K_2 ------------------------------------------------------>
RRSIG_par(DS_K_2) ------------------------------------------->
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_Z_10(SOA)
-------------------> RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
------------------->
-------------------> DNSKEY_K_2 DNSKEY_K_2
------------------->
-------------------> DNSKEY_Z_11 DNSKEY_Z_11
------------------->
-------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
Figure 8: Stages of Deployment during an Algorithm RolloverHere's what each stage is doing 🎀
- initial: the zone before any transition happens. The number of keys can vary, but every key (in DNSKEY records) for the zone uses the same algorithm.
- new RRSIGs: signatures made with the new key over all records in the zone get added, but the key itself doesn't yet. This step propagates the new-algorithm signatures out to caches. Skip it, and a resolver could grab the new DNSKEY RRset (with the new algorithm) while still holding RRsets in its cache signed only by the old DNSKEY RRset, meaning without the new algorithm 😬
- new DNSKEY: once the old data has expired from caches, the new key can be added to the zone.
- new DS: once the cache data for the old DNSKEY RRset has expired, the DS for the new key can be added to the parent zone, and the DS for the old key can be removed in that same step.
- DNSKEY removal: once the cache data for the old DS RRset has expired, the old algorithm can be removed. This time the old key has to go first, before the old signatures do.
- RRSIGs removal: once the cache data for the old DNSKEY RRset has expired, the old signatures can be removed during this step too.
The RRSIG for the DNSKEY RRset doesn't need to be pre-published, since those records travel together, and it doesn't need any special processing to keep them in sync ✨
Below, we cover a few special cases of algorithm rollovers 🧚
- Single-Type Signing Scheme Algorithm rollover: when there's no differentiation between ZSKs and KSKs (Section 4.1.4.1).
- RFC 5011 Algorithm rollover: when trust anchors can track the roll via RFC 5011 style rollover (Section 4.1.4.2).
- 1 and 2 combined: when a Single-Type Signing Scheme Algorithm rollover is performed RFC 5011 style (Section 4.1.4.3).
On top of the narrative below, these special cases show up in Figures 12, 13, and 14 in Appendix C 🌈
4.1.4.1. Single-Type Signing Scheme Algorithm Rollover 🍓
If one key acts as both ZSK and KSK, the same scheme and figure as above (Figure 8 in Section 4.1.4) applies. All DNSKEY_Z_* records from the table get removed, and all RRSIG_Z_* records get replaced with RRSIG_S_*. All DNSKEY_K_* records get replaced with DNSKEY_S_*, and all RRSIG_K_* records get replaced with RRSIG_S_*. The requirement to sign with both algorithms, and to make sure old RRSIGs have the chance to expire from distant caches before the new algorithm goes into the DNSKEY RRset, is still valid 🫶
This is shown in Figure 12 in Appendix C 💜
4.1.4.2. Algorithm Rollover, RFC 5011 Style 👑
Trust anchor algorithm rollover is almost as simple as a regular RFC 5011-based rollover 💅 However, the old trust anchor must be revoked before it gets removed from the zone.
The timeline (see Figure 13 in Appendix C) looks a lot like Figure 8 above, except that after the "new DS" step there's an extra step where the DNSKEY gets revoked. The details of that "revoke DNSKEY" step are in Figure 9 below 🦋
---------------------------------
revoke DNSKEY
---------------------------------
Parent:
----------------------------->
----------------------------->
----------------------------->
----------------------------->
Child:
SOA_3
RRSIG_Z_10(SOA)
RRSIG_Z_11(SOA)
DNSKEY_K_1_REVOKED
DNSKEY_K_2
DNSKEY_Z_11
RRSIG_K_1(DNSKEY)
RRSIG_K_2(DNSKEY)
---------------------------------
Figure 9: The Revoke DNSKEY State That Is Added to an Algorithm
Rollover when RFC 5011 Is in UseThere's one exception to the RFC 4035 requirement quoted in Section 4.1.4 above 🙈 All zone data must still be signed with an unrevoked key, but it's allowed to sign the key set with a revoked key. The slightly esoteric argument goes like this:
Resolvers that don't understand the RFC 5011 REVOKE flag will treat DNSKEY_K_1_REVOKED the same as if it were DNSKEY_K_1. In other words, they'll handle the revoked key as a normal key, so RRsets signed with it will validate. As a result, the signature matches the algorithm listed in the DNSKEY RRset 🧩
Resolvers that do implement RFC 5011 will remove DNSKEY_K_1 from their set of trust anchors. That's fine, because they've already added DNSKEY_K_2 as the new trust anchor. So algorithm 2 is the only signaled algorithm by now. That means we only need RRSIG_K_2(DNSKEY) to authenticate the DNSKEY RRset, and we're still compliant with Section 2.2 of RFC 4035: There must be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset ✨
4.1.4.3. Single Signing Type Algorithm Rollover, RFC 5011 Style 🌸
If you decide to do an RFC 5011 style rollover with a Single Signing Scheme key, it's worth noting that Section 2.1 of RFC 5011 says:
Once the resolver sees the REVOKE bit, it MUST NOT use this key as a trust anchor or for any other purpose except to validate the RRSIG it signed over the DNSKEY RRset specifically for the purpose of validating the revocation.
This means that once DNSKEY_S_1 is revoked, it can't be used to validate its signatures over non-DNSKEY RRsets 😭 So those RRsets should be signed with a shadow key, DNSKEY_Z_10, during the algorithm rollover. The shadow key can be removed at the same time the revoked DNSKEY_S_1 is removed from the zone. In other words, the zone has to temporarily fall back to a KSK/ZSK split model during the rollover 🧠
Put another way, the rule that every RRset needs at least one signature for each algorithm used in the DNSKEY RRset still applies. A different key with the same algorithm, other than the revoked key, has to sign the entire zone. So more operations are needed if the Single-Type Signing Scheme is in use. Before rolling the algorithm, a new key with the same algorithm as the key being considered for revocation has to be introduced. That key can then temporarily act as a ZSK during the algorithm rollover 🎀
Just like algorithm rollover RFC 5011 style, all zone data must still be signed with an unrevoked key, but it's permissible to sign the key set with a revoked key, using the same esoteric argument given in Section 4.1.4.2 💖
The lesson here is that a Single-Type Signing Scheme algorithm rollover using RFC 5011 is as complicated as its name makes it sound 😩 Reverting to a split-key scheme for the duration of the rollover may be the better move 👑
4.1.4.4. NSEC-to-NSEC3 Algorithm Rollover
Okay so this one is a special case bestie 💅 It's the rollover from an NSEC signed zone to an NSEC3 signed zone. Here, algorithm numbers are used to signal support for NSEC3, but they do not mandate the use of NSEC3 ✨ So NSEC records should stay in the zone until the rollover to the new algorithm has completed and the new DNSKEY RRset has populated distant caches, at the end of the "new DNSKEY" stage. 🫶
At that point, validators that haven't implemented NSEC3 will treat the zone as unsecured as soon as they follow the chain of trust to the DS that points to a DNSKEY of the new algorithm, while validators that support NSEC3 will happily validate using NSEC 🙈 Turning on NSEC3 can then happen during the "new DS" step: you increase the serial number, introduce the NSEC3PARAM record to signal that NSEC3-authenticated data related to denial of existence should be served, and re-sign the zone 🔥
In summary, an NSEC-to-NSEC3 rollover is an ordinary algorithm rollover where NSEC is used all the time, and only after that rollover finishes does NSEC3 need to be deployed. The procedures are also listed in Sections 10.4 and 10.5 of RFC 5155 [RFC5155] 🌸
4.1.5. Considerations for Automated Key Rollovers ✨
As keys must be renewed periodically, there's some motivation to automate the rollover process 🤖 Consider the following:
- ZSK rollovers are easy to automate, as only the child zone is involved. 🦋
- A KSK rollover needs interaction between the parent and child. Data exchange is needed to provide the new keys to the parent. Consequently, this data must be authenticated, and integrity must be guaranteed in order to avoid attacks on the rollover 😭
4.2. Planning for Emergency Key Rollover 🚨
This section is all about prep for a possible key compromise 🧚 It's advisable to have a documented procedure ready for those times when a key compromise is suspected or confirmed. Trust me, you do not want to be figuring this out in a panic 💀
When the private material of one of a zone's keys is compromised, an attacker can use it for as long as a valid trust chain exists. A trust chain remains intact for:
- as long as a signature over the compromised key in the trust chain is valid, and
- as long as the DS RR in the parent zone points to the (compromised) key signing the DNSKEY RRset, and
- as long as the (compromised) key is anchored in a resolver and is used as a starting point for validation (this is generally the hardest to update).
While a trust chain to a zone's compromised key exists, your namespace is vulnerable to abuse by anyone who has obtained illegitimate possession of the key 😤 Zone administrators have to decide whether abuse of the compromised key is worse than having data in caches that cannot be validated. If the zone administrator chooses to break the trust chain to the compromised key, data in caches signed with this key cannot be validated. However, if the zone administrator takes the path of a regular rollover, the malicious key holder can keep spoofing data so that it appears to be valid during the rollover. It's a whole dilemma, and it's giving high stakes 👑
4.2.1. KSK Compromise 🔑
A compromised KSK can be used to sign the key set of an attacker's version of the zone. That zone could be used to poison the DNS 💀
A zone containing a DNSKEY RRset with a compromised KSK is vulnerable as long as the compromised KSK is configured as the trust anchor, or a DS record in the parent zone points to it.
So when the KSK has been compromised, the trust anchor or the parent DS record should be replaced as soon as possible 🏃♀️ Whether to break the trust chain during the emergency rollover is local policy. The trust chain would be broken when the compromised KSK is removed from the child's zone while the parent still has a DS record pointing to the compromised KSK. The assumption is that there is only one DS record at the parent. If there are multiple DS records, this doesn't apply, although the chain of trust of this particular key is broken.
Note that an attacker's version of the zone still uses the compromised KSK, and the presence of the corresponding DS record in the parent would make the data in this zone appear valid. Removing the compromised key would make the attacker's version of the zone appear valid and the original zone appear as Bogus 😱 Therefore, we advise administrators not to remove the KSK before the parent has a DS record for the new KSK in place. Lowkey the most important tip in this whole section 💅
4.2.1.1. Emergency Key Rollover Keeping the Chain of Trust Intact 🦋
If you want to perform an emergency key rollover in a way that keeps the chain of trust intact, the timing of the KSK replacement is kind of critical ⏰ The goal is to remove the compromised KSK as soon as the new DS RR is available at the parent. This means making sure that the signature made with a new KSK over the key set that contains the compromised KSK expires just after the new DS appears at the parent. Expiration of that signature will cause that key set to expire from the caches.
The procedure goes like this:
- Introduce a new KSK into the key set, and keep the compromised KSK in the key set. Lower the TTL for DNSKEYs so that the DNSKEY RRset will expire from caches sooner.
- Sign the key set with a short validity period. The validity period should expire shortly after the DS is expected to appear in the parent and the old DSs have expired from caches. This provides an upper limit on how long the compromised KSK can be used in a replay attack.
- Upload the DS for this new key to the parent.
- Follow the procedure of the regular KSK rollover: wait for the DS to appear at the authoritative servers, and then wait as long as the TTL of the old DS RRs. If necessary, re-sign the DNSKEY RRset and modify/extend the expiration time.
- Remove the compromised DNSKEY RR from the zone, and re-sign the key set using your "normal" TTL and signature validity period ✨
An extra danger of a key compromise is that the compromised key could be used to fake a legit-looking DNSKEY/DS rollover and/or name server changes at the parent 🚩 When that happens, the domain may be in dispute. An authenticated, out-of-band, and secure notify mechanism to contact the parent is needed in this case 📣
Note that this is only a problem when the DNSKEY and/or DS records are used to authenticate communication with the parent.
4.2.1.2. Emergency Key Rollover Breaking the Chain of Trust 💔
There are two methods to perform an emergency key rollover in a way that breaks the chain of trust. The first method causes the child zone to appear Bogus to validating resolvers. The other causes the child zone to appear Insecure. Both are described below 🧐
With the method that makes the child zone appear Bogus to validating resolvers, the child zone replaces the current KSK with a new one and re-signs the key set. Next, it sends the DS of the new key to the parent. Only after the parent has placed the new DS in the zone is the child's chain of trust repaired. Note that until that point, the child zone is still vulnerable to spoofing: the attacker is still in possession of the compromised key that the DS points to 😬
An alternative method of breaking the chain of trust is removing the DS RRs from the parent zone altogether. As a result, the child zone becomes Insecure. After the DS has expired from distant caches, the keys and signatures are removed from the child zone, new keys and signatures are introduced, and finally, a new DS is submitted to the parent 🌈
4.2.2. ZSK Compromise 🔐
Because no interaction with the parent is required when a ZSK is compromised, the situation is less severe than with a KSK compromise, bestie 🌸 The zone must still be re-signed with a new ZSK as soon as possible. Since this is a local operation and requires no communication between the parent and child, it can be done fairly quickly ⚡ However, one has to take into account that, just as with a normal rollover, the immediate disappearance of the old compromised key may lead to verification problems. Also note that until the RRSIG over the compromised ZSK has expired, the zone may still be at risk.
4.2.3. Compromises of Keys Anchored in Resolvers 🧚
A key can also be pre-configured in resolvers as a trust anchor. If trust anchor keys are compromised, the administrators of resolvers using these keys should be notified of this fact. Zone administrators may consider setting up a mailing list to communicate the fact that a SEP key is about to be rolled over. This communication will of course need to be authenticated by some means, e.g., by using digital signatures 📨
End-users who have to update an anchored key should always verify the new key 🫶 New keys should be authenticated out-of-band, for example through the use of an announcement website that is secured using Transport Layer Security (TLS) [RFC5246] 🔒
4.2.4. Stand-By Keys 🫧
Stand-by keys are keys that are published in your zone but are not used to sign RRsets. There are two reasons someone would want stand-by keys: one is to speed up the emergency key rollover, and the other is to recover from a disaster that leaves your production private keys inaccessible 🆘
The way you deal with stand-by keys differs for ZSKs and KSKs. To make a stand-by ZSK, you need to publish its DNSKEY RR. To make a stand-by KSK, you need to get its DS RR published at the parent 💜
Assuming you have your normal DNS operation, to prepare stand-by keys you need to:
- Generate a stand-by ZSK and KSK. Store them safely in a location different from the place where the currently used ZSK and KSK are held.
- Pre-publish the DNSKEY RR of the stand-by ZSK in the zone.
- Pre-publish the DS of the stand-by KSK in the parent zone.
Now suppose a disaster occurs and disables access to the currently used keys. To recover from that situation, follow these procedures:
- Set up your DNS operations and introduce the stand-by KSK into the zone.
- Post-publish the disabled ZSK and sign the zone with the stand-by keys.
- After some time, when the new signatures have propagated, the old keys, old signatures, and the old DS can be removed.
- Generate a new stand-by key set at a different location and continue "normal" operation 🌟
4.3. Parent Policies 🎀
4.3.1. Initial Key Exchanges and Parental Policies Considerations ✨
Okay bestie, first up is the initial key exchange 🔑. It is always subject to the policies the parent sets 👑. This matters SO much in a registry-registrar-registrant setup, where a registry runs the parent zone and the registrant (the person using the child-domain name) deals with the registry through a middle-person called a registrar 💌 (see [RFC3375] for the full official definition). The key material gets passed from the DNS operator to the parent through a registrar 📨. The registrant picks both the DNS operator and the registrar, and they could totally be different organizations 🏢. When you're designing a key exchange policy, keep in mind that the authentication and authorization mechanisms used during a key exchange should be as strong as the ones used for swapping delegation info between parent and child 🔐. So basically, DNSSEC doesn't implicitly need the authentication process to be stronger than regular DNS already is 💅.
Using the DNS itself as the source for the actual DNSKEY material is so smart because it cuts down on user error 🙌. A DNSKEY query tool can use the SEP bit [RFC4035] to pick the right key(s) out of a DNSSEC key set, so there's less chance of sending the wrong DNSKEY 🎯. It can also validate the self-signature over a key, which checks that the sender actually owns the private key material 🗝️. Fetching the DNSKEY from the DNS keeps the chain of trust intact once the parent publishes the DS RR saying the child is secure 🔗✨.
Note: Out-of-band verification is still needed when the key material is fetched for the first time, even via DNS. The parent can never be sure whether or not the DNSKEY RRs have been spoofed. 😭
With some types of key rollovers, the DNSKEY isn't pre-published, so a DNSKEY query tool can't retrieve the successor key 🙈. In that situation, the out-of-band method is required. This also lets the child figure out the digest algorithm of the DS record 🧐.
4.3.2. Storing Keys or Hashes? 🗄️
When you're designing a registry system, think about whether to store the DNSKEYs and/or the matching DSs 🤔. A child zone might want a DS published using a message digest algorithm the registry doesn't understand yet, so the registry can't count on being able to generate the DS from a raw DNSKEY 😬. That's why we suggest registry systems should be able to store DS RRs, even if they also store DNSKEYs 💾 (see also "DNSSEC Trust Anchor Configuration and Maintenance" [DNSSEC-TRUST-ANCHOR]).
Storage also ties into the customer interface and how data moves between the registrant and registry 📦. Will the child-zone administrator be able to upload DS RRs with unknown hash algorithms, or does the interface only allow DNSKEYs? When registries support the Extensible Provisioning Protocol (EPP) [RFC5910], it can be used for registrar-registry interactions, since that protocol lets you transfer both DS and, optionally, DNSKEY RRs 🚚. There's no standardized way to move data between the customer and the registrar 🙃. Different registrars do their own thing, from simple web interfaces to various APIs 🌐. In some cases, the DNSSEC extensions to EPP may be applicable ✨.
Having an out-of-band mechanism such as a registry directory (e.g., Whois) to find out which keys generate DS Resource Records for specific owners and/or zones may also help with troubleshooting 🔍.
4.3.3. Security Lameness 🦆
Security lameness is when the parent has a DS RR pointing to a nonexistent DNSKEY RR 💀. It can happen temporarily during a Double-DS rollover scheme. But care should be taken that not all DS RRs are pointing to a nonexistent DNSKEY RR, which will cause the child's zone to be marked Bogus by verifying DNS clients 🚨.
As part of a comprehensive delegation check, the parent could, at key exchange time, verify that the child's key is actually configured in the DNS 🕵️. However, if a parent doesn't understand the hashing algorithm the child uses, the parental checks are limited to only comparing the key id 🆔.
Child zones should be very careful when removing DNSKEY material -- specifically, SEP keys -- for which a DS RR exists 🥺. Once a zone is "security lame", a fix (e.g., removing a DS RR) will take time to propagate through the DNS ⏳.
4.3.4. DS Signature Validity Period ⏰
Since the DS can be replayed as long as it has a valid signature, a short signature validity period for the DS RRSIG minimizes the time that a child is vulnerable if its KSK(s) get compromised 🛡️. But a validity period that's too short introduces the possibility that a zone gets marked Bogus if the signer is misconfigured 😱. There may not be enough time to fix problems before signatures expire (this is a generic argument; also see Section 4.4.2) 🫠. Something as mundane as zone administrator unavailability during weekends shows the need for DS signature validity periods longer than two days 📅. Just like any signature validity period, we suggest an absolute minimum for the DS signature validity period of a few days 💖.
The maximum signature validity period of the DS record depends on how long child zones are willing to be vulnerable after a key compromise 🤷♀️. On the other hand, shortening the DS signature validity period increases the operational risk for the parent 😬. Therefore, the parent may have a policy to use a signature validity period that is considerably longer than the child would hope for 👑.
A compromise between the policy/operational constraints of the parent and minimizing damage for the child may result in a DS signature validity period somewhere between a week and several months 🌈.
In addition to the signature validity period, which sets a lower bound on the number of times the zone administrator will need to sign the zone data and an upper bound on the time that a child is vulnerable after key compromise, there is the TTL value on the DS RRs 🧮. Shortening the TTL reduces the damage of a successful replay attack. It does mean that the authoritative servers will see more queries. But on the other hand, a short TTL lowers the persistence of DS RRsets in caches, thereby increasing the speed with which updated DS RRsets propagate through the DNS 🚀.
4.3.5. Changing DNS Operators 🧳
The parent-child relationship is often described in terms of a registry-registrar-registrant model, where a registry maintains the parent zone and the registrant (the user of the child-domain name) deals with the registry through an intermediary called a registrar [RFC3375] 💁. Registrants may outsource the maintenance of their DNS system, including the maintenance of DNSSEC key material, to the registrar or to another third party, referred to here as the DNS operator 🏠.
For various reasons, a registrant may want to move between DNS operators 🚪. How easy this move will be depends principally on the DNS operator they're moving away from (the losing operator), as the losing operator has control over the DNS zone and its keys 🔑. The following sections describe the two cases: where the losing operator cooperates with the new operator (the gaining operator), and where the two do not cooperate 🤝.
4.3.5.1. Cooperating DNS Operators 🤝
okay so in this scenario we're assuming the losing operator won't hand over any private key material to the gaining operator (that would be the easy mode, lol 💀) but is otherwise totally cooperative 🫶
in this setup the change can happen with a Pre-Publish ZSK rollover, where the losing operator pre-publishes the gaining operator's ZSK, combined with a Double-Signature KSK rollover. for that one, the two registrars swap public keys and each one independently makes a signature over those key sets. they combine the results and both publish them in their copy of the zone. once that's done, each operator can use their own private keys to sign their zone content during the transfer 💅
------------------------------------------------------------
initial | pre-publish |
------------------------------------------------------------
Parent:
NS_A NS_A
DS_A DS_A
------------------------------------------------------------
Child at A: Child at A: Child at B:
SOA_A0 SOA_A1 SOA_B0
RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
NS_A NS_A NS_B
RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS)
RRSIG_Z_A(NS)
DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A DNSKEY_K_A
DNSKEY_K_B DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
------------------------------------------------------------
re-delegation | post-migration |
------------------------------------------------------------
Parent:
NS_B NS_B
DS_B DS_B
------------------------------------------------------------
Child at A: Child at B: Child at B:
SOA_A1 SOA_B0 SOA_B1
RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA)
NS_A NS_B NS_B
NS_B RRSIG_Z_B(NS) RRSIG_Z_B(NS)
RRSIG_Z_A(NS)
DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A
DNSKEY_K_B DNSKEY_K_B DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
Figure 10: Rollover for Cooperating Operatorsin this figure, A is the losing operator and B is the gaining operator 🦋 RRSIG_Z is the RRSIG made by a ZSK, RRSIG_K is made with a KSK, and the A or B on the end tells you who produced the key pair. "Child at A" is how the zone content looks to the losing DNS operator, and "Child at B" is how it looks to the gaining one ✨
the zone starts out delegated from the parent to the name servers of operator A, and operator A signs everything with their own ZSK and KSK 🌸 the cooperating operator A pre-publishes the new NS record along with operator B's ZSK and KSK, including the RRSIG over the DNSKEY RRset made by operator B's KSK. operator B has to publish that same DNSKEY RRset too. once it has filled up the caches, the re-delegation can happen, which means changing the NS and DS records in the parent zone so they point to operator B. after every DNSSEC record tied to operator A has expired from the caches, operator B can stop publishing the keys and signatures that belong to operator A, and the same goes the other way around 🧚
the signature exchange has a couple of drawbacks, not gonna lie 🙈 it means more operational overhead, because the operators don't just have to swap public keys, they also have to swap the signatures over the new DNSKEY RRset. that drawback goes away if the Double-Signature KSK rollover is replaced with a Double-DS KSK rollover. check out Figure 15 in Appendix D for the diagram 🍓
so, if the registry and registrars allow DS records to be published that don't point to a published DNSKEY in the child zone, the Double-DS KSK rollover is the preferred option (see Figure 5), paired with the Pre-Publish ZSK rollover. this way there's no need to share KSK signatures between the operators, but both operators still have to publish each other's ZSKs 👑
4.3.5.2. Non-Cooperating DNS Operators 😤
okay this is where things get messy 😭 in the non-cooperating case, the losing operator might not cooperate at all and just leave the data in the DNS as it is. in extreme cases, the losing operator can get obstructive and publish a DNSKEY RR with a high TTL and a long signature validity period, so registrar A's DNSKEY could end up sitting in caches for (in theory at least) decades 💀
the problem shows up when a validator tries to validate with the losing operator's key, but there's no signature material made by the losing operator anywhere in the delegation path after the re-delegation from the losing operator to the gaining operator has happened. you could imagine a rollover where the gaining operator copies every RRSIG the losing operator made and publishes those alongside its own signatures, but that wouldn't let anyone change the zone content. and since a re-delegation happened, the NS RRset has changed by definition, so that plan just won't work 🙅♀️ on top of that, if zone transfers aren't allowed by the losing operator and NSEC3 is deployed in the losing operator's zone, the gaining operator can't be certain that all of the losing operator's RRSIGs have been copied.
so the only viable move for the registrant is to let their zone go Insecure for the duration of the change. the registry should be asked to remove the DS RR pointing to the losing operator's DNSKEY and to change the NS RRset so it points to the gaining operator. once that has spread through the DNS, the registry should be asked to insert the DS record pointing to the (newly signed) zone at operator B 🦋
some behaviours of resolver implementations can help with changing DNS operators, though 💖 things to keep in mind:
- TTL sanity checking, as described in RFC 2308 [RFC2308], will limit the impact of the actions of an obstructive losing operator. resolvers that implement TTL sanity checking use an upper limit for TTLs on RRsets in responses.
- if RRsets at the zone cut (are about to) expire, the resolver restarts its search above the zone cut. otherwise, the resolver risks continuing to use a name server that the parent might have un-delegated 😬
- limiting how long DNSKEYs that seem unable to validate signatures stay cached, and/or trying to recover when DNSKEYs don't seem able to validate data, also reduces the effects of the non-cooperating registrar problem ✨
however, there's no operational methodology to work around this business issue, and proper contractual relationships between all the parties involved seem to be the only real solution 📜 it's worth noting that in many cases, broken delegations for a little while already happen when a zone switches from one DNS operator to another. and honestly, when operators change, the services that the zone references often change operators too, which can mean some downtime 🌧️
in any case, to keep these problems small, the classic setup is relatively short TTLs on all the involved Resource Records. that handles a lot of the trouble with zone changes, whether or not DNSSEC is in use 🌈
4.4. Time in DNSSEC ⏰
without DNSSEC, all times in the DNS are relative 🕰️ the SOA fields REFRESH, RETRY, and EXPIRATION are timers used to work out how much time has passed after a slave server synced with a master server. the TTL value and the SOA RR minimum TTL parameter [RFC2308] decide how long a forwarder should cache data (or negative responses) after fetching it from an authoritative server. by using a signature validity period, DNSSEC brings in the idea of absolute time in the DNS ⏳ signatures in DNSSEC have an expiration date, and once that passes the signature is marked invalid and the signed data is considered Bogus 🚫
the stuff in this section is all qualitative and focused on the operational and managerial side of things 💜 if you want a deeper, number-heavy dive into rollover timing parameters, check out "DNSSEC Key Timing Considerations" [DNSSEC-KEY-TIMING] 📚
4.4.1. Time Considerations ✨
okay so, signatures have expiration dates, which means you have to think about timing 🕰️ here's what to keep in mind:
- We suggest that the Maximum Zone TTL value of your zone data be smaller than your signature validity period. 💖
If the TTL duration was similar to that of the signature validity period, then all RRsets fetched during the validity period would be cached until the signature expiration time. Section 8.1 of RFC 4033 [RFC4033] suggests that "the resolver may use the time remaining before expiration of the signature validity period of a signed RRset as an upper bound for the TTL". So the query load on authoritative servers would spike at the signature expiration time, because that's also when records expire from caches all at once 😭
Having a TTL that is at least a few times smaller than your signature validity period helps avoid those query load peaks. 🦋
- We suggest that the signature publication period end at least one Maximum Zone TTL duration (but preferably a minimum of a few days) before the end of the signature validity period. 🎀
Re-signing a zone shortly before the signature validity period ends can make data expire from caches at the same time. That can lead to peaks in the load on authoritative servers 💀 To avoid this, schemes are deployed where the zone is periodically visited for a re-signing operation, and those signatures that are within a so-called Refresh Period from signature expiration get recreated. Also see Section 4.4.2 below. 🧚
If there's an operational error, you'd have one Maximum Zone TTL duration to fix it. Re-signing a zone a few days before the end of the signature validity period means the signatures will survive at least a (long) weekend during that kind of operational havoc. This is called the Refresh Period (see Section 4.4.2). 🌸
- We suggest that the Minimum Zone TTL be long enough to both fetch and verify all the RRs in the trust chain. In workshop environments, it has been demonstrated [NIST-Workshop] that a low TTL (under 5 to 10 minutes) caused disruptions because of the following two problems: 🙈
- During validation, some data may expire before the validation is complete. The validator should be able to keep all data until it is completed. This applies to all RRs needed to complete the chain of trust: DS, DNSKEY, RRSIG, and the final answers, i.e., the RRset that is returned for the initial query. 😤
- Frequent verification causes load on recursive name servers. Data at delegation points, DS, DNSKEY, and RRSIG RRs benefits from caching, so the TTL on those should be relatively long. Data at the leaves in the DNS tree has less impact on recursive name servers. 🍓
- Slave servers will need to be able to fetch newly signed zones well before the RRSIGs in the zone served by the slave server pass their signature expiration time. 🫶
When a slave server is out of sync with its master and the data in a zone is signed by expired signatures, it may be better for the slave server not to give out any answer. 🙅♀️
Normally, a slave server that can't contact a master server for an extended period will expire a zone. When that happens, the server responds differently to queries for that zone. Some servers issue SERVFAIL, whereas others turn off the AA bit in the answers. The time of expiration is set in the SOA record and is relative to the last successful refresh between the master and the slave servers. There is no coupling between the signature expiration of RRSIGs in the zone and the expire parameter in the SOA. 🤷♀️
If the server serves a DNSSEC-secured zone, the signatures may expire well before the SOA expiration timer counts down to zero. It is not possible to completely prevent this by modifying the SOA parameters. 😩
However, the effects can be minimized where the SOA expiration time is equal to or shorter than the Refresh Period (see Section 4.4.2). ✨
The consequence of an authoritative server not being able to update a zone for an extended period is that signatures may expire. In this case, non-secure resolvers keep being able to resolve data served by those slave servers, while security-aware resolvers run into problems because answers get marked as Bogus. 🚫
We suggest that the SOA expiration timer be approximately one third or a quarter of the signature validity period. That way, problems with transfers from the master server get noticed before signatures time out. 👀
We also suggest that operators of name servers that supply secondary services develop systems to identify upcoming signature expirations in the zones they slave, and take appropriate action where such an event is detected. 🛠️
When determining the value for the expiration parameter, one has to take the following into account: What are the chances that all secondaries expire the zone? How quickly can the administrators of the secondary servers be reached to load a valid zone? These questions aren't DNSSEC-specific, but they may influence the choice of your signature validity periods. 💅
4.4.2. Signature Validity Periods 🦋
4.4.2.1. Maximum Value 🌈
The first consideration for choosing a maximum signature validity period is the risk of a replay attack. For low-value, long-term stable resources, the risks may be minimal, and the signature validity period may be several months. Although signature validity periods of many years are allowed, the same "operational habit" arguments as those given in Section 3.2.2 play a role: When a zone is re-signed with some regularity, zone administrators stay conscious of the operational necessity of re-signing. 🧠
4.4.2.2. Minimum Value 🍓
The minimum value of the signature validity period is set by the time you'd like to survive an operational failure in provisioning. At what time will a failure be noticed, and at what time is action expected to be taken? By answering these questions, you can take into account the availability of zone administrators during (long) weekends or the time taken to access backup media. The result could easily suggest a minimum signature validity period of a few days. 📅
Note, however, that the argument above assumes that zone data has just been signed and published when the problem occurred. In practice, a zone may be signed according to a frequency set by the Re-Sign Period, where the signer visits the zone content and only refreshes signatures that are within a given amount of time (the Refresh Period) of expiration. The Re-Sign Period must be smaller than the Refresh Period in order for zone data to be signed in a timely fashion. ⏰
If an operational problem occurs during re-signing, the signatures in the zone that expire first are the ones that were generated longest ago. In the worst case, these signatures are the Refresh Period minus the Re-Sign Period away from signature expiration. 😵
To make things slightly more complicated, some signers vary the signature validity period over a small range (the jitter interval) so that not all signatures expire at the same time. 🎲
In other words, the minimum signature validity period is set by first choosing the Refresh Period (usually a few days), then defining the Re-Sign Period so that the Refresh Period minus the Re-Sign Period, minus the maximum jitter, sets the time in which operational havoc can be resolved. It's giving math, but it's also giving clarity 🧮💖
The relationship between signature times is illustrated in Figure 11.
Inception Signing Expiration
time time time
| | | | |
|------------------|---------------------------------|.....|.....|
| | | | |
+/-jitter
| Inception offset | |
|<---------------->| Validity Period |
| |<---------------------------------------->|
Inception Signing Reuse Reuse Reuse New Expiration
time time RRSIG time
| | | | | | |
|------------------|-------------------------------|-------|
| | | | | | |
<-----> <-----> <-----> <----->
Re-Sign Period
| Refresh |
|<----------->|
| Period |
Figure 11: Signature Timing ParametersNote that in the figure, the validity of the signature starts shortly before the signing time. That's done to deal with validators that might have some clock skew. This is called the inception offset, and it should be chosen so that false negatives are minimized to a reasonable level. 🫧
4.4.2.3. Differentiation between RRsets 💜
It is possible to vary signature validity periods between signatures over different RRsets in the zone. In practice, this could be done when zones contain highly volatile data (which may be the case in dynamic-update environments). Note, however, that the risk of replay (e.g., by stale secondary servers) should be the leading factor in determining the signature validity period, since the TTLs on the data itself are still the primary parameter for cache expiry. 🔥
In some cases, the risk of replaying existing data might be different from the risk of replaying the denial of data. In those cases, the signature validity period on NSEC or NSEC3 records may be tweaked accordingly. 🌸
When a zone contains secure delegations, a relatively short signature validity period protects the child against replay attacks in the case where the child's key is compromised (see Section 4.3.4). Since there is a higher operational risk for the parent registry when choosing a short validity period, and a higher operational risk for the child when choosing a long validity period, some (price) differentiation may occur for validity periods between individual DS RRs in a single zone. 💅
There seem to be no other arguments for differentiation in validity periods. 👑
5. "Next Record" Types ✨
okay so, when DNSSEC was being built, the team made a big design choice: they split signing and serving apart. 🍓 Servers don't do crypto while they're answering queries. That's iconic for performance, but it creates a problem. There are SO many names that don't exist sitting between the ones that do, so the zone needs records that cover all those gaps. 🧚
There are two ways to prove a name doesn't exist in DNSSEC: a clear-text way and an obfuscated-data way. ✨ Both of them:
- include a list of all the RRTYPEs present, which is how you prove a certain RRTYPE doesn't exist at a certain name 💅;
- store only the name the zone is authoritative for (so glue in the zone is left out) 🫶; and
- use a specific RRTYPE to hold the info about which RRTYPEs are at that name. Clear-text uses NSEC, and obfuscated-data uses NSEC3. 🦋
5.1. Differences between NSEC and NSEC3
ngl this is the tea. 🍵 The clear-text one (NSEC) is a sorted linked list of the names in the zone. NSEC3 is basically the same idea, except it first hashes the names with a one-way hash function and then builds the sorted linked list out of those hashed strings. 🔐
NSEC needs no crypto beyond checking its signature record. 💖 It's human readable too, so you can run manual queries and see if things are working. The downside is "zone walking": someone can ask for every entry in a zone just by following the linked list of NSEC RRs through the "Next Domain Name" field 😭. Everyone agrees DNS data is reachable through queries, but some zone admins find this unwanted for policy, regulatory, or other reasons, and honestly that's valid. 🙈
Also, NSEC needs a signature over every RR in the zone file, which means any denial of existence is cryptographically signed. ✨ BUT, in a big zone with lots of delegations where very few go to signed zones, that can add overhead nobody can handle, especially when the insecure delegations get updated a lot. (A typical example is a TLD operator with few registrants who use secure delegations.) 💀 NSEC3 lets the gap between two secure delegations "opt out", so it can contain one or more insecure delegations. That makes the zone smaller and less crypto-heavy, but you lose the ability to cryptographically deny the existence of names in that span. 🧚
The NSEC3 record uses a hashing method on the requested name. 🌸 To make guessing the zone's entries more work, you can set a number of hashing iterations in the NSEC3 record. You can also specify a salt, which changes the hashes too. 🎀 Heads up though: NSEC3 does NOT fully protect against info leaking from the zone. You can still work out the size of the zone, which RRTYPEs are in there, and so on. 👀
5.2. NSEC or NSEC3
the first reason to deploy NSEC3, which is preventing zone enumeration, only makes sense when the zone content isn't highly structured or trivially guessable. 🙃 Highly structured zones, like in-addr.arpa., ip6.arpa., and e164.arpa., can be trivially enumerated using ordinary DNS properties. And for small zones that only have records at the apex and a few common names like "www" or "mail", guessing the content and proving completeness is also trivial even with NSEC3. 💅 So in these cases, NSEC is preferred, because it's easier for signers and validating resolvers. ✨
For large zones where names are "not readily available", like the ones where you have to sign a non-disclosure agreement before getting the data, NSEC3 is preferred. 🔒 The second reason to think about NSEC3 is "Opt-Out", which can cut down how many NSEC3 records you need. We'll talk about it more below (Section 5.3.4). 🦋
5.3. NSEC3 Parameters
NSEC3 is controlled by a bunch of parameters, and some of them can be varied. This section is all about choosing those. 🎀
5.3.1. NSEC3 Algorithm
The NSEC3 hashing algorithm runs on the Fully Qualified Domain Name (FQDN) in its uncompressed form. 🧠 This means the brute force work an attacker does for one FQDN can't be reused for another one, because those entries are unique by definition. iconic. 👑
At the time of writing, there's only ONE NSEC3 hash algorithm defined. [RFC5155] specifically says: "When specifying a new hash algorithm for use with NSEC3, a transition mechanism MUST also be defined". 💖 So this document doesn't cover NSEC3 hash algorithm transition. 🌈
5.3.2. NSEC3 Iterations
One of the worries with NSEC3 is that someone could run a pre-calculated dictionary attack to check whether certain domain names exist in a zone. 😬 NSEC3 introduces two mechanisms to make those attacks more expensive: iterations and salt. ⭐
The iterations parameter defines how many additional times the hash function has been run. 🧚 A higher value means more resiliency against dictionary attacks, but it costs more computing for both the server and the resolver. 💜
RFC 5155 Section 10.3 [RFC5155] looks at the tradeoffs between the cost during signing and the cost to the validating name server, while still giving a reasonable barrier against dictionary attacks. 🤓 It offers useful iteration limits for a given RSA key size: 150 iterations for 1024-bit keys, 500 iterations for 2048-bit keys, and 2,500 iterations for 4096-bit keys. 🫶 The document says 100 iterations is a sufficiently costly, yet not excessive, value. In the worst-case scenario, name server performance would be halved, regardless of key size [NSEC3-HASH-PERF]. 📉
5.3.3. NSEC3 Salt
While iterations make hashing a dictionary word more expensive, the salt shortens how long a calculated hash can be used. ⏳ If the zone admin changes the salt value, an attacker loses all the pre-calculated work for that zone. 🙌
There must be a complete NSEC3 chain using the same salt value, and it has to match the salt value in the NSEC3PARAM record. 💅 Salt changes don't need special rollover procedures. But changing the salt means regenerating all the NSEC3 records, which means generating new RRSIGs over them. So it makes sense to line the salt change up with a Zone Signing Key change, since that process usually already means regenerating all the RRSIGs anyway. 🔄 If there's no critical dependency on incremental signing and the zone can be signed with little effort, you don't need to line them up. 🌸
5.3.4. Opt-Out
Opt-Out was introduced so signed records could be gradually added to zones that mostly contain delegation records. 🌱 Using the Opt-Out flag changes what an NSEC3 span means. Instead of authoritatively denying the existence of names inside the span, it becomes proof that DNSSEC isn't available for the delegations in that span. 🦋 That means you can add or remove the delegations covered by the span without recalculating or re-signing the RRs in the NSEC3 RR chain. 🎀
Opt-Out is only specified for use over delegation points, so it only helps zones with a large number of insecure delegations. 🍰 This typically applies to large TLDs and similar zones. In most other situations, Opt-Out should not be deployed. 🙅♀️ More considerations are in Section 12.2 of RFC 5155 [RFC5155]. 📚
6. Security Considerations 🔐
DNSSEC adds data origin authentication and data integrity to the DNS, using digital signatures over Resource Record sets. 💖 It does NOT protect against denial-of-service attacks, and it does NOT provide confidentiality. 😱 For more general DNSSEC security considerations, please see RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035]. 📖
This document tries to cover the operational considerations for keeping a DNSSEC service stable and secure. 🛡️ When you do key rollovers, remember it takes time for data to propagate to the verifying clients. It's also important to know that this data may be cached. ⚠️ If you ignore the 'data propagation' properties of the DNS, you can end up with validation failures, because cached data may not match the data fetched from the authoritative servers. That makes secured zones unavailable to security-aware resolvers. 💀 Please don't let this happen to your zone, bestie. 🫶
7. Acknowledgments 💜
Significant parts of the text in this document are copied from RFC 4641 [RFC4641]. That document was edited by Olaf Kolkman and Miek Gieben. Other people who contributed or were otherwise involved in that work were, in random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette, Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, Peter Koch, Mike StJohns, Emma Bretherick, Adrian Bedford, Lindy Foster, and O. Courtay. 🌸
For this version of the document, we'd like to acknowledge the people who were actively involved in putting it together. In random order: Mark Andrews, Patrik Faltstrom, Tony Finch, Alfred Hoenes, Bill Manning, Scott Rose, Wouter Wijngaards, Antoin Verschuren, Marc Lampo, George Barwood, Sebastian Castro, Suresh Krishnaswamy, Eric Rescorla, Stephen Morris, Olafur Gudmundsson, Ondrej Sury, and Rickard Bellgrim. 👑🎀
8. Contributors 🧚
Significant contributions to this document came from:
- Paul Hoffman, who contributed on the choice of cryptographic parameters and addressing some of the trust anchor issues 🔑;
- Jelte Jansen, who provided the initial text in Section 4.1.4 ✍️; and
- Paul Wouters, who provided the initial text for Section 5, and Alex Bligh, who improved it 💖.
The figure in Section 4.4.2 was adapted from the OpenDNSSEC user documentation. 🦋
9. References 📚
9.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC", RFC 5702,
October 2009.9.2. Informative References 📚
Okay bestie, these are the "extra reading" docs 🤓. Nothing here is strictly required, but they're the sources the spec leans on for the deeper stuff, so here's the full list:
[RFC1995]Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996. 🔁[RFC1996]Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996. 📣[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑[RFC2308]Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. 🗂️[RFC3007]Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. 🔄[RFC3375]Hollenbeck, S., "Generic Registry-Registrar Protocol Requirements", RFC 3375, September 2002. 🧾[RFC3766]Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. 💪[RFC4086]Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. 🎲[RFC4641]Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006. 🛠️[RFC4949]Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. 📖[RFC5011]StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007. 🪝[RFC5910]Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, May 2010. 🌐[RFC5933]Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5933, July 2010. ✍️[RFC6605]Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, April 2012. 🌙[NIST-Workshop]Rose, S., "NIST DNSSEC workshop notes", July 2001,<http://www.ietf.org/mail-archive/web/dnsop/current/msg01020.html>. 🏛️[NIST-SP-800-90A]Barker, E. and J. Kelsey, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST Special Publication 800-90A, January 2012. 🎰[RFC5246]Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 🔒[DNSSEC-KEY-TIMING]Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key Timing Considerations", Work in Progress, July 2012. ⏰[DNSSEC-DPS]Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A Framework for DNSSEC Policies and DNSSEC Practice Statements", Work in Progress, November 2012. 📝[DNSSEC-TRUST-ANCHOR]Larson, M. and O. Gudmundsson, "DNSSEC Trust Anchor Configuration and Maintenance", Work in Progress, October 2010. ⚓[NSEC3-HASH-PERF]Schaeffer, Y., "NSEC3 Hash Performance", NLnet Labs document 2010-002, March 2010. 🏎️
Appendix A. Terminology 🧚
Okay so this section is a jargon decoder ring 💍. A bunch of terms here are defined in other documents, but we didn't copy-paste those definitions. We wrote our own, more elaborate explanations instead. Heads up though: these explanations are not official, so the real definitions live in the source docs.
- Anchored key: A DNSKEY configured in resolvers around the globe. This key is hard to update, hence the term 'anchored'. ⚓
- Bogus: Also see Section 5 of RFC 4033 [RFC4033]. An RRset in DNSSEC is marked "Bogus" when a signature of an RRset does not validate against a DNSKEY. 🚩
- Key rollover: A key rollover (also called key supercession in some environments) is the act of replacing one key pair with another at the end of a key effectivity period. 🔄
- Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used exclusively for signing the apex key set. The fact that a key is a KSK is only relevant to the signing tool. 🔑
- Key size: The term 'key size' can be substituted by 'modulus size' throughout the document for RSA keys. It is mathematically more correct to use modulus size for RSA keys, but as this is a document directed at operators we feel more at ease with the term 'key size'. 📏
- Private and public keys: DNSSEC secures the DNS through the use of public-key cryptography. Public-key cryptography is based on the existence of two (mathematically related) keys, a public key and a private key. The public keys are published in the DNS by the use of the DNSKEY Resource Record (DNSKEY RR). Private keys should remain private. 🤫
- Refresh Period: The period before the expiration time of the signature, during which the signature is refreshed by the signer. 🔃
- Re-Sign Period: This refers to the frequency with which a signing pass on the zone is performed. The Re-Sign Period defines when the zone is exposed to the signer. And on the signer, not all signatures in the zone have to be regenerated: That depends on the Refresh Period. 🗓️
- Secure Entry Point (SEP) key: A KSK that has a DS record in the parent zone pointing to it or that is configured as a trust anchor. Although not required by the protocol, we suggest that the SEP flag [RFC4034] be set on these keys. 🚪
- Self-signature: This only applies to signatures over DNSKEYs; a signature made with DNSKEY x over DNSKEY x is called a self-signature. Note: Without further information, self-signatures convey no trust. They are useful to check the authenticity of the DNSKEY, i.e., they can be used as a hash. 🪞
- Signing jitter: A random variation in the signature validity period of RRSIGs in a zone to prevent all of them from expiring at the same time. 🎲
- Signer: The system that has access to the private key material and signs the Resource Record sets in a zone. A signer may be configured to sign only parts of the zone, e.g., only those RRsets for which existing signatures are about to expire. ✍️
- Singing the zone file: The term used for the event where an administrator joyfully signs its zone file while producing melodic sound patterns. 🎤🎶
- Single-Type Signing Scheme: A signing scheme whereby the distinction between Zone Signing Keys and Key Signing Keys is not made. 🧩
- Zone administrator: The 'role' that is responsible for signing a zone and publishing it on the primary authoritative server. 👩💻
- Zone Signing Key (ZSK): A key that is used for signing all data in a zone (except, perhaps, the DNSKEY RRset). The fact that a key is a ZSK is only relevant to the signing tool. 🌸
Appendix B. Typographic Conventions ✨
okay so bestie, this appendix is the cheat sheet for all the notation in this doc 🎀 once you know the shorthand, the signed zones stop looking like a wall of random base64 💖
Key notation: a key is written as DNSKEY_x_y, where x tells you what kind of key it is: K for Key Signing Key, Z for Zone Signing Key, and S when KSKs and ZSKs aren't being told apart and the key is just being used as a secure entry point 🔑 The y is a number or identifier, and you can think of it as the key id 🍓
RRsets ignored: if the signatures on non-DNSKEY RRsets have the same parameters as the SOA, we don't bother mentioning them 🙈 In the example further down, the SOA is signed with the same parameters as the foo.example.com A RRset, so that RRset gets ignored in the shorthand 💅
RRset notations: RRs only get labelled by their type. The owner, class, rdata and TTL are all dropped, so "example.com 3600 IN A 192.0.2.1" just becomes "A" ✨ An RRset is a list of RRs, so "A1, A2" means an RRset with two "A" records, and that can also get shortened to just "A" 🦋
Signature notation: signatures are written as RRSIG_x_y(type), which means the RRset of RRTYPE 'type' is signed with DNSKEY_x_y 🫶 Signatures made in the parent zone are written as RRSIG_par(type) 👑
SOA representation: SOAs are written as SOA_x, where x is the serial number 🌸
DS representation: DSs are written as DS_x_y, and the x and y work like the key notation 💜 x says what kind of key the DS record points at, and y is the 'key id' of that key 🧚
Zone representation: once we've used all of the above, we can squash a whole signed zone down by dropping every unnecessary detail, like the names, and writing all the data as "SOA_x" 🎀
Here's the signed zone we're going to shrink:
example.com. 3600 IN SOA ns1.example.com. olaf.example.net. (
2005092303 ; serial
450 ; refresh (7 minutes 30 seconds)
600 ; retry (10 minutes)
345600 ; expire (4 days)
300 ; minimum (5 minutes)
)
3600 RRSIG SOA 5 2 3600 20120824013000 (
20100424013000 14 example.com.
NMafnzmmZ8wevpCOI+/JxqWBzPxrnzPnSXfo
...
OMY3rTMA2qorupQXjQ== )
3600 NS ns1.example.com.
3600 NS ns2.example.com.
3600 NS ns3.example.com.
3600 RRSIG NS 5 2 3600 20120824013000 (
20100424013000 14 example.com.
p0Cj3wzGoPFftFZjj3jeKGK6wGWLwY6mCBEz
...
+SqZIoVHpvE7YBeH46wuyF8w4XknA4Oeimc4
zAgaJM/MeG08KpeHhg== )
3600 TXT "Net::DNS domain"
3600 RRSIG TXT 5 2 3600 20120824013000 (
20100424013000 14 example.com.
o7eP8LISK2TEutFQRvK/+U3wq7t4X+PQaQkp
...
BcQ1o99vwn+IS4+J1g== )
300 NSEC foo.example.com. NS SOA TXT RRSIG NSEC DNSKEY
300 RRSIG NSEC 5 2 300 20120824013000 (
20100424013000 14 example.com.
JtHm8ta0diCWYGu/TdrE1O1sYSHblN2i/IX+
...
PkXNI/Vgf4t3xZaIyw== )
3600 DNSKEY 256 3 5 (
AQPaoHW/nC0fj9HuCW3hACSGiP0AkPS3dQFX
...
sAuryjQ/HFa5r4mrbhkJ
) ; key id = 14
3600 DNSKEY 257 3 5 (
AQPUiszMMAi36agx/V+7Tw95l8PYmoVjHWvO
...
oy88Nh+u2c9HF1tw0naH
) ; key id = 15
3600 RRSIG DNSKEY 5 2 3600 20120824013000 (
20100424013000 14 example.com.
HWj/VEr6p/FiUUiL70QQWtk+NBIlsJ9mdj5U
...
QhhmMwV3tIxJk2eDRQ== )
3600 RRSIG DNSKEY 5 2 3600 20120824013000 (
20100424013000 15 example.com.
P47CUy/xPV8qIEuua4tMKG6ei3LQ8RYv3TwE
...
JWL70YiUnUG3m9OL9w== )
foo.example.com. 3600 IN A 192.0.2.2
3600 RRSIG A 5 3 3600 20120824013000 (
20100424013000 14 example.com.
xHr023P79YrSHHMtSL0a1nlfUt4ywn/vWqsO
...
JPV/SA4BkoFxIcPrDQ== )
300 NSEC example.com. A RRSIG NSEC
300 RRSIG NSEC 5 3 300 20120824013000 (
20100424013000 14 example.com.
Aaa4kgKhqY7Lzjq3rlPlFidymOeBEK1T6vUF
...
Qe000JyzObxx27pY8A== )and with all our shorthand, it squishes down to this 🫧
SOA_2005092303
RRSIG_Z_14(SOA_2005092303)
DNSKEY_K_14
DNSKEY_Z_15
RRSIG_K_14(DNSKEY)
RRSIG_Z_15(DNSKEY)The rest of the zone data has the same signature as the SOA record, i.e., an RRSIG created with DNSKEY_K_14. So if you've got that, you've got the whole zone 💀✨
Appendix C. Transition Figures for Special Cases of Algorithm Rollovers ✨
okay so this appendix is basically the storyboard 🎬 for the tricky algorithm rollover cases from Section 4.1.4. Each figure is a little timeline showing what the parent and child publish at each step, so you can see the whole dance at once 💃
The figures in this appendix complement and illustrate the special cases of algorithm rollovers as described in Section 4.1.4.
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_S_1 ------------------------------------------------------->
RRSIG_par(DS_S_1) -------------------------------------------->
Child:
SOA_0 SOA_1 SOA_2
RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_1(SOA)
RRSIG_S_2(SOA) RRSIG_S_2(SOA)
DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1
DNSKEY_S_2
RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY)
RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
----------------------------------------------------------------
new DS DNSKEY removal RRSIGs removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_S_2 ------------------------------------------------------>
RRSIG_par(DS_S_2) ------------------------------------------->
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_S_1(SOA)
-------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA)
------------------->
-------------------> DNSKEY_S_2 DNSKEY_S_2
-------------------> RRSIG_S_1(DNSKEY)
-------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
----------------------------------------------------------------
Figure 12: Single-Type Signing Scheme Algorithm Roll
Also see Section 4.1.4.1.
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_K_1 ------------------------------------------------------->
RRSIG_par(DS_K_1) -------------------------------------------->
Child:
SOA_0 SOA_1 SOA_2
RRSIG_Z_1(SOA) RRSIG_Z_1(SOA) RRSIG_Z_1(SOA)
RRSIG_Z_2(SOA) RRSIG_Z_2(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
DNSKEY_K_2
DNSKEY_Z_1 DNSKEY_Z_1 DNSKEY_Z_1
DNSKEY_Z_2
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
new DS revoke DNSKEY DNSKEY removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_K_2 ------------------------------------------------------>
RRSIG_par(DS_K_2) ------------------------------------------->
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_Z_1(SOA) RRSIG_Z_1(SOA)
-------------------> RRSIG_Z_2(SOA) RRSIG_Z_2(SOA)
-------------------> DNSKEY_K_1_REVOKED
-------------------> DNSKEY_K_2 DNSKEY_K_2
------------------->
-------------------> DNSKEY_Z_2 DNSKEY_Z_2
-------------------> RRSIG_K_1(DNSKEY)
-------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
RRSIGs removal
----------------------------------------------------------------
Parent:
------------------------------------->
------------------------------------->
------------------------------------->
------------------------------------->
Child:
SOA_5
RRSIG_Z_2(SOA)
DNSKEY_K_2
DNSKEY_Z_2
RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
Figure 13: RFC 5011 Style Algorithm Roll
Also see Section 4.1.4.2.
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_S_1 ------------------------------------------------------->
RRSIG_par(DS_S_1) -------------------------------------------->
Child:
SOA_0 SOA_1 SOA_2
RRSIG_S_1(SOA)
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
RRSIG_S_2(SOA) RRSIG_S_2(SOA)
DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1
DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10
DNSKEY_S_2
RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY)
RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
----------------------------------------------------------------
new DS revoke DNSKEY DNSKEY removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_S_2 ------------------------------------------------------>
RRSIG_par(DS_S_2) ------------------------------------------->
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_Z_10(SOA)
-------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA)
-------------------> DNSKEY_S_1_REVOKED
-------------------> DNSKEY_Z_10
-------------------> DNSKEY_S_2 DNSKEY_S_2
-------------------> RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY)
-------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
----------------------------------------------------------------
RRSIGs removal
----------------------------------------------------------------
Parent:
------------------------------------->
------------------------------------->
------------------------------------->
------------------------------------->
Child:
SOA_5
RRSIG_S_2(SOA)
DNSKEY_S_2
RRSIG_S_2(DNSKEY)
----------------------------------------------------------------
Figure 14: RFC 5011 Algorithm Roll in a Single-Type
Signing Scheme Environment
Also see Section 4.1.4.3.C.1. Hmm, Wait, I Think That's a Wrap for the Figures 💅
Oops, sorry, let me fix that. The figures above are all in Appendix C, and I shouldn't have made up a subsection that isn't in the original. Everything stays as it was.
Appendix D. Transition Figure for Changing DNS Operators 🦋
okay this one is my fave 😭 it's about what happens when you move your DNS to a whole new operator, and the figure shows the steps in order.
The figure in this Appendix complements and illustrates the special case of changing DNS operators as described in Section 4.3.5.1.
------------------------------------------------------------
new DS | pre-publish |
------------------------------------------------------------
Parent:
NS_A NS_A
DS_A DS_B DS_A DS_B
------------------------------------------------------------
Child at A: Child at A: Child at B:
SOA_A0 SOA_A1 SOA_B0
RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
NS_A NS_A NS_B
RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS)
RRSIG_Z_A(NS)
DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
------------------------------------------------------------
re-delegation | post-migration |
------------------------------------------------------------
Parent:
NS_B NS_B
DS_A DS_B DS_B
------------------------------------------------------------
Child at A: Child at B: Child at B:
SOA_A1 SOA_B0 SOA_B1
RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA)
NS_A NS_B NS_B
NS_B RRSIG_Z_B(NS) RRSIG_Z_B(NS)
RRSIG_Z_A(NS)
DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_B DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
Figure 15: An Alternative Rollover Approach for Cooperating OperatorsAppendix E. Summary of Changes from RFC 4641 🎀
okay so this is the "what's different" list, and it's giving changelog energy ✨
This document differs from RFC 4641 [RFC4641] in the following ways:
- Addressed the errata listed on <http://www.rfc-editor.org/errata_search.php?rfc=4641>.
- Recommended RSA/SHA-256 in addition to RSA/SHA-1.
- Did a complete rewrite of Section 3.5 of RFC 4641 (Section 3.4.2 of this document), removing the table and suggesting a key size of 1024 for keys in use for less than 8 years, issued up to at least 2015.
- Removed the KSK for high-level zones consideration.
- Added text on algorithm rollover.
- Added text on changing (non-cooperating) DNS registrars.
- Did a significant rewrite of Section 3, whereby the argument is made that the timescales for rollovers are made purely on operational arguments.
- Added Section 5.
- Introduced Single-Type Signing Scheme terminology and made the arguments for the choice of a Single-Type Signing Scheme more explicit.
- Added a section about stand-by keys.
Authors' Addresses 💜
okay bestie, here's where to find the authors 🫶
Olaf M. Kolkman NLnet Labs Science Park 400 Amsterdam 1098 XH The Netherlands
EMail: olaf@nlnetlabs.nl URI: http://www.nlnetlabs.nl
W. (Matthijs) Mekking NLnet Labs Science Park 400 Amsterdam 1098 XH The Netherlands
EMail: matthijs@nlnetlabs.nl URI: http://www.nlnetlabs.nl
R. (Miek) Gieben SIDN Labs Meander 501 Arnhem 6825 MD The Netherlands
EMail: miek.gieben@sidn.nl URI: http://www.sidn.nl
That's the whole thing, bestie! RFC 6781 is complete 🌈👑✨
📦 where this page comes from
- ietf: rfc6781 2012-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms