RFC 3658
Delegation Signer (DS) Resource Record (RR)
Delegation Signer (DS) Resource Record (RR) 🎀
Okay, this is RFC 3658, by O. Gudmundsson, dated December 2003 🗓️. It's on the Standards Track 💅 and sits in the Network Working Group. It updates RFC 3090, RFC 3008, RFC 2535 and RFC 1035 🔥, so if you've ever touched those, this one matters for you.
Status of this Memo ✨
This doc specifies an Internet standards track protocol for the Internet community, and it's basically asking everyone for discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.
Copyright Notice 🔒
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract 🦋
So the delegation signer (DS) resource record (RR) gets inserted at a zone cut (aka a delegation point) 📍. Its whole job is to say two things: the delegated zone is digitally signed, and the delegated zone recognizes the indicated key as a valid zone key for itself 🔑. It's a modification to the DNS Security Extensions definition, and it's motivated by operational considerations 🛠️. The big idea is to make this resource record an explicit statement about the delegation, instead of having people infer it 💖.
This document defines the DS RR, gives examples of how it's used, and describes what it means for resolvers 👑. Heads up: this change is not backwards compatible with RFC 2535 😬. This document updates RFC 1035, RFC 2535, RFC 3008 and RFC 3090.
Table of Contents 📖
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Reserved Words. . . . . . . . . . . . . . . . . . . . . 4
2. Specification of the Delegation key Signer. . . . . . . . . . 4
2.1. Delegation Signer Record Model. . . . . . . . . . . . . 4
2.2. Protocol Change . . . . . . . . . . . . . . . . . . . . 5
2.2.1. RFC 2535 2.3.4 and 3.4: Special Considerations
at Delegation Points . . . . . . . . . . . . . 6
2.2.1.1. Special processing for DS queries. . . 6
2.2.1.2. Special processing when child and an
ancestor share nameserver. . . . . . . 7
2.2.1.3. Modification on use of KEY RR in the
construction of Responses. . . . . . . 8
2.2.2. Signer's Name (replaces RFC3008 section 2.7). . 9
2.2.3. Changes to RFC 3090 . . . . . . . . . . . . . . 9
2.2.3.1. RFC 3090: Updates to section 1:
Introduction . . . . . . . . . . . . . 9
2.2.3.2. RFC 3090 section 2.1: Globally
Secured. . . . . . . . . . . . . . . . 10
2.2.3.3. RFC 3090 section 3: Experimental
Status . . . . . . . . . . . . . . . . 10
2.2.4. NULL KEY elimination. . . . . . . . . . . . . . 10
2.3. Comments on Protocol Changes. . . . . . . . . . . . . . 10
2.4. Wire Format of the DS record. . . . . . . . . . . . . . 11
2.4.1. Justifications for Fields . . . . . . . . . . . 12
2.5. Presentation Format of the DS Record. . . . . . . . . . 12
2.6. Transition Issues for Installed Base. . . . . . . . . . 12
2.6.1. Backwards compatibility with RFC 2535 and
RFC 1035. . . . . . . . . . . . . . . . . . . . 12
2.7. KEY and corresponding DS record example . . . . . . . . 13
3. Resolver. . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. DS Example" . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Resolver Cost Estimates for DS Records" . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Intellectual Property Statement . . . . . . . . . . . . . . . 16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References. . . . . . . . . . . . . . . . . . 17
8.2. Informational References. . . . . . . . . . . . . . . . 17
9. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 18
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 191. Introduction 🎀
Knowing the DNS system [RFC1035], DNS security extensions [RFC2535], and DNSSEC terminology [RFC3090] is super important 📚.
Here's the tea 🍵: when the same data can live in two administratively different DNS zones, it gets out of sync all the time. An NS RRset showing up in a zone anywhere other than the apex means there's a zone cut or delegation 🦋. The RDATA of that NS RRset names the authoritative nameservers for the delegated, or "child", zone. Based on actual measurements, 10-30% of all delegations on the Internet have differing NS RRsets at parent and child 😭. Reasons include a lack of communication between parent and child, and bogus name servers being listed to meet registry requirements.
DNSSEC [RFC2535, RFC3008, RFC3090] says a child zone needs its KEY RRset signed by its parent so you get a verifiable chain of KEYs 🔗. There's been some debate about where that signed KEY RRset should live: at the child [RFC2535], or at the parent. If the KEY RRset lives at the child, keeping the signed copy up to date takes frequent two-way communication between the two parties 💬. The child sends the KEY RRset to the parent, then the parent sends the signature(s) back. Storing the KEY RRset at the parent was thought to simplify all that 🧚.
DNSSEC [RFC2535] requires that the parent store a NULL KEY record for an unsecure child zone to indicate that the child is unsecure. Honestly, a NULL KEY record is a waste 💀: a whole signed RRset is used to communicate effectively one bit of information, which is that the child is unsecure. Chasing down NULL KEY RRsets complicates resolution in many cases, because nameservers for both parent and child need to be queried for the KEY RRset if the child nameserver doesn't return it. Storing the KEY RRset only in the parent zone simplifies this and would allow the elimination of NULL KEY RRsets entirely ✨. For large delegation zones, the cost of NULL keys is a significant barrier to deployment.
Before the restrictions imposed by RFC 3445 [RFC3445], another implication of the DNSSEC key model was that the KEY record could store public keys for other protocols as well as DNSSEC keys 🌸. That comes with a bunch of potential problems, including:
- The KEY RRset can become quite large if many applications and protocols store their keys at the zone apex. Possible protocols are IPSEC, HTTP, SMTP, SSH and others that use public key cryptography.
- The KEY RRset may require frequent updates.
- The probability of compromised or lost keys, which trigger emergency key roll-over procedures, increases.
- The parent may refuse to sign KEY RRsets with non-DNSSEC zone keys.
- The parent may not meet the child's expectations of turnaround time for resigning the KEY RRset.
Given these reasons, SIG@parent isn't any better than SIG/KEY@Child 🙈.
1.2. Reserved Words 🔑
So these are the key words: "MAY", "MAY NOT", "MUST", "MUST NOT", "REQUIRED", "RECOMMENDED", "SHOULD", and "SHOULD NOT". Wherever they show up in this document, they're to be interpreted as described in BCP 14, RFC 2119 [RFC2119] 🫶.
2. Specification of the Delegation key Signer 👑
This section defines the Delegation Signer (DS) RR type (type code 43) and the changes to DNS that make room for it 💅.
2.1. Delegation Signer Record Model 🦋
This document presents a replacement for the DNSSEC KEY record chain of trust [RFC2535]. It uses a new RR that lives only at the parent 📍. This record identifies the key(s) the child uses to self-sign its own KEY RRset.
Even though DS identifies two roles for KEYs, Key Signing Key (KSK) and Zone Signing Key (ZSK), there is no requirement that a zone uses two different keys for these roles. It's expected that many small zones will only use one key, while larger zones will be more likely to use multiple keys 🌈.
The chain of trust is now established by verifying the parent KEY RRset, the DS RRset from the parent, and the KEY RRset at the child. This is cryptographically equivalent to using just KEY records 🔐.
Communication between the parent and child is greatly reduced, since the child only needs to notify the parent about changes in keys that sign its apex KEY RRset. The parent is ignorant of all other keys in the child's apex KEY RRset 🙈. Furthermore, the child keeps full control over the apex KEY RRset and its content. The child can maintain any policies about its KEY usage for DNSSEC with minimal impact on the parent. So if the child wants frequent key roll-over for its DNS zone keys, the parent doesn't need to know about it 💖. The child can use one key to sign only its apex KEY RRset, and a different key to sign the other RRsets in the zone.
This model fits well with a slow roll out of DNSSEC and the islands of security model. In this model, someone who trusts "good.example." can preconfigure a key from "good.example." as a trusted key, and from then on trusts any data signed by that key or that has a chain of trust to that key 🔑. If "example." starts advertising DS records, "good.example." doesn't have to change operations by suspending self-signing. DS records can be used in configuration files to identify trusted keys instead of KEY records. Another big win is that the amount of information stored in large delegation zones goes down: rather than the NULL KEY record at every unsecure delegation demanded by RFC 2535, only secure delegations need extra information, in the form of a signed DS RRset 🎉.
The main disadvantage of this approach is that verifying a zone's KEY RRset takes two signature verification operations instead of the one in the RFC 2535 chain of trust. There's no impact on the number of signatures verified for other types of RRsets 🧮.
2.2. Protocol Change 🔥
All DNS servers and resolvers that support DS MUST support the OK bit [RFC3225] and a larger message size [RFC3226]. In order for a delegation to be considered secure, the delegation MUST contain a DS RRset. If a query contains the OK bit, a nameserver returning a referral for the delegation MUST include the following RRsets in the authority section in this order:
If DS RRset is present:
parent's copy of child's NS RRset
DS and SIG(DS)
If no DS RRset is present:
parent's copy of child's NS RRset
parent's zone NXT and SIG(NXT)This makes referral messages bigger, which could mean some or all of the glue gets left out 📦. If the DS or NXT RRsets with signatures don't fit in the DNS message, the TC bit MUST be set. Additional section processing doesn't change 🙌.
A DS RRset next to an NS RRset means the child zone is secure 🔒. If an NS RRset exists without a DS RRset, the child zone is unsecure (from the parents point of view). DS RRsets MUST NOT appear at non-delegation points or at a zone's apex. 🚫
Section 2.2.1 defines special considerations for authoritative nameservers responding to DS queries, and it replaces RFC 2535 sections 2.3.4 and 3.4. Section 2.2.2 replaces RFC 3008 section 2.7, and section 2.2.3 updates RFC 3090 💖.
2.2.1. RFC 2535 2.3.4 and 3.4: Special Considerations at Delegation Points ✨
okay so DNS security sees each zone as one neat unit that the zone owner fully controls 💅 every entry (RRset) gets signed by a special private key held by the zone manager. but the DNS protocol sees the leaf nodes that are also the apex nodes of a child zone (aka delegation points) as "really" belonging to the child zone 🥺 those names show up in two master files and might have RRsets signed by both the parent and child keys. so a retrieval could get a messy mix of RRsets and SIGs, especially since one nameserver could be serving both the zone above and the zone below a delegation point [RFC2181] 🙈
Each DS RRset stored in the parent zone MUST be signed by at least one of the parent zone's private keys. The parent zone MUST NOT contain a KEY RRset at any delegation point. Delegations in the parent MAY contain only the following RR types: NS, DS, NXT and SIG. The NS RRset MUST NOT be signed. The NXT RRset is the exception 👑 it will always show up differently and authoritatively in both the parent and child zones, as long as both are secure.
A secure zone MUST contain a self-signed KEY RRset at its apex. After verifying the DS RRset from the parent, a resolver MAY trust any KEY identified in the DS RRset as a valid signer of the child's apex KEY RRset. Resolvers that are configured to trust one of the keys signing the KEY RRset MAY now treat any data signed by the zone keys in the KEY RRset as secure. In all other cases, resolvers MUST consider the zone unsecure. 🔒
An authoritative nameserver queried for type DS MUST return the DS RRset in the answer section. 🎀
2.2.1.1. Special processing for DS queries
When a nameserver is authoritative for the parent zone at a delegation point and gets a query for the DS record at that name, it MUST answer based on data in the parent zone, returning either the DS or a negative answer. This is true whether or not it's also authoritative for the child zone. ✨
When the nameserver is authoritative for the child zone at a delegation point but NOT the parent zone, there's no natural response, since the child zone isn't authoritative for the DS record at the zone's apex 💀 These queries are only expected to come from recursive nameservers that aren't DS-aware, so the authoritative nameserver MUST answer with:
RCODE: NOERROR
AA bit: set
Answer Section: Empty
Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]so basically it answers as if it's authoritative and the DS record just doesn't exist 🙈 DS-aware recursive nameservers query the parent zone at delegation points, so they won't be affected by this. 🧚
A nameserver that's authoritative for only the child zone, and is also a caching server, MAY (if the RD bit is set in the query) perform recursion to find the DS record at the delegation point, or MAY return the DS record from its cache. In this case, the AA bit MUST NOT be set in the response. 🦋
2.2.1.2. Special processing when child and an ancestor share nameserver
Special rules are needed so DS RR aware nameservers can interact nicely with older caches. Otherwise those caches might wrongly label a nameserver as lame because of where the DS RRset sits 😭
This kind of situation might happen when a nameserver is authoritative for both a zone and its grandparent, but not the parent. It sounds like a super obscure example, but it's very real 💅 The root zone is currently served on 13 machines, and "root-servers.net." is served on 4 of those 13, but "net." is served on different nameservers.
When a nameserver receives a query for (<QNAME>, DS, <QCLASS>), the response MUST be determined by reading these rules in order:
- If the nameserver is authoritative for the zone that holds the DS RR set (i.e., the zone that delegates <QNAME>, a.k.a. the "parent" zone), the response contains the DS RR set as an authoritative answer. 👑
- If the nameserver is offering recursive service and the RD bit is set in the query, the nameserver performs the query itself (according to the rules for resolvers described below) and returns its findings.
- If the nameserver is authoritative for the zone that holds the <QNAME>'s SOA RR set, the response is an authoritative negative answer as described in 2.2.1.1.
- If the nameserver is authoritative for a zone or zones above the QNAME, a referral to the most enclosing (deepest match) zone's servers is made.
- If the nameserver is not authoritative for any part of the QNAME, a response indicating a lame nameserver for QNAME is given.
Using these rules will require some special processing on the part of a DS RR aware resolver. Let's look at an example to see how it plays out 🌸
Say a nameserver is authoritative for roots.example.net. and for the root zone, but NOT for the two zones in between (or the intervening two label deep zone). Assume that QNAME=roots.example.net., QTYPE=DS, and QCLASS=IN.
The resolver will send this request (assuming no cached data) expecting a referral to a nameserver for .net. Instead, rule number 3 above applies and the nameserver returns a negative answer 😳 The resolver shouldn't accept this answer as final, because it can work out from the SOA RR in the negative answer which context the nameserver answered within.
One solution is to tell the resolver to hunt for the authoritative zone of the data in a brute force way. 🔍
To do that, take the owner name of the returned SOA RR and strip off enough left-hand labels until a successful NS response is obtained. A successful response here means the answer has NS records in it. (Keep in mind that a cut point can be two labels down in a zone.) 💖
Back to the example: the response will include a negative answer with either the SOA RR for "roots.example.net." or "example.net.", depending on whether roots.example.net is a delegated domain. Either way, removing the leftmost label of the SOA owner name will lead to the location of the data we want ✨
2.2.1.3. Modification on use of KEY RR in the construction of Responses
This section updates RFC 2535 section 3.5 by replacing it with the following:
A query for KEY RR MUST NOT trigger any additional section processing. Security aware resolvers will include corresponding SIG records in the answer section.
KEY records SHOULD NOT be added to the additional records section in response to any query.
RFC 2535 said KEY records should be added to the additional section when SOA or NS records were included in an answer. This was done to cut down on round trips (in the SOA case) and to force out NULL KEYs (in the NS case). Since this document obsoletes NULL KEYs, there's no reason to include KEYs with NSs anymore. Also, SOAs are included in the authority section of negative answers, so including the KEYs every time would cause redundant transfers of KEYs 🙄
RFC 2535 section 3.5 also had a rule for adding the KEY RRset to the response for a query for A and AAAA types. Since Restrict KEY [RFC3445] got rid of the use of KEY RR by all applications, this rule isn't needed anymore 🫶
2.2.2. Signer's Name (replaces RFC 3008 section 2.7)
The signer's name field of a SIG RR MUST contain the name of the zone to which the data and signature belong. The combination of signer's name, key tag, and algorithm MUST identify a zone key if the SIG is to be considered material. This document defines a standard policy for DNSSEC validation, but local policy MAY override the standard policy. 🔑
There are no restrictions on the signer field of a SIG(0) record. The combination of signer's name, key tag, and algorithm MUST identify a key if this SIG(0) is to be processed. 🦋
2.2.3. Changes to RFC 3090
A number of sections in RFC 3090 need to be updated to reflect the DS record. 🌈
2.2.3.1. RFC 3090: Updates to section 1: Introduction
Most of the text is still relevant, but the words "NULL key" are to be replaced with "missing DS RRset". In section 1.3, the last three paragraphs discuss the confusion in sections of RFC 2535 that are replaced in section 2.2.1 above. So those paragraphs are now obsolete 🙃
2.2.3.2. RFC 3090 section 2.1: Globally Secured
Rule 2.1.b is replaced by the following rule:
2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a private key whose public counterpart MUST appear in a zone signing KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to-implement algorithm. This KEY RR MUST be identified by a DS RR in a signed DS RRset in the parent zone. 👑
If a zone can't get its parent to advertise a DS record for it, the child zone CANNOT be considered globally secured. The only exception is the root zone, since there's no parent zone for it 🌸
2.2.3.3. RFC 3090 section 3: Experimental Status.
The only difference between experimental status and globally secured is the missing DS RRset in the parent zone. All locally secured zones are experimental. 🧪
2.2.4. NULL KEY elimination
RFC 3445 section 3 eliminates the top two bits in the flags field of the KEY RR. Those two bits were used to indicate NULL KEY or NO KEY. RFC 3090 defines a zone as either secure or not, and these rules remove the need to put NULL keys at the zone apex to show that the zone isn't secured for an algorithm. Together with this document, these other two changes eliminate all uses for the NULL KEY. This document obsoletes NULL KEY. 💀✨
2.3. Comments on Protocol Changes
Over the years there've been lots of discussions about the DNS delegation model, with people calling it broken because there's no good way to assert whether a delegation exists 😤 In the RFC 2535 version of DNSSEC, the presence of the NS bit in the NXT bit map proves there's a delegation at that name. But something more explicit is required, and the DS record addresses that need for secure delegations. 🎀
The DS record is a major change to DNS: it's the first resource record that can appear ONLY on the upper side of a delegation. Adding it will cause interoperability problems and requires a flag day for DNSSEC. Many old nameservers and resolvers MUST be upgraded to take advantage of DS. Some old nameservers will be able to be authoritative for zones with DS records but won't add the NXT or DS records to the authority section. The same goes for caching nameservers; in fact, some might even refuse to pass on the DS or NXT records. 🚩
2.4. Wire Format of the DS record 🎀
Okay so the DS (type=43) record has these fields: key tag, algorithm, digest type, and the digest of a public key KEY record that is allowed and/or used to sign the child's apex KEY RRset. Other keys MAY sign the child's apex KEY RRset. ✨
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key tag | algorithm | Digest type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digest (length depends on type) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (SHA-1 digest is 20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The key tag is calculated as specified in RFC 2535. Algorithm MUST be allowed to sign DNS data. The digest type is an identifier for the digest algorithm used. The digest is calculated over the canonical name of the delegated domain name followed by the whole RDATA of the KEY record (all four fields). 🔍
digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)
KEY_RR_rdata = Flags | Protocol | Algorithm | Public KeyDigest type value 0 is reserved, value 1 is SHA-1, and reserving other types requires IETF standards action. For interoperability reasons, keeping number of digest algorithms low is strongly RECOMMENDED. The only reason to reserve additional digest types is to increase security. 🌸
DS records MUST point to zone KEY records that are allowed to authenticate DNS data. The indicated KEY records protocol field MUST be set to 3; flag field bit 7 MUST be set to 1. The value of other flag bits is not significant for the purposes of this document. 💜
The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless of key size. New digest types probably will have larger digests. 🦋
2.4.1. Justifications for Fields 💅
The algorithm and key tag fields are there so resolvers can quickly spot the candidate KEY records to check. SHA-1 is a strong cryptographic checksum: it is computationally infeasible for an attacker to generate a KEY record that has the same SHA-1 digest. Combining the name of the key and the key rdata as input to the digest gives a stronger binding. Having the key tag in the DS record adds more assurance than the SHA-1 digest alone, since there are now two different mapping functions. 🔥
This format is a concise way to represent the keys that the child will use, which keeps the answer for the delegation small and lowers the chance of a DNS message overflowing. The SHA-1 hash is strong enough to uniquely identify the key and is similar to the PGP key footprint. The digest type field is there for possible future expansion. 🌈
The DS record is well suited to listing trusted keys for islands of security in configuration files. ⭐
2.5. Presentation Format of the DS Record 🍓
The presentation format of the DS record consists of three numbers (key tag, algorithm, and digest type) followed by the digest itself presented in hex:
example. DS 12345 3 1 123456789abcdef67890123456789abcdef678902.6. Transition Issues for Installed Base 🫶
No backwards compatibility with RFC 2535 is provided. 🙈
RFC 2535-compliant resolvers will assume that all DS-secured delegations are locally secure. This is bad, but the DNSEXT Working Group has determined that rather than dealing with both RFC 2535-secured zones and DS-secured zones, a rapid adoption of DS is preferable. Thus, the only option for early adopters is to upgrade to DS as soon as possible. 😭
2.6.1. Backwards compatibility with RFC 2535 and RFC 1035 👑
This section documents how a resolver determines the type of delegation. 🧐
RFC 1035 delegation (in parent) has:
RFC 1035 NSRFC 2535 adds the following two cases:
Secure RFC 2535: NS + NXT + SIG(NXT)
NXT bit map contains: NS SIG NXT
Unsecure RFC 2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
NXT bit map contains: NS SIG KEY NXT
KEY must be a NULL key.DNSSEC with DS has the following two states:
Secure DS: NS + DS + SIG(DS)
NXT bit map contains: NS SIG NXT DS
Unsecure DS: NS + NXT + SIG(NXT)
NXT bit map contains: NS SIG NXTIt is difficult for a resolver to determine if a delegation is secure RFC 2535 or unsecure DS. This could be overcome by adding a flag to the NXT bit map, but only upgraded resolvers would understand this flag, anyway. Having both parent and child signatures for a KEY RRset might allow old resolvers to accept a zone as secure, but the cost of doing this for a long time is much higher than just prohibiting RFC 2535-style signatures at child zone apexes and forcing rapid deployment of DS-enabled nameservers and resolvers. 🚀
RFC 2535 and DS can, in theory, be deployed in parallel, but this would require resolvers to deal with RFC 2535 configurations forever. This document obsoletes the NULL KEY in parent zones, which is a difficult enough change that to cause a flag day. 🌟
2.7. KEY and corresponding DS record example 🧚
This is an example of a KEY record and the corresponding DS record.
dskey.example. KEY 256 3 1 (
AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
) ; key id = 28668
DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE3. Resolver 🔮
3.1. DS Example ✨
To create a chain of trust, a resolver goes from trusted KEY to DS to KEY. 🔗
Assume the key for domain "example." is trusted. Zone "example."
contains at least the following records:
example. SOA <soa stuff>
example. NS ns.example.
example. KEY <stuff>
example. NXT secure.example. NS SOA KEY SIG NXT
example. SIG(SOA)
example. SIG(NS)
example. SIG(NXT)
example. SIG(KEY)
secure.example. NS ns1.secure.example.
secure.example. DS tag=12345 alg=3 digest_type=1 <foofoo>
secure.example. NXT unsecure.example. NS SIG NXT DS
secure.example. SIG(NXT)
secure.example. SIG(DS)
unsecure.example NS ns1.unsecure.example.
unsecure.example. NXT example. NS SIG NXT
unsecure.example. SIG(NXT)
In zone "secure.example." following records exist:
secure.example. SOA <soa stuff>
secure.example. NS ns1.secure.example.
secure.example. KEY <tag=12345 alg=3>
secure.example. KEY <tag=54321 alg=5>
secure.example. NXT <nxt stuff>
secure.example. SIG(KEY) <key-tag=12345 alg=3>
secure.example. SIG(SOA) <key-tag=54321 alg=5>
secure.example. SIG(NS) <key-tag=54321 alg=5>
secure.example. SIG(NXT) <key-tag=54321 alg=5>In this example, the private key for "example." signs the DS record for "secure.example.", making that a secure delegation. The DS record states which key is expected to sign the KEY RRset at "secure.example.". Here "secure.example." signs its KEY RRset with the KEY identified in the DS RRset, thus the KEY RRset is validated and trusted. 🥰
This example has only one DS record for the child, but parents MUST allow multiple DS records to facilitate key roll-over and multiple KEY algorithms. 🔄
The resolver determines the security status of "unsecure.example." by examining the parent zone's NXT record for this name. The absence of the DS bit indicates an unsecure delegation. Note the NXT record SHOULD only be examined after verifying the corresponding signature. 🕵️♀️
3.2. Resolver Cost Estimates for DS Records 💸
From a RFC 2535 recursive resolver point of view, for each delegation followed to chase down an answer, one KEY RRset has to be verified. Additional RRsets might also need to be verified based on local policy (e.g., the contents of the NS RRset). Once the resolver gets to the appropriate delegation, validating the answer might require verifying one or more signatures. A simple A record lookup requires at least N delegations to be verified and one RRset. For a DS-enabled recursive resolver, the cost is 2N+1. For an MX record, where the target of the MX record is in the same zone as the MX record, the costs are N+2 and 2N+2, for RFC 2535 and DS, respectively. In the case of a negative answer, the same ratios hold true. 🧮
The recursive resolver has to do an extra query to get the DS record, which will increase the overall cost of resolving this question, but it will never be worse than chasing down NULL KEY records from the parent in RFC 2535 DNSSEC. 💁♀️
DS adds processing overhead on resolvers and increases the size of delegation answers, but much less than storing signatures in the parent zone. 🎀
4. Security Considerations 💀
This document proposes a change to the validation chain of KEY records in DNSSEC. The change is not believed to reduce security in the overall system. In RFC 2535 DNSSEC, the child zone has to communicate keys to its parent and prudent parents will require some authentication with that transaction. The modified protocol will require the same authentication, but allows the child to exert more local control over its own KEY RRset. 🛡️
There is a remote possibility that an attacker could generate a valid KEY that matches all the DS fields, of a specific DS set, and thus forge data from the child. This possibility is considered impractical, as on average more than
2 ^ (160 - <Number of keys in DS set>)keys would have to be generated before a match would be found. 😱
An attacker that wants to match any DS record will have to generate on average at least 2^80 keys. 🫣
The DS record represents a change to the DNSSEC protocol and there is an installed base of implementations, as well as textbooks on how to set up secure delegations. Implementations that do not understand the DS record will not be able to follow the KEY to DS to KEY chain and will consider all zones secured that way as unsecure. 🚨
5. IANA Considerations 🌈
IANA has allocated an RR type code for DS from the standard RR type space (type 43). 🎉
IANA has established a new registry for the DS RR type for digest algorithms. Defined types are:
0 is Reserved,
1 is SHA-1.Adding new reservations requires IETF standards action. 🏁
6. Intellectual Property Statement ✨
Okay so, bestie, the IETF is basically saying "we don't take a side 💅" on whether any intellectual property rights might apply to the tech in this doc, or whether you can actually get a license for them. It also doesn't claim it went looking for any of those rights either. 🙈 If you want the IETF's rules on rights for standards-track and standards-related docs, those live in BCP-11. Any claims of rights that were filed for publication, any promises of licenses, or the results of trying to get a general license for implementers or users can be requested from the IETF Secretariat. Lowkey very official, but it's giving transparency 🎀
The IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to practice this standard. Send that info to the IETF Executive Director. 🫶
7. Acknowledgments 🌸
Okay, the people who helped build the ideas in this doc over the last few years deserve all the flowers 💐 The core idea of using one key to sign only the KEY RRset came out of chats with Bill Manning and Perry Metzger about how to put a single root key into all resolvers. 🔑 Then there's a whole squad who also dropped useful comments: Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie, Jakob Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt Larson, Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker, Miek Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark Andrews, Harald Alvestrand, and others. Main character energy for all of them 👑
8. References 📚
8.1. Normative References
- [RFC1035]: Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
- [RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2535]: Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
- [RFC3008]: Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000.
- [RFC3090]: Lewis, E., "DNS Security Extension Clarification on Zone Status", RFC 3090, March 2001.
- [RFC3225]: Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
- [RFC3445]: Massey, D. and S. Rose, "Limiting the scope of the KEY Resource Record (RR)", RFC 3445, December 2002.
8.2. Informational References
- [RFC2181]: Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
- [RFC3226]: Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001.
9. Author's Address 🧚
Olafur Gudmundsson 3821 Village Park Drive Chevy Chase, MD, 20815
EMail: ds-rfc@ogud.com
10. Full Copyright Statement 💜
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Acknowledgement 🎀
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc3658 2003-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms