RFC 4641
DNSSEC Operational Practices
RFC 4641: DNSSEC Operational Practices 💖
part 1 of 7 🎀
- Network Working Group 🌸
- Authors: O. Kolkman and R. Gieben, from NLnet Labs ✨
- Category: Informational. This one shares info with the Internet community, it doesn't set a standard 📚
- Date: September 2006 📅
- Obsoletes: RFC 2541. It doesn't list any RFC it updates 🦋
Status of This Memo 🫶
This memo gives info to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice ©️
Copyright (C) The Internet Society (2006).
Abstract ✨
okay so this doc is all about running DNS with security extensions (DNSSEC) 🔐. The main audience is zone administrators who are deploying DNSSEC. 💅
It talks about the operational side of using keys and signatures in the DNS. Specifically: key generation, key storage, signature generation, key rollover, and the related policies 🔑.
It also obsoletes RFC 2541. Why? It covers more operational ground now and has more up-to-date requirements on key sizes and the new DNSSEC spec. It's giving glow-up 🌈
Table of Contents 📋
1. Introduction ....................................................3
1.1. The Use of the Term 'key' ..................................4
1.2. Time Definitions ...........................................4
2. Keeping the Chain of Trust Intact ...............................5
3. Keys Generation and Storage .....................................6
3.1. Zone and Key Signing Keys ..................................6
3.1.1. Motivations for the KSK and ZSK Separation ..........6
3.1.2. KSKs for High-Level Zones ...........................7
3.2. Key Generation .............................................8
3.3. Key Effectivity Period .....................................8
3.4. Key Algorithm ..............................................9
3.5. Key Sizes ..................................................9
3.6. Private Key Storage .......................................11
4. Signature Generation, Key Rollover, and Related Policies .......12
4.1. Time in DNSSEC ............................................12
4.1.1. Time Considerations ................................12
4.2. Key Rollovers .............................................14
4.2.1. Zone Signing Key Rollovers .........................14
4.2.1.1. Pre-Publish Key Rollover ..................15
4.2.1.2. Double Signature Zone Signing Key
Rollover ..................................17
4.2.1.3. Pros and Cons of the Schemes ..............18
4.2.2. Key Signing Key Rollovers ..........................18
4.2.3. Difference Between ZSK and KSK Rollovers ...........20
4.2.4. Automated Key Rollovers ............................21
4.3. Planning for Emergency Key Rollover .......................21
4.3.1. KSK Compromise .....................................22
4.3.1.1. Keeping the Chain of Trust Intact .........22
4.3.1.2. Breaking the Chain of Trust ...............23
4.3.2. ZSK Compromise .....................................23
4.3.3. Compromises of Keys Anchored in Resolvers ..........24
4.4. Parental Policies .........................................24
4.4.1. Initial Key Exchanges and Parental Policies
Considerations .....................................24
4.4.2. Storing Keys or Hashes? ............................25
4.4.3. Security Lameness ..................................25
4.4.4. DS Signature Validity Period .......................26
5. Security Considerations ........................................26
6. Acknowledgments ................................................26
7. References .....................................................27
7.1. Normative References ......................................27
7.2. Informative References ....................................28
Appendix A. Terminology ...........................................30
Appendix B. Zone Signing Key Rollover How-To ......................31
Appendix C. Typographic Conventions ...............................321. Introduction 🌷
this doc explains how to run a DNS Security (DNSSEC)-enabled environment 🛡️. It's meant for operators who already know the DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC. If you need the basics, check out RFC 4033 [4] for an intro to DNSSEC, RFC 4034 [5] for the newly introduced Resource Records (RRs), and RFC 4035 [6] for the protocol changes 📖.
operators and sysadmins got real experience during workshops and early operational deployment tests 🧑💻. This doc turns all of that into practices for zone administrators. As of writing, there's very little production experience with DNSSEC, so this doc should explicitly not be seen as representing 'Best Current Practices'. it's not the final word, bestie 🙈.
the procedures here focus on maintaining signed zones, which means signing and publishing zones on authoritative servers ✍️. The goal is that maintenance stuff like re-signing or key rollovers stays transparent to any verifying clients on the Internet 🫧.
here's the layout. Section 2 covers why keeping the "chain of trust" intact matters 🔗. Section 3 covers key generation and storing private keys, and the focus there is mostly on the private part of the key(s) 🗝️. Section 4 covers the public part of the keys. Since public keys live in the DNS, you have to think about all kinds of timing issues, which are in Section 4.1 💭. Sections 4.2 and 4.3 are about the rollover, or supercession, of keys 🔄. Last but not least, Section 4.4 is about how parents handle their children's public keys so the chains of trust hold 👨👩👧.
the typographic conventions are explained in Appendix C 🖋️.
since this is a doc of operational suggestions and there are no protocol specifications, the RFC 2119 [7] language does not apply 🙅♀️.
this doc obsoletes RFC 2541 [12] to reflect how the underlying DNSSEC protocol has evolved since then 🦋. The cryptographic algorithm choices, DNS record types and type names, and the parent-child key and signature exchange changed enough to need a major rewrite plus more info and explanation. It's a whole main character moment ✨.
1.1. The Use of the Term 'key' 🔑
it's assumed you already get asymmetric keys, the thing DNSSEC is built on (public key cryptography [17]) 🧠. So this doc uses the term 'key' pretty loosely 🫶. When it says 'a key is used to sign data', it means the private part of the key pair is the one doing the signing 🖊️. It's also assumed you know the public part of the key pair gets published in the DNSKEY Resource Record, and that the public part is what gets used in key exchanges 📬.
1.2. Time Definitions ⏰
this doc uses a bunch of time-related terms. These definitions apply:
- "Signature validity period" The period that a signature is valid. It starts at the time specified in the signature inception field of the RRSIG RR and ends at the time specified in the expiration field of the RRSIG RR. 🗓️
- "Signature publication period" Time after which a signature (made with a specific key) is replaced with a new signature (made with the same key). This replacement takes place by publishing the relevant RRSIG in the master zone file. After one stops publishing an RRSIG in a zone, it may take a while before the RRSIG has expired from caches and has actually been removed from the DNS. 📤
- "Key effectivity period" The period during which a key pair is expected to be effective. This period is defined as the time between the first inception time stamp and the last expiration date of any signature made with this key, regardless of any discontinuity in the use of the key. The key effectivity period can span multiple signature validity periods. 🌙
- "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum value of the TTLs from the complete set of RRs in a zone. Note that the minimum TTL is not the same as the MINIMUM field in the SOA RR. See [11] for more information. 🍓
2. Keeping the Chain of Trust Intact 🔗
keeping a valid chain of trust is super important 💀, because broken chains of trust get data marked as Bogus (as defined in [4] Section 5). That can make whole (sub)domains invisible to verifying clients 👻. Admins of secured zones need to realize that, from the verifying clients' point of view, their zone is part of a chain of trust 💜.
like the intro said, these procedures are meant to keep zone maintenance, like re-signing or key rollovers, transparent to verifying clients on the Internet 🫧.
admins also have to remember that data published on an authoritative primary server won't be seen by verifying clients right away 🐢. It can take time to transfer to secondary authoritative nameservers, and clients may be fetching from caching non-authoritative servers too 🗄️. The time for a zone transfer from master to slave is negligible when you use NOTIFY [9] and incremental transfer (IXFR) [8]. It goes up when full zone transfers (AXFR) are used with NOTIFY, and it goes up even more if you rely on full zone transfers based only on the SOA timing parameters for refresh 📈.
for verifying clients it matters that data from secured zones can build chains of trust, whether the data came straight from an authoritative server, a caching nameserver, or some middle box 📦. Only by carefully using the available timing parameters can a zone admin make sure the data needed for verification can be obtained ⏱️.
the responsibility for keeping the chain of trust intact is shared by the admins of every secured zone in that chain 🤝. This is most obvious during a 'key compromise', when you have to trade off between keeping the chain valid and replacing the compromised keys as fast as possible 😬. Zone admins then have to choose between keeping the chain intact, which lets attacks with the compromised key keep working, or deliberately breaking the chain, which makes secured subdomains invisible to security-aware resolvers 🫣. Also see Section 4.3 🔍.
3. Keys Generation and Storage 🗝️
this section covers a bunch of considerations about key security 🔐. It's about generating, the effectivity period, size, and storage of private keys ✨.
3.1. Zone and Key Signing Keys 🔑
okay so the DNSSEC validation protocol literally does not care about different types of DNSKEYs 💅. Every DNSKEY can be used during validation, no cap. In real life though, operators split their keys into Key Signing Keys and Zone Signing Keys, and they use the so-called Secure Entry Point (SEP) [3] flag to tell them apart during operations. We'll get into the dynamics and considerations below ✨.
To make zone re-signing and key rollover procedures easier to implement 😭, it is possible to use one or more keys as Key Signing Keys (KSKs). These keys will only sign the apex DNSKEY RRSet in a zone. Other keys can sign all the RRSets in a zone, and those are called Zone Signing Keys (ZSKs). In this document, we assume that KSKs are the subset of keys used for key exchanges with the parent and potentially for configuration as trusted anchors, which are the SEP keys 🫶. We also assume a one-to-one mapping between KSK and SEP keys, and that the SEP flag is set on all KSKs.
3.1.1. Motivations for the KSK and ZSK Separation
Splitting up the KSK and ZSK functions has several perks 🦋:
- No parent/child interaction is required when ZSKs are updated.
- The KSK can be made stronger (i.e., using more bits in the key material). This has little operational impact since it is only used to sign a small fraction of the zone data. Also, the KSK is only used to verify the zone's key set, not for other RRSets in the zone.
- As the KSK is only used to sign a key set, which is most probably updated less frequently than other data in the zone, it can be stored separately from and in a safer location than the ZSK.
- A KSK can have a longer key effectivity period.
For almost any method of key management and zone signing, the KSK gets used less often than the ZSK 🌸. Once a key set is signed with the KSK, all the keys in the key set can be used as ZSKs. If a ZSK gets compromised, it can simply be dropped from the key set, and then the new key set is re-signed with the KSK.
Given the assumption that the SEP flag is set for KSKs, you can tell a KSK apart from a ZSK by checking the flag field in the DNSKEY RR. If the flag field is an odd number, it's a KSK. If it's an even number, it's a ZSK 🎀.
The Zone Signing Key can be used to sign all the data in a zone on a regular basis. When a Zone Signing Key is to be rolled, no interaction with the parent is needed. This allows for signature validity periods on the order of days ⭐.
The Key Signing Key is only to be used to sign the DNSKEY RRs in a zone. If a Key Signing Key is to be rolled over, there will be interactions with parties other than the zone administrator 👀. These can include the registry of the parent zone or administrators of verifying resolvers that have the particular key configured as secure entry points. Hence, the key effectivity period of these keys can and should be made much longer. Although, given a long enough key, the key effectivity period can be on the order of years, we suggest planning for a key effectivity on the order of a few months so that a key rollover remains an operational routine 🧚.
3.1.2. KSKs for High-Level Zones
Higher-level zones are generally more sensitive than lower-level zones 🚨. Anyone controlling or breaking the security of a zone thereby obtains authority over all of its subdomains. The exception is resolvers that have locally configured the public key of a subdomain, because in that case this, and only this, subdomain wouldn't be affected by the compromise of the parent zone. Therefore, extra care should be taken with high-level zones, and strong keys should be used.
The root zone is the most critical of all zones 👑. Someone controlling or compromising the security of the root zone would control the entire DNS namespace of all resolvers using that root zone (except in the case of resolvers that have locally configured the public key of a subdomain). Therefore, the utmost care must be taken in the securing of the root zone. The strongest and most carefully handled keys should be used. The root zone private key should always be kept off-line 🔒.
Many resolvers will start at a root server for their access to and authentication of DNS data. Securely updating the trust anchors in an enormous population of resolvers around the world will be extremely difficult 😩.
3.2. 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 lower the size of the likely key space so that it can be exhaustively searched. Technical suggestions for the generation of random keys will be found in RFC 4086 [14]. One should carefully assess if the random number generator used during key generation adheres to these suggestions.
Keys with a long effectivity period are particularly sensitive, because they represent a more valuable target and are subject to attack for a longer time than short-period keys 💀. It is strongly recommended 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.3. Key Effectivity Period
For various reasons, keys in DNSSEC need to be changed once in a while 🔄. The longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis. Furthermore, when key rollovers are too rare an event, they will not become part of the operational habit, and there is a risk that nobody on-site will remember the procedure for rollover when the need is there 🙈.
From a purely operational perspective, a reasonable key effectivity period for Key Signing Keys is 13 months, with the intent to replace them after 12 months 📅. An intended key effectivity period of a month is reasonable for Zone Signing Keys 🍓.
For key sizes that match these effectivity periods, see Section 3.5.
As argued in Section 3.1.2, securely updating trust anchors will be extremely difficult 😤. On the other hand, the "operational habit" argument also applies to trust anchor reconfiguration. If a short key effectivity period is used and the trust anchor configuration has to be revisited on a regular basis, the odds that the configuration tends to be forgotten are smaller. The trade-off is against a system that is so dynamic that administrators of the validating clients will not be able to follow the modifications 🌈.
Key effectivity periods can be made very short, as in a few minutes ⚡. But when replacing keys, one has to take the considerations from Section 4.1 and Section 4.2 into account.
3.4. Key Algorithm
There are currently three different types of algorithms that can be used in DNSSEC: RSA, DSA, and elliptic curve cryptography 🧮. The latter is fairly new and has yet to be standardized for usage in DNSSEC.
RSA has been developed in an open and transparent manner. As the patent on RSA expired in 2000, its use is now also free 🦋.
DSA has been developed by the National Institute of Standards and Technology (NIST). The creation of signatures takes roughly the same time as with RSA, but verification is 10 to 40 times as slow [17] 🐢.
We suggest the use of RSA/SHA-1 as the preferred algorithm for the key. The current known attacks on RSA can be defeated by making your key longer. As the MD5 hashing algorithm is showing cracks, we recommend the usage of SHA-1 💅.
At the time of publication, it is known that the SHA-1 hash has cryptanalysis issues. There is work in progress on addressing these issues. We recommend the use of public key algorithms based on hashes stronger than SHA-1 (e.g., SHA-256), as soon as these algorithms are available in protocol specifications (see [19] and [20]) and implementations ✨.
3.5. Key Sizes 📏
okay so when picking key sizes, zone admins gotta think about how long a key will be used, how much data gets signed during the key publication period (see Section 8.10 of [17]) 📅, and, optionally, how big the parent's key size is 🫶. bestie, the chain of trust is literally "a chain", so making one link several times bigger than the others is kinda pointless 😭. the weakest link is what decides how strong the whole chain is 💀. also peep Section 3.1.1 for why keys doing different jobs (ZSK vs. KSK) might need different sizes 🔑.
generating a key of the right size is a whole thing, ngl 🙈. RFC 3766 [13] tries to help with that. the first part of the selection procedure in Section 1 of the RFC says:
1. Determine the attack resistance necessary to satisfy the security requirements of the application. Do this by estimating the minimum number of computer operations that the attacker will be forced to do in order to compromise the security of the system and then take the logarithm base two of that number. Call that logarithm value "n". A 1996 report recommended 90 bits as a good all-around choice for system security. The 90 bit number should be increased by about 2/3 bit/year, or about 96 bits in 2005.
[13] goes on to explain how this number "n" can be used to calculate key sizes in public key cryptography 🧮. it all culminates in this table (slightly modified for our purposes) 🎀:
+-------------+-----------+--------------+
| System | | |
| requirement | Symmetric | RSA or DSA |
| for attack | key size | modulus size |
| resistance | (bits) | (bits) |
| (bits) | | |
+-------------+-----------+--------------+
| 70 | 70 | 947 |
| 80 | 80 | 1228 |
| 90 | 90 | 1553 |
| 100 | 100 | 1926 |
| 150 | 150 | 4575 |
| 200 | 200 | 8719 |
| 250 | 250 | 14596 |
+-------------+-----------+--------------+the key sizes here are kinda huge 😳, and that's because they're built to resist a trillionaire attacker 🤑. if we assume that rich attacker won't go after your key and that the key gets rolled over once a year 🔄, we land on these KSK sizes: 1024 bits for low-value domains, 1300 bits for medium-value domains, and 2048 bits for high-value domains 👑.
whether a domain is low, medium, or high value depends solely on the view of the zone owner 💅. for example, you could see leaf nodes in the DNS as low value, and top-level domains (TLDs) or the root zone as high value 🌈. the suggested key sizes should be safe for the next 5 years ⭐.
ZSKs can be rolled over more easily (and therefore more often) 🔁, so their key sizes can be smaller. but like we said at the top of this part, making the ZSK sizes too small compared to the KSK sizes doesn't really make sense 🙅♀️. try to keep the difference in size to about 100 bits 📉.
nobody can see the future, so these key sizes are only a guide 🔮. more info can be found in [16] and Section 7.5 of [17]. it's worth noting though that [16] is already considered overly optimistic about what key sizes count as safe 🫠.
one last thing about key sizes ☝️. bigger keys make the RRSIG and DNSKEY records bigger too, which raises the chance of DNS UDP packet overflow 📦. creating and validating RRSIGs also takes longer with bigger keys, so don't needlessly double your key sizes 🙃.
3.6. Private Key Storage 🔐
it is recommended that, where possible, zone private keys and the zone file master copy that's getting signed be kept and used only on 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 RRs ✍️. then the augmented file can be transferred 📤.
when you rely on dynamic update to manage a signed zone [10], be aware that at least one private key of the zone will have to live on the master server 👀. that key is only as secure as the amount of exposure the server gets from unknown clients, plus the security of the host 😬. it's not mandatory, but you could run the DNS like this: the master that processes the dynamic updates is unreachable from generic hosts on the Internet 🚫, and it's not listed in the NS RR set, even though its name shows up in the SOA RR's MNAME field 🕵️♀️. the nameservers in the NS RRSet can receive zone updates through NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism 📬. this approach is known as the "hidden master" setup 🦋.
the ideal situation is a one-way flow of information to the network, so nothing can be tampered with from the network side 🌊. keeping the zone master file on-line and just cycling it through an off-line signer doesn't do that 🙅♀️. the on-line version could still get tampered with if the host it lives on gets compromised 💔. for maximum security, the master copy of the zone file should be off-net and shouldn't be updated based on unsecured, network-mediated communication 🔒.
realistically, keeping a zone file off-line usually isn't practical 😩, so the machines where zone files are maintained will be connected to a network. operators are advised to take security measures to shield unauthorized access to the master copy 🛡️.
for dynamically updated secured zones [10], both the master copy and the private key used to update signatures on updated RRs will need to be on-line 🌐.
4. Signature Generation, Key Rollover, and Related Policies ⏰
4.1. Time in DNSSEC ⌛
without DNSSEC, all times in the DNS are relative 🕰️. the SOA fields REFRESH, RETRY, and EXPIRATION are timers used to figure out how much time has passed since a slave server synced with a master server 🔄. the Time to Live (TTL) value and the SOA RR minimum TTL parameter [11] decide how long a forwarder should cache data after fetching it from an authoritative server 💾. by using a signature validity period, DNSSEC brings in the idea of an absolute time in the DNS ✨. signatures in DNSSEC have an expiration date, and after that the signature is marked invalid and the signed data is to be considered Bogus 🚨.
4.1.1. Time Considerations ⏳
because signatures expire, bestie, think about the following 💅:
- we suggest the Maximum Zone TTL of your zone data to be a fraction of your signature validity period 🍰.
if the TTL were of similar order to the signature validity period, then all RRSets fetched during the validity period would be cached until the signature expiration time 😱. Section 7.1 of [4] 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 query load on authoritative servers would peak at signature expiration time, since that's also when records expire from caches all at once 📈💥.
to avoid those query load peaks, we suggest the TTL on all the RRs in your zone be at least a few times smaller than your signature validity period 🧁.
- we suggest the signature publication period to end at least one Maximum Zone TTL duration before the end of the signature validity period ⏪.
re-signing a zone shortly before the end of the signature validity period may cause simultaneous expiration of data from caches 🫨. that can then lead to peaks in load on authoritative servers 📊.
- we suggest 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 [18] that a low TTL (under 5 to 10 minutes) caused disruptions because of two problems 🧪:
- during validation, some data may expire before validation is complete. the validator should be able to keep all data until it's finished. this applies to all RRs needed to complete the chain of trust: DSes, DNSKEYs, RRSIGs, and the final answers, i.e., the RRSet returned for the initial query 🧩.
- frequent verification causes load on recursive nameservers 😵. data at delegation points, DSes, DNSKEYs, and RRSIGs benefits from caching, so the TTL on those should be relatively long 💜.
- 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 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 expiration time is set in the SOA record and is relative to the last successful refresh between the master and the slave servers ⏱️. there's no coupling between the signature expiration of RRSIGs in the zone and the expire parameter in the SOA 🙅♀️.
if the server serves a DNSSEC zone, it may well happen that signatures expire well before the SOA expiration timer counts down to zero 😬. it's not possible to completely prevent this by tweaking the SOA parameters 🛑. however, the effects can be minimized where the SOA expiration time is equal to or shorter than the signature validity period ✅. the consequence of an authoritative server being unable to update a zone while that zone includes expired signatures is that non-secure resolvers keep resolving data served by those slave servers, while security-aware resolvers run into problems because answers are marked as Bogus 🥲.
we suggest the SOA expiration timer be approximately one third or one fourth of the signature validity period 🍕. that lets problems with transfers from the master server get noticed before the actual signature times out 👀. we also suggest that operators of nameservers supplying secondary services develop 'watch dogs' to spot upcoming signature expirations in zones they slave, and take appropriate action 🐶.
when deciding the value for the expiration parameter, you have to take the following into account 📝: what are the chances that all my secondaries expire the zone? how quickly can I reach an administrator of secondary servers to load a valid zone? these questions aren't DNSSEC specific, but they may still influence the choice of your signature validity intervals 🎀.
4.2. Key Rollovers ✨
Okay so a DNSSEC key can't be used forever (see Section 3.3) 💀. That means key rollovers, or supercessions if you want to be fancy 🎀, are just a fact of life once you're using DNSSEC. Zone admins who are rolling their keys have to remember that data from previous versions of their zone is still hanging out in caches 🧊. When you're deploying DNSSEC this really matters, because ignoring what's in caches can lead to loss of service for clients 😭.
The most pressing example is when zone data signed with an old key gets validated by a resolver that doesn't have the old zone key cached. If the old key isn't in the current zone anymore, the validation fails and the data gets marked "Bogus" 🙈. And it can go the other way too: trying to validate data signed with a new key against an old key living in a local cache also ends with the data marked "Bogus". Iykyk, it's a whole mess 💅.
4.2.1. Zone Signing Key Rollovers 🔑
For "Zone Signing Key rollovers", there are two ways to make sure things still work during the rollover 🦋. Either the data still in caches can be verified with the new key sets, or the newly generated signatures can be verified with the keys still in caches. One schema, described in Section 4.2.1.2, uses double signatures. The other uses key pre-publication (Section 4.2.1.1). The pros, cons, and recommendations are covered in Section 4.2.1.3 🌸.
4.2.1.1. Pre-Publish Key Rollover 🧚
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 giving main character energy 👑. It has real perks if a key gets compromised: the new key has already been distributed in the DNS, so the zone admin can quickly switch to it and remove the compromised key from the zone 🔥. Another big win is that the zone size doesn't double, unlike with the double signature ZSK rollover. There's a small "how-to" for this kind of rollover in Appendix B 🍓.
Pre-publish key rollover involves four stages, as follows:
----------------------------------------------------------------
initial new DNSKEY new RRSIGs DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2 SOA3
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11 DNSKEY11
RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
----------------------------------------------------------------
Pre-Publish Key Rolloverinitial: This is the initial version of the zone. DNSKEY 1 is the Key Signing Key. DNSKEY 10 is used to sign all the data of the zone, the Zone Signing Key. 🔑
new DNSKEY: DNSKEY 11 gets introduced into the key set. No signatures are generated with this key yet, but that doesn't protect the public key against 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: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is used to sign the data in the zone exclusively. That means all the signatures from DNSKEY 10 get removed from the zone 🧹. DNSKEY 10 stays published in the key set, so data that was loaded into caches from version 1 of the zone can still be verified with key sets fetched from version 2 of the zone 🫶. The minimum time the key set including DNSKEY 10 has to stay published is the time it takes for zone data from the previous version to expire from old caches. In other words, it's 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 10 is removed from the zone. The key set, which now only contains DNSKEY 1 and DNSKEY 11, is re-signed with DNSKEY 1 ✨.
The above scheme can be simplified by always publishing the "future" key right after the rollover 🧠. Here's how that looks (we show two rollovers). The future key is introduced in "new DNSKEY" as DNSKEY 12, and then a newer one, numbered 13, shows up in "new DNSKEY (II)":
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2)
DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11 DNSKEY11 DNSKEY12
RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY)
RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
----------------------------------------------------------------
----------------------------------------------------------------
new RRSIGs (II) new DNSKEY (II)
----------------------------------------------------------------
SOA3 SOA4
RRSIG12(SOA3) RRSIG12(SOA4)
DNSKEY1 DNSKEY1
DNSKEY11 DNSKEY12
DNSKEY12 DNSKEY13
RRSIG1(DNSKEY) RRSIG1(DNSKEY)
RRSIG12(DNSKEY) RRSIG12(DNSKEY)
----------------------------------------------------------------
Pre-Publish Key Rollover, Showing Two RolloversNote that the key introduced in the "new DNSKEY" phase isn't used for production yet. That means its private key can be stored in a physically secure manner, and it doesn't need to be "fetched" every time a zone needs to be signed 🔐.
4.2.1.2. Double Signature Zone Signing Key Rollover 💫
This section shows how to do a ZSK key rollover using 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 needs to propagate to all authoritative servers, and the data sitting in (distant) caches needs to expire. That takes at least the Maximum Zone TTL ⏳.
Double signature ZSK rollover involves three stages, as follows:
----------------------------------------------------------------
initial new DNSKEY DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
RRSIG11(SOA1)
DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11
RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
RRSIG11(DNSKEY)
----------------------------------------------------------------
Double Signature Zone Signing Key Rolloverinitial: This is the initial version of the zone. DNSKEY 1 is the Key Signing Key. DNSKEY 10 is used to sign all the data of the zone, the Zone Signing Key. 🔑
new DNSKEY: At the "New DNSKEY" stage (SOA serial 1), DNSKEY 11 is introduced into the key set, and all the data in the zone gets signed with both DNSKEY 10 and DNSKEY 11 ✍️. The rollover period has to keep going until all data from version 0 of the zone has expired from remote caches. That takes at least the Maximum Zone TTL of version 0 of the zone ⏰.
DNSKEY removal: DNSKEY 10 is removed from the zone, and all the signatures from DNSKEY 10 come out with it 🧹. The key set, which now only contains DNSKEY 11, is re-signed with DNSKEY 1 ✨.
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. Data from the current version can be verified with data from the previous version of the zone too 🔁. The duration of the "new DNSKEY" phase and the period between rollovers should be at least the Maximum Zone TTL 🕰️.
Making sure that the "new DNSKEY" phase lasts until the signature expiration time of the data in the initial version of the zone is recommended 🌈. That way, all caches get cleared of the old signatures. Heads up though: this duration could end up being way longer than the Maximum Zone TTL, which makes the rollover a lengthy procedure 🥱.
Note that in this example we assumed the zone wasn't modified during the rollover. New data can be introduced into the zone, as long as it's signed with both keys 💜.
4.2.1.3. Pros and Cons of the Schemes ⚖️
Pre-publish key rollover: This rollover doesn't involve signing the zone data twice. Instead, before the actual rollover, the new key gets published in the key set, which means it's available for cryptanalysis attacks 😬. A small disadvantage is that this process takes four steps. Also, the pre-publish scheme involves more parental work when it's used for KSK rollovers, as explained in Section 4.2.3 🙃.
Double signature ZSK rollover: The drawback of this signing scheme is that during the rollover, the number of signatures in your zone doubles. That may be prohibitive if you have very big zones 📦. The advantage is that it only requires three steps 🎉.
4.2.2. Key Signing Key Rollovers ✨
Okay so, KSK rollovers follow the same considerations as ZSK rollovers 💅 BUT we can use a double signature scheme to make sure old data (only the apex key set) in caches can be verified with a new key set, and vice versa 🔥 Since only the key set gets signed with a KSK, zone size considerations do not apply 🧚
--------------------------------------------------------------------
initial new DNSKEY DS change DNSKEY removal
--------------------------------------------------------------------
Parent:
SOA0 --------> SOA1 -------->
RRSIGpar(SOA0) --------> RRSIGpar(SOA1) -------->
DS1 --------> DS2 -------->
RRSIGpar(DS) --------> RRSIGpar(DS) -------->
Child:
SOA0 SOA1 --------> SOA2
RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2)
-------->
DNSKEY1 DNSKEY1 --------> DNSKEY2
DNSKEY2 -------->
DNSKEY10 DNSKEY10 --------> DNSKEY10
RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY)
RRSIG2 (DNSKEY) -------->
RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY)
--------------------------------------------------------------------Stages of Deployment for a Double Signature Key Signing Key Rollover 🌸
- initial: This is the initial version of the zone 🍓 The parental DS points to
DNSKEY1. Before the rollover starts, the child has to figure out what the TTL is of the DS RR that points toDNSKEY1. It's needed during the rollover, and we call that valueTTL_DS💜 - new DNSKEY: During this phase, the zone administrator generates a second KSK,
DNSKEY2🦋 The key gets handed to the parent, and the child has to wait until a new DS RR pointing toDNSKEY2has been generated. Once that DS RR is published on all servers authoritative for the parent's zone, the zone administrator has to wait at leastTTL_DSto make sure the old DS RR has expired from caches ⏳ - DS change: The parent replaces
DS1withDS2🔄 - DNSKEY removal:
DNSKEY1has been removed 👋
Real talk, this scenario puts the responsibility for keeping a valid chain of trust on the child 🫶 It also assumes the parent only has one DS RR (per algorithm) per zone. There's an alternative mechanism that's been considered: using an established trust relation, the interaction can happen in-band, and the parent could possibly signal the removal of the keys by the child. In that mechanism, there are periods where the parent has two DS RRs at the same time. Since the protocol for this interaction hasn't been developed as of writing, further discussion is out of scope for this document 🙈
4.2.3. Difference Between ZSK and KSK Rollovers 💖
Note that KSK rollovers and ZSK rollovers are different, bestie 👀 A KSK rollover requires interaction with the parent (and possibly replacing trust anchors), plus the delay that comes with waiting for that to happen 😭
A zone key rollover can be handled in two different ways: pre-publish (Section 4.2.1.1) and double signature (Section 4.2.1.2) ✨
The KSK is used to validate the key set, and the KSK doesn't change during a ZSK rollover, so a cache is able to validate the new key set of the zone 🧠 The pre-publish method would also work for a KSK rollover. The records that get pre-published are the parental DS RRs. BUT the pre-publish method has some drawbacks for KSKs, so we'll walk through the rollover scheme first and then point those out 🎀
--------------------------------------------------------------------
initial new DS new DNSKEY DS/DNSKEY removal
--------------------------------------------------------------------
Parent:
SOA0 SOA1 --------> SOA2
RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2)
DS1 DS1 --------> DS2
DS2 -------->
RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS)
Child:
SOA0 --------> SOA1 SOA1
RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1)
-------->
DNSKEY1 --------> DNSKEY2 DNSKEY2
-------->
DNSKEY10 --------> DNSKEY10 DNSKEY10
RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY)
RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY)
--------------------------------------------------------------------Stages of Deployment for a Pre-Publish Key Signing Key Rollover 🌈
When the child zone wants to roll, it notifies the parent during the "new DS" phase and submits the new key (or the corresponding DS) to the parent 📨 The parent publishes DS1 and DS2, pointing to DNSKEY1 and DNSKEY2 respectively. During the rollover ("new DNSKEY" phase), which can happen as soon as the new DS set has propagated through the DNS, the child replaces DNSKEY1 with DNSKEY2 🔁 Right after that ("DS/DNSKEY removal" phase), it can notify the parent that the old DS record can be deleted 🗑️
The drawbacks of this scheme? 😬 During the "new DS" phase, the parent can't verify the match between the DS2 RR and DNSKEY2 using the DNS, because DNSKEY2 isn't published yet. Also, we introduce a "security lame" key (see Section 4.4.3). And finally, the child-parent interaction takes two steps. The "double signature" method only needs one interaction 💅
4.2.4. Automated Key Rollovers 🤖
Keys have to be renewed periodically, so there's some motivation to automate the rollover process 💫 Consider the following:
- ZSK rollovers are easy to automate, because only the child zone is involved ✨
- A KSK rollover needs interaction between parent and child. Data exchange is needed to provide the new keys to the parent, so this data must be authenticated and its integrity must be guaranteed in order to avoid attacks on the rollover 🛡️
4.3. Planning for Emergency Key Rollover 🚨
This section is all about preparing for a possible key compromise 🥺 Our advice is to have a documented procedure ready for when a key compromise is suspected or confirmed. Trust me, future you will be so grateful 🙏
When the private material of one of your keys is compromised, it can be used for as long as a valid trust chain exists 😱 A trust chain remains intact:
- as long as a signature over the compromised key in the trust chain is valid,
- as long as a parental DS RR (and its signature) points to the compromised key,
- as long as the key is anchored in a resolver and is used as a starting point for validation (this is generally the hardest one to update).
While a trust chain to your compromised key exists, your namespace is vulnerable to abuse by anyone who has illegitimately gotten hold of the key 💀 Zone operators have to make a trade-off if abuse of the compromised key is worse than having data in caches that can't be validated. If the zone operator chooses to break the trust chain to the compromised key, data in caches signed with this key can't be validated. BUT if the zone administrator goes with a regular rollover instead, the malicious key holder can spoof data so it looks valid 😤
4.3.1. KSK Compromise 🔑
A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable for as long as the compromised KSK is configured as a trust anchor, or a parental DS points to it 😰
A compromised KSK can be used to sign the key set of an attacker's zone. That zone could then be used to poison the DNS ☠️
So, when the KSK has been compromised, the trust anchor or the parental DS should be replaced as soon as possible 🏃♀️ Whether to break the trust chain during the emergency rollover is a matter of 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 pointing to the compromised KSK. (The assumption here is that there's only one DS at the parent. If there are multiple DSes, this doesn't apply, but the chain of trust for this particular key is still broken.)
Note that an attacker's zone still uses the compromised KSK, and the presence of a parental DS would make the data in that zone appear valid 👀 Removing the compromised key would make the attacker's zone appear valid and the child's zone appear Bogus. Therefore, we advise not removing the KSK before the parent has a DS pointing to a new KSK in place 🫶
4.3.1.1. Keeping the Chain of Trust Intact 🧵
If we follow this advice, the timing of the KSK replacement is kinda critical 😩 The goal is to remove the compromised KSK as soon as the new DS RR is available at the parent. We also want to make sure the signature made with a new KSK over the key set (which still includes the compromised KSK) expires just after the new DS appears at the parent, so the old cruft gets cleaned up in one swoop 🧹
The procedure goes like this:
- Introduce a new KSK into the key set, and keep the compromised KSK in the key set.
- 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 DSes have expired from caches.
- Upload the DS for this new key to the parent.
- Follow the procedure of the regular KSK rollover: wait for the DS to appear in 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 or extend the expiration time.
- Remove the compromised DNSKEY RR from the zone, and re-sign the key set using your "normal" validity interval.
Here's an extra danger of a key compromise: the compromised key could be used to facilitate a legitimate DNSKEY/DS rollover and/or nameserver changes at the parent 😱 When that happens, the domain may end up in dispute. In this case, an authenticated, out-of-band, and secure notify mechanism to contact the parent is needed 📞
Note that this is only a problem when the DNSKEY and/or DS records are used for authentication at the parent 🤓
4.3.1.2. Breaking the Chain of Trust 💔
There are two methods to break 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 👇
In 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 🩹
An alternative way to break the chain of trust is to remove the DS RRs from the parent zone altogether. As a result, the child zone would become insecure 🥀
4.3.2. ZSK Compromise ✨
okay so a ZSK compromise is less dramatic than a KSK compromise bc no parental interaction is needed 💅 but the zone still has to get re-signed with a new ZSK asap 🏃♀️. It's a local operation, no chatting with the parent or child required, so it can happen pretty fast. BUT (and this is a big but) just like a normal rollover, the old compromised key vanishing immediately can cause verification problems 😭. Also, as long as the RRSIG over the compromised ZSK hasn't expired, the zone may still be at risk 🙈.
4.3.3. Compromises of Keys Anchored in Resolvers 🔑
a key can also be pre-configured in resolvers 🧚. For example, once DNSSEC is successfully deployed, the root key may be pre-configured in most security aware resolvers 👑.
if trust-anchor keys get compromised, the resolvers using them should be told about it 📣. Zone administrators may consider setting up a mailing list to announce that a SEP key is about to be rolled over 💌. That communication will of course need to be authenticated, e.g., by using digital signatures 🔐.
end-users who have to update an anchored key should always validate the new key 🫶. New keys should be authenticated out-of-band, for example through an announcement website secured with secure sockets (TLS) [21] 🌸.
4.4. Parental Policies 👑
4.4.1. Initial Key Exchanges and Parental Policies Considerations 🎀
the initial key exchange is always subject to the parent's policies 📋. When 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 exchanging delegation information between parent and child 💪. So no, there's no implicit need in DNSSEC to make the authentication process stronger than it was in DNS 🙅♀️.
using the DNS itself as the source for the actual DNSKEY material, plus an out-of-band check on the DNSKEY's validity, has the benefit of reducing the chances of user error 🍓. A DNSKEY query tool can use the SEP bit [3] to pick the proper key from a DNSSEC key set, which lowers the chance of sending the wrong DNSKEY ✨. It can also validate the self-signature over a key, which verifies ownership of the private key material 🔍. Fetching the DNSKEY from the DNS keeps the chain of trust intact once the parent publishes the DS RR indicating the child is secure 🔗.
Note: the out-of-band verification is still needed when the key material is fetched via the DNS. The parent can never be sure whether or not the DNSKEY RRs have been spoofed 🚨.
4.4.2. Storing Keys or Hashes? 🗄️
when designing a registry system, think about which DNSKEYs and/or corresponding DSes to store 🤔. 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 record from a raw DNSKEY 😬. That's why we recommend that registry systems at least support storing DS records 💜.
storing DNSKEYs can be useful too, since having them helps during troubleshooting. As long as the child's chosen message digest is supported, the overhead of generating DS records from them is minimal 🧮. An out-of-band mechanism, like a registry directory (e.g., Whois), can also help troubleshooting by showing which keys are used to generate DS Resource Records for specific owners and/or zones 🕵️♀️.
storage choices also tie into the customer interface and the way data moves between 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? 🤨 In the registry-registrar model, you can use the DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15], which allows transfer of DS RRs and optionally DNSKEY RRs 📨.
4.4.3. Security Lameness 🦆
security lameness is what happens when a parent has a DS RR pointing to a non-existing DNSKEY RR 😵. When this happens, verifying DNS clients may mark the child's zone as "Bogus" 🚫.
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 🔎. But if a parent doesn't understand the hashing algorithm the child uses, the parental checks are limited to just comparing the key id 🥲.
child zones need to be super careful when removing DNSKEY material, especially SEP keys that have a DS RR pointing at them ⚠️.
once a zone is "security lame," a fix (e.g., removing a DS RR) takes time to propagate through the DNS 🐢.
4.4.4. DS Signature Validity Period ⏳
since the DS can be replayed as long as it has a valid signature, a short signature validity period over the DS minimizes how long a child is vulnerable if its KSK(s) are compromised 🫣. But a signature validity period that's too short means a zone could get marked "Bogus" because of a configuration error in the signer 😱. There may not be enough time to fix problems before signatures expire. Something as mundane as the operator being unavailable on weekends shows why DS signature validity periods need to be longer than 2 days 🗓️. We recommend an absolute minimum for a 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 stay vulnerable after a key compromise 🕰️. On the flip side, shortening the DS signature validity interval increases the operational risk for the parent 🥵. So the parent may have a policy to use a signature validity interval that's considerably longer than the child would hope for 🙃.
a compromise between the parent's operational constraints and minimizing damage for the child may land on a DS signature validity period somewhere between a week and months 🌈.
besides the signature validity period, there's also the TTL value on the DS RRs 🧠. The signature validity period sets a lower bound on how often the zone owner needs to sign the zone data, and an upper bound on how long a child stays vulnerable after a key compromise. Shortening the TTL means the authoritative servers see more queries 📈. But a short TTL also lowers how long DS RRSets persist in caches, which speeds up how fast updated DS RRSets propagate through the DNS 🚀.
5. Security Considerations 🚨
DNSSEC adds data integrity to the DNS 🔒. This document tries to assess the operational considerations needed to keep a DNSSEC service stable and secure 🛡️. Not taking into account the 'data propagation' properties in the DNS will cause validation failures and may make secured zones unavailable to security-aware resolvers 💀. Please don't skip this part, bestie 😭.
6. Acknowledgments 🫶
most of the ideas in this document came out of collective efforts during workshops, discussions, and tryouts ✨.
at the risk of forgetting people who were the original contributors of the ideas, we want to shout out the people who were actively involved in putting this document together 📣. 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, and Peter Koch 👑💖.
some material in this document was copied from RFC 2541 [12] 📚.
Mike StJohns designed the key exchange between parent and child mentioned in the last paragraph of Section 4.2.2 🎀.
Section 4.2.4 was supplied by G. Guette and O. Courtay 🧚.
Emma Bretherick, Adrian Bedford, and Lindy Foster corrected many of the spelling and style issues ✏️.
Kolkman and Gieben take the blame for introducing all miscakes (sic) 🙈.
while working on this document, Kolkman was employed by the RIPE NCC and Gieben was employed by NLnet Labs 💼.
7. References 📚
7.1. Normative References 💜
- [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
- [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
- [3] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, May 2004.
- [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
- [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
- [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
7.2. Informative References 🦋
- [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [8] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
- [9] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.
- [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
- [11] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
- [12] Eastlake, D., "DNS Security Operational Considerations", RFC 2541, March 1999.
- [13] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
- [14] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
- [15] Hollenbeck, S., "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 4310, December 2005.
- [16] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes", The Journal of Cryptology 14 (255-293), 2001.
- [17] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc., 1996.
- [18] Rose, S., "NIST DNSSEC workshop notes", June 2001.
- [19] Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC", Work in Progress, January 2006.
- [20] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006.
- [21] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
Appendix A. Terminology ✨
okay so this appendix is the jargon glossary 📖💅 the definitions are the author's own explanations, not copy-pasted from the source docs, so they're not official, but they're super helpful to get the vibe 🫶
Anchored key 🔑: a DNSKEY that's configured in resolvers all over the globe. it's really hard to update, which is literally why it's called "anchored" ⚓
Bogus 🚫: see Section 5 of [4] for the full story! an RRSet in DNSSEC gets marked "Bogus" when a signature on it doesn't validate against a DNSKEY. 💀
Key Signing Key or KSK 👑: a KSK is a key used only for signing the apex key set. whether a key is a KSK only matters to the signing tool, not the protocol itself 🛠️
Key size 📏: "key size" can be swapped out for "modulus size" everywhere in the doc. technically modulus size is more correct 🤓 but since this doc is for operators, the authors felt more comfy with "key size" 🥰
Private and public keys 🗝️: DNSSEC protects the DNS using public key cryptography. that means there are two mathematically related keys, a public one and a private one. public keys get published in the DNS using the DNSKEY Resource Record (DNSKEY RR). private keys stay private, no sharing!! 🤫
Key rollover 🔄: also called key supercession in some environments. it's when you swap one key pair for another at the end of a key's effectivity period. main character glow-up moment ✨
Secure Entry Point (SEP) key 🚪: a KSK that either has a parental DS record pointing to it or is configured as a trust anchor. the protocol doesn't require it, but the authors recommend setting the SEP flag [3] on these keys 🏳️🌈 it's giving "good hygiene"
Self-signature 🪞: this one only applies to signatures over DNSKEYs. a signature made with DNSKEY x over DNSKEY x is called a self-signature. but heads up, without more info, self-signatures convey no trust 🚩 they're only useful for checking the DNSKEY is authentic, so you can kinda use them like a hash 🧁
Singing the zone file 🎶: the term for when an administrator joyfully signs their zone file while humming melodic sound patterns. yes this is a real term in the doc 😭🎤
Signer ✍️: the system that has access to the private key material and signs the Resource Record sets in a zone. a signer can be set up to sign only some parts of the zone, like only the RRSets whose existing signatures are about to expire ⏳
Zone Signing Key (ZSK) 🧩: a key used for signing all the data in a zone. again, whether a key is a ZSK only matters to the signing tool 🛠️
Zone administrator 🧑💻: the "role" responsible for signing a zone and publishing it on the primary authoritative server. the big boss of the zone 👑
Appendix B. Zone Signing Key Rollover How-To 🔁
okay bestie, this is the step-by-step for rolling over a Zone Signing Key 💖 it uses the pre-published signature scheme plus the most conservative method for making sure data doesn't live in caches anymore. so careful, very cautious, very iconic 🧚
Step 0: The preparation 🎀: create two keys and publish both of them in your key set. mark one as "active" and the other as "published". use the "active" key to sign your zone data. store the private part of the "published" key, preferably offline 🔒 the protocol doesn't have attributes to mark a key as active or published, so you gotta track that yourself with a notebook or a key management tool 📓
Step 1: Determine expiration ⏰: at the start of the rollover, write down the highest expiration time of signatures in your zone file that were made with the current active key. then wait until that expiration time from Step 1 has passed 🕰️
Step 2: Switch keys 🔀: now start using the "published" key to sign your data (aka mark it "active"). then stop using the old "active" key and mark it "rolled" 🍓
Step 3: Repeat when ready 🔁: it's safe to start a new rollover (going back to Step 1) after at least one signature validity period has passed 🫶
Appendix C. Typographic Conventions 🎨
these are the little notation tricks the doc uses, so you can read it like a pro 💅
Key notation 🗝️: a key is written as DNSKEYx, where x is a number or an identifier. you can think of x as the key id 🆔
RRSet notations 📦: RRs are only written by their type. everything else (owner, class, rdata, and TTL) gets left out. so example.com 3600 IN A 192.0.2.1 gets shortened to just A. RRSets are a list of RRs, so A1, A2 means the RRSet with two "A" records, and that can be shortened again to just A 🌸
Signature notation ✒️: signatures are written as RRSIGx(RRSet), which means the RRSet is signed with DNSKEYx 💜
Zone representation 🗺️: using all of the above, the doc simplifies a signed zone by dropping unnecessary details like names, and by swapping all the data out for "SOAx" 🧼
SOA representation 🧾: SOAs are written as SOAx, where x is the serial number 🔢
Here's the signed zone the doc starts from, before all the simplifying ✨
example.net. 86400 IN SOA ns.example.net. bert.example.net. (
2006022100 ; serial
86400 ; refresh ( 24 hours)
7200 ; retry ( 2 hours)
3600000 ; expire (1000 hours)
28800 ) ; minimum ( 8 hours)
86400 RRSIG SOA 5 2 86400 20130522213204 (
20130422213204 14 example.net.
cmL62SI6iAX46xGNQAdQ... )
86400 NS a.iana-servers.net.
86400 NS b.iana-servers.net.
86400 RRSIG NS 5 2 86400 20130507213204 (
20130407213204 14 example.net.
SO5epiJei19AjXoUpFnQ ... )
86400 DNSKEY 256 3 5 (
EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
86400 DNSKEY 257 3 5 (
gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
86400 RRSIG DNSKEY 5 2 86400 20130522213204 (
20130422213204 14 example.net.
J4zCe8QX4tXVGjV4e1r9... )
86400 RRSIG DNSKEY 5 2 86400 20130522213204 (
20130422213204 15 example.net.
keVDCOpsSeDReyV6O... )
86400 RRSIG NSEC 5 2 86400 20130507213204 (
20130407213204 14 example.net.
obj3HEp1GjnmhRjX... )
a.example.net. 86400 IN TXT "A label"
86400 RRSIG TXT 5 3 86400 20130507213204 (
20130407213204 14 example.net.
IkDMlRdYLmXH7QJnuF3v... )
86400 NSEC b.example.com. TXT RRSIG NSEC
86400 RRSIG NSEC 5 3 86400 20130507213204 (
20130407213204 14 example.net.
bZMjoZ3bHjnEz0nIsPMM... )
...and after all that simplifying, it turns into this super compact version 🎀
SOA2006022100
RRSIG14(SOA2006022100)
DNSKEY14
DNSKEY15
RRSIG14(KEY)
RRSIG15(KEY)the rest of the zone data has the same signature as the SOA record, meaning an RRSIG made with DNSKEY 14 🌈
Authors' Addresses 💌
Olaf M. Kolkman 🇳🇱 NLnet Labs Kruislaan 419 Amsterdam 1098 VA The Netherlands
EMail: olaf@nlnetlabs.nl URI: http://www.nlnetlabs.nl
R. (Miek) Gieben 🫶
EMail: miek@miek.nl
Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2006). 🦋
this document is covered by the rights, licenses and restrictions in BCP 78, and except where BCP 78 says otherwise, the authors keep all their rights 🔐
this document and the info inside it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈
Intellectual Property 🧠
the IETF doesn't take a position on whether any Intellectual Property Rights or other rights claimed around the technology in this document are valid or how far they reach, and it also doesn't say whether licenses for those rights are available. it hasn't independently gone hunting for any such rights either 🕵️♀️ info on how rights work for RFC documents lives in BCP 78 and BCP 79 📚
copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission for implementers or users of this spec can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🗂️
the IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 📬
Acknowledgement 🌷
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 💖
📦 where this page comes from
- ietf: rfc4641 2006-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms