7Network Working Group O. Gudmundsson
8Request for Comments: 3658 December 2003
9Updates: 3090, 3008, 2535, 1035
10Category: Standards Track
13 Delegation Signer (DS) Resource Record (RR)
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
25 Copyright (C) The Internet Society (2003). All Rights Reserved.
29 The delegation signer (DS) resource record (RR) is inserted at a zone
30 cut (i.e., a delegation point) to indicate that the delegated zone is
31 digitally signed and that the delegated zone recognizes the indicated
32 key as a valid zone key for the delegated zone. The DS RR is a
33 modification to the DNS Security Extensions definition, motivated by
34 operational considerations. The intent is to use this resource
35 record as an explicit statement about the delegation, rather than
38 This document defines the DS RR, gives examples of how it is used and
39 describes the implications on resolvers. This change is not
40 backwards compatible with RFC 2535. This document updates RFC 1035,
41 RFC 2535, RFC 3008 and RFC 3090.
58Gudmundsson Standards Track [Page 1]
60RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
65 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
66 1.2. Reserved Words. . . . . . . . . . . . . . . . . . . . . 4
67 2. Specification of the Delegation key Signer. . . . . . . . . . 4
68 2.1. Delegation Signer Record Model. . . . . . . . . . . . . 4
69 2.2. Protocol Change . . . . . . . . . . . . . . . . . . . . 5
70 2.2.1. RFC 2535 2.3.4 and 3.4: Special Considerations
71 at Delegation Points . . . . . . . . . . . . . 6
72 2.2.1.1. Special processing for DS queries. . . 6
73 2.2.1.2. Special processing when child and an
74 ancestor share nameserver. . . . . . . 7
75 2.2.1.3. Modification on use of KEY RR in the
76 construction of Responses. . . . . . . 8
77 2.2.2. Signer's Name (replaces RFC3008 section 2.7). . 9
78 2.2.3. Changes to RFC 3090 . . . . . . . . . . . . . . 9
79 2.2.3.1. RFC 3090: Updates to section 1:
80 Introduction . . . . . . . . . . . . . 9
81 2.2.3.2. RFC 3090 section 2.1: Globally
82 Secured. . . . . . . . . . . . . . . . 10
83 2.2.3.3. RFC 3090 section 3: Experimental
84 Status . . . . . . . . . . . . . . . . 10
85 2.2.4. NULL KEY elimination. . . . . . . . . . . . . . 10
86 2.3. Comments on Protocol Changes. . . . . . . . . . . . . . 10
87 2.4. Wire Format of the DS record. . . . . . . . . . . . . . 11
88 2.4.1. Justifications for Fields . . . . . . . . . . . 12
89 2.5. Presentation Format of the DS Record. . . . . . . . . . 12
90 2.6. Transition Issues for Installed Base. . . . . . . . . . 12
91 2.6.1. Backwards compatibility with RFC 2535 and
92 RFC 1035. . . . . . . . . . . . . . . . . . . . 12
93 2.7. KEY and corresponding DS record example . . . . . . . . 13
94 3. Resolver. . . . . . . . . . . . . . . . . . . . . . . . . . . 14
95 3.1. DS Example" . . . . . . . . . . . . . . . . . . . . . . 14
96 3.2. Resolver Cost Estimates for DS Records" . . . . . . . . 15
97 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
98 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
99 6. Intellectual Property Statement . . . . . . . . . . . . . . . 16
100 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
101 8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
102 8.1. Normative References. . . . . . . . . . . . . . . . . . 17
103 8.2. Informational References. . . . . . . . . . . . . . . . 17
104 9. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 18
105 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
114Gudmundsson Standards Track [Page 2]
116RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
121 Familiarity with the DNS system [RFC1035], DNS security extensions
122 [RFC2535], and DNSSEC terminology [RFC3090] is important.
124 Experience shows that when the same data can reside in two
125 administratively different DNS zones, the data frequently gets out of
126 sync. The presence of an NS RRset in a zone anywhere other than at
127 the apex indicates a zone cut or delegation. The RDATA of the NS
128 RRset specifies the authoritative nameservers for the delegated or
129 "child" zone. Based on actual measurements, 10-30% of all
130 delegations on the Internet have differing NS RRsets at parent and
131 child. There are a number of reasons for this, including a lack of
132 communication between parent and child and bogus name servers being
133 listed to meet registry requirements.
135 DNSSEC [RFC2535, RFC3008, RFC3090] specifies that a child zone needs
136 to have its KEY RRset signed by its parent to create a verifiable
137 chain of KEYs. There has been some debate on where the signed KEY
138 RRset should reside, whether at the child [RFC2535] or at the parent.
139 If the KEY RRset resides at the child, maintaining the signed KEY
140 RRset in the child requires frequent two-way communication between
141 the two parties. First, the child transmits the KEY RRset to the
142 parent and then the parent sends the signature(s) to the child.
143 Storing the KEY RRset at the parent was thought to simplify the
146 DNSSEC [RFC2535] requires that the parent store a NULL KEY record for
147 an unsecure child zone to indicate that the child is unsecure. A
148 NULL KEY record is a waste: an entire signed RRset is used to
149 communicate effectively one bit of information - that the child is
150 unsecure. Chasing down NULL KEY RRsets complicates the resolution
151 process in many cases, because nameservers for both parent and child
152 need to be queried for the KEY RRset if the child nameserver does not
153 return it. Storing the KEY RRset only in the parent zone simplifies
154 this and would allow the elimination of the NULL KEY RRsets entirely.
155 For large delegation zones, the cost of NULL keys is a significant
156 barrier to deployment.
158 Prior to the restrictions imposed by RFC 3445 [RFC3445], another
159 implication of the DNSSEC key model is that the KEY record could be
160 used to store public keys for other protocols in addition to DNSSEC
161 keys. There are a number of potential problems with this, including:
163 1. The KEY RRset can become quite large if many applications and
164 protocols store their keys at the zone apex. Possible protocols
165 are IPSEC, HTTP, SMTP, SSH and others that use public key
170Gudmundsson Standards Track [Page 3]
172RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
175 2. The KEY RRset may require frequent updates.
177 3. The probability of compromised or lost keys, which trigger
178 emergency key roll-over procedures, increases.
180 4. The parent may refuse to sign KEY RRsets with non-DNSSEC zone
183 5. The parent may not meet the child's expectations of turnaround
184 time for resigning the KEY RRset.
186 Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.
190 The key words "MAY", "MAY NOT", "MUST", "MUST NOT", "REQUIRED",
191 "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
192 interpreted as described in BCP 14, RFC 2119 [RFC2119].
1942. Specification of the Delegation key Signer
196 This section defines the Delegation Signer (DS) RR type (type code
197 43) and the changes to DNS to accommodate it.
1992.1. Delegation Signer Record Model
201 This document presents a replacement for the DNSSEC KEY record chain
202 of trust [RFC2535] that uses a new RR that resides only at the
203 parent. This record identifies the key(s) that the child uses to
204 self-sign its own KEY RRset.
206 Even though DS identifies two roles for KEYs, Key Signing Key (KSK)
207 and Zone Signing Key (ZSK), there is no requirement that zone uses
208 two different keys for these roles. It is expected that many small
209 zones will only use one key, while larger zones will be more likely
210 to use multiple keys.
212 The chain of trust is now established by verifying the parent KEY
213 RRset, the DS RRset from the parent and the KEY RRset at the child.
214 This is cryptographically equivalent to using just KEY records.
216 Communication between the parent and child is greatly reduced, since
217 the child only needs to notify the parent about changes in keys that
218 sign its apex KEY RRset. The parent is ignorant of all other keys in
219 the child's apex KEY RRset. Furthermore, the child maintains full
220 control over the apex KEY RRset and its content. The child can
221 maintain any policies regarding its KEY usage for DNSSEC with minimal
222 impact on the parent. Thus, if the child wants to have frequent key
226Gudmundsson Standards Track [Page 4]
228RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
231 roll-over for its DNS zone keys, the parent does not need to be aware
232 of it. The child can use one key to sign only its apex KEY RRset and
233 a different key to sign the other RRsets in the zone.
235 This model fits well with a slow roll out of DNSSEC and the islands
236 of security model. In this model, someone who trusts "good.example."
237 can preconfigure a key from "good.example." as a trusted key, and
238 from then on trusts any data signed by that key or that has a chain
239 of trust to that key. If "example." starts advertising DS records,
240 "good.example." does not have to change operations by suspending
241 self-signing. DS records can be used in configuration files to
242 identify trusted keys instead of KEY records. Another significant
243 advantage is that the amount of information stored in large
244 delegation zones is reduced: rather than the NULL KEY record at every
245 unsecure delegation demanded by RFC 2535, only secure delegations
246 require additional information in the form of a signed DS RRset.
248 The main disadvantage of this approach is that verifying a zone's KEY
249 RRset requires two signature verification operations instead of the
250 one in RFC 2535 chain of trust. There is no impact on the number of
251 signatures verified for other types of RRsets.
255 All DNS servers and resolvers that support DS MUST support the OK bit
256 [RFC3225] and a larger message size [RFC3226]. In order for a
257 delegation to be considered secure the delegation MUST contain a DS
258 RRset. If a query contains the OK bit, a nameserver returning a
259 referral for the delegation MUST include the following RRsets in the
260 authority section in this order:
262 If DS RRset is present:
263 parent's copy of child's NS RRset
266 If no DS RRset is present:
267 parent's copy of child's NS RRset
268 parent's zone NXT and SIG(NXT)
270 This increases the size of referral messages, possibly causing some
271 or all glue to be omitted. If the DS or NXT RRsets with signatures
272 do not fit in the DNS message, the TC bit MUST be set. Additional
273 section processing is not changed.
275 A DS RRset accompanying a NS RRset indicates that the child zone is
276 secure. If a NS RRset exists without a DS RRset, the child zone is
277 unsecure (from the parents point of view). DS RRsets MUST NOT appear
278 at non-delegation points or at a zone's apex.
282Gudmundsson Standards Track [Page 5]
284RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
287 Section 2.2.1 defines special considerations related to authoritative
288 nameservers responding to DS queries and replaces RFC 2535 sections
289 2.3.4 and 3.4. Section 2.2.2 replaces RFC 3008 section 2.7, and
290 section 2.2.3 updates RFC 3090.
2922.2.1. RFC 2535 2.3.4 and 3.4: Special Considerations at Delegation
295 DNS security views each zone as a unit of data completely under the
296 control of the zone owner with each entry (RRset) signed by a special
297 private key held by the zone manager. But the DNS protocol views the
298 leaf nodes in a zone that are also the apex nodes of a child zone
299 (i.e., delegation points) as "really" belonging to the child zone.
300 The corresponding domain names appear in two master files and might
301 have RRsets signed by both the parent and child zones' keys. A
302 retrieval could get a mixture of these RRsets and SIGs, especially
303 since one nameserver could be serving both the zone above and below a
304 delegation point [RFC2181].
306 Each DS RRset stored in the parent zone MUST be signed by at least
307 one of the parent zone's private keys. The parent zone MUST NOT
308 contain a KEY RRset at any delegation point. Delegations in the
309 parent MAY contain only the following RR types: NS, DS, NXT and SIG.
310 The NS RRset MUST NOT be signed. The NXT RRset is the exceptional
311 case: it will always appear differently and authoritatively in both
312 the parent and child zones, if both are secure.
314 A secure zone MUST contain a self-signed KEY RRset at its apex. Upon
315 verifying the DS RRset from the parent, a resolver MAY trust any KEY
316 identified in the DS RRset as a valid signer of the child's apex KEY
317 RRset. Resolvers configured to trust one of the keys signing the KEY
318 RRset MAY now treat any data signed by the zone keys in the KEY RRset
319 as secure. In all other cases, resolvers MUST consider the zone
322 An authoritative nameserver queried for type DS MUST return the DS
323 RRset in the answer section.
3252.2.1.1. Special processing for DS queries
327 When a nameserver is authoritative for the parent zone at a
328 delegation point and receives a query for the DS record at that name,
329 it MUST answer based on data in the parent zone, return DS or
330 negative answer. This is true whether or not it is also
331 authoritative for the child zone.
338Gudmundsson Standards Track [Page 6]
340RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
343 When the nameserver is authoritative for the child zone at a
344 delegation point but not the parent zone, there is no natural
345 response, since the child zone is not authoritative for the DS record
346 at the zone's apex. As these queries are only expected to originate
347 from recursive nameservers which are not DS-aware, the authoritative
348 nameserver MUST answer with:
352 Answer Section: Empty
353 Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
355 That is, it answers as if it is authoritative and the DS record does
356 not exist. DS-aware recursive nameservers will query the parent zone
357 at delegation points, so will not be affected by this.
359 A nameserver authoritative for only the child zone, that is also a
360 caching server MAY (if the RD bit is set in the query) perform
361 recursion to find the DS record at the delegation point, or MAY
362 return the DS record from its cache. In this case, the AA bit MUST
363 NOT be set in the response.
3652.2.1.2. Special processing when child and an ancestor share
368 Special rules are needed to permit DS RR aware nameservers to
369 gracefully interact with older caches which otherwise might falsely
370 label a nameserver as lame because of the placement of the DS RR set.
372 Such a situation might arise when a nameserver is authoritative for
373 both a zone and it's grandparent, but not the parent. This sounds
374 like an obscure example, but it is very real. The root zone is
375 currently served on 13 machines, and "root-servers.net." is served on
376 4 of the 13, but "net." is severed on different nameservers.
378 When a nameserver receives a query for (<QNAME>, DS, <QCLASS>), the
379 response MUST be determined from reading these rules in order:
381 1) If the nameserver is authoritative for the zone that holds the DS
382 RR set (i.e., the zone that delegates <QNAME>, a.k.a. the "parent"
383 zone), the response contains the DS RR set as an authoritative
386 2) If the nameserver is offering recursive service and the RD bit is
387 set in the query, the nameserver performs the query itself
388 (according to the rules for resolvers described below) and returns
394Gudmundsson Standards Track [Page 7]
396RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
399 3) If the nameserver is authoritative for the zone that holds the
400 <QNAME>'s SOA RR set, the response is an authoritative negative
401 answer as described in 2.2.1.1.
403 4) If the nameserver is authoritative for a zone or zones above the
404 QNAME, a referral to the most enclosing (deepest match) zone's
407 5) If the nameserver is not authoritative for any part of the QNAME,
408 a response indicating a lame nameserver for QNAME is given.
410 Using these rules will require some special processing on the part of
411 a DS RR aware resolver. To illustrate this, an example is used.
413 Assuming a nameserver is authoritative for roots.example.net. and for
414 the root zone but not the intervening two zones (or the intervening
415 two label deep zone). Assume that QNAME=roots.example.net.,
416 QTYPE=DS, and QCLASS=IN.
418 The resolver will issue this request (assuming no cached data)
419 expecting a referral to a nameserver for .net. Instead, rule number
420 3 above applies and a negative answer is returned by the nameserver.
421 The reaction by the resolver is not to accept this answer as final,
422 as it can determine from the SOA RR in the negative answer the
423 context within which the nameserver has answered.
425 A solution would be to instruct the resolver to hunt for the
426 authoritative zone of the data in a brute force manner.
428 This can be accomplished by taking the owner name of the returned SOA
429 RR and striping off enough left-hand labels until a successful NS
430 response is obtained. A successful response here means that the
431 answer has NS records in it. (Entertaining the possibility that a
432 cut point can be two labels down in a zone.)
434 Returning to the example, the response will include a negative answer
435 with either the SOA RR for "roots.example.net." or "example.net."
436 depending on whether roots.example.net is a delegated domain. In
437 either case, removing the left most label of the SOA owner name will
438 lead to the location of the desired data.
4402.2.1.3. Modification on use of KEY RR in the construction of Responses
442 This section updates RFC 2535 section 3.5 by replacing it with the
450Gudmundsson Standards Track [Page 8]
452RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
455 A query for KEY RR MUST NOT trigger any additional section
456 processing. Security aware resolvers will include corresponding SIG
457 records in the answer section.
459 KEY records SHOULD NOT be added to the additional records section in
460 response to any query.
462 RFC 2535 specified that KEY records be added to the additional
463 section when SOA or NS records were included in an answer. This was
464 done to reduce round trips (in the case of SOA) and to force out NULL
465 KEYs (in the NS case). As this document obsoletes NULL keys, there
466 is no need for the inclusion of KEYs with NSs. Furthermore, as SOAs
467 are included in the authority section of negative answers, including
468 the KEYs each time will cause redundant transfers of KEYs.
470 RFC 2535 section 3.5 also included a rule for adding the KEY RRset to
471 the response for a query for A and AAAA types. As Restrict KEY
472 [RFC3445] eliminated use of KEY RR by all applications, this rule is
4752.2.2. Signer's Name (replaces RFC 3008 section 2.7)
477 The signer's name field of a SIG RR MUST contain the name of the zone
478 to which the data and signature belong. The combination of signer's
479 name, key tag, and algorithm MUST identify a zone key if the SIG is
480 to be considered material. This document defines a standard policy
481 for DNSSEC validation; local policy MAY override the standard policy.
483 There are no restrictions on the signer field of a SIG(0) record. The
484 combination of signer's name, key tag, and algorithm MUST identify a
485 key if this SIG(0) is to be processed.
4872.2.3. Changes to RFC 3090
489 A number of sections in RFC 3090 need to be updated to reflect the DS
4922.2.3.1. RFC 3090: Updates to section 1: Introduction
494 Most of the text is still relevant but the words "NULL key" are to be
495 replaced with "missing DS RRset". In section 1.3, the last three
496 paragraphs discuss the confusion in sections of RFC 2535 that are
497 replaced in section 2.2.1 above. Therefore, these paragraphs are now
506Gudmundsson Standards Track [Page 9]
508RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
5112.2.3.2. RFC 3090 section 2.1: Globally Secured
513 Rule 2.1.b is replaced by the following rule:
515 2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a
516 private key whose public counterpart MUST appear in a zone signing
517 KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to-
518 implement algorithm. This KEY RR MUST be identified by a DS RR in a
519 signed DS RRset in the parent zone.
521 If a zone cannot get its parent to advertise a DS record for it, the
522 child zone cannot be considered globally secured. The only exception
523 to this is the root zone, for which there is no parent zone.
5252.2.3.3. RFC 3090 section 3: Experimental Status.
527 The only difference between experimental status and globally secured
528 is the missing DS RRset in the parent zone. All locally secured
529 zones are experimental.
5312.2.4. NULL KEY elimination
533 RFC 3445 section 3 eliminates the top two bits in the flags field of
534 KEY RR. These two bits were used to indicate NULL KEY or NO KEY. RFC
535 3090 defines that zone as either secure or not and these rules
536 eliminate the need to put NULL keys in the zone apex to indicate that
537 the zone is not secured for a algorithm. Along with this document,
538 these other two eliminate all uses for the NULL KEY. This document
5412.3. Comments on Protocol Changes
543 Over the years, there have been various discussions surrounding the
544 DNS delegation model, declaring it to be broken because there is no
545 good way to assert if a delegation exists. In the RFC 2535 version
546 of DNSSEC, the presence of the NS bit in the NXT bit map proves there
547 is a delegation at this name. Something more explicit is required
548 and the DS record addresses this need for secure delegations.
550 The DS record is a major change to DNS: it is the first resource
551 record that can appear only on the upper side of a delegation.
552 Adding it will cause interoperability problems and requires a flag
553 day for DNSSEC. Many old nameservers and resolvers MUST be upgraded
554 to take advantage of DS. Some old nameservers will be able to be
555 authoritative for zones with DS records but will not add the NXT or
556 DS records to the authority section. The same is true for caching
557 nameservers; in fact, some might even refuse to pass on the DS or NXT
562Gudmundsson Standards Track [Page 10]
564RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
5672.4. Wire Format of the DS record
569 The DS (type=43) record contains these fields: key tag, algorithm,
570 digest type, and the digest of a public key KEY record that is
571 allowed and/or used to sign the child's apex KEY RRset. Other keys
572 MAY sign the child's apex KEY RRset.
574 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
575 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
576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
577 | key tag | algorithm | Digest type |
578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
579 | digest (length depends on type) |
580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
581 | (SHA-1 digest is 20 bytes) |
582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
590 The key tag is calculated as specified in RFC 2535. Algorithm MUST
591 be allowed to sign DNS data. The digest type is an identifier for
592 the digest algorithm used. The digest is calculated over the
593 canonical name of the delegated domain name followed by the whole
594 RDATA of the KEY record (all four fields).
596 digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)
598 KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
600 Digest type value 0 is reserved, value 1 is SHA-1, and reserving
601 other types requires IETF standards action. For interoperability
602 reasons, keeping number of digest algorithms low is strongly
603 RECOMMENDED. The only reason to reserve additional digest types is
604 to increase security.
606 DS records MUST point to zone KEY records that are allowed to
607 authenticate DNS data. The indicated KEY records protocol field MUST
608 be set to 3; flag field bit 7 MUST be set to 1. The value of other
609 flag bits is not significant for the purposes of this document.
611 The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless
612 of key size. New digest types probably will have larger digests.
618Gudmundsson Standards Track [Page 11]
620RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
6232.4.1. Justifications for Fields
625 The algorithm and key tag fields are present to allow resolvers to
626 quickly identify the candidate KEY records to examine. SHA-1 is a
627 strong cryptographic checksum: it is computationally infeasible for
628 an attacker to generate a KEY record that has the same SHA-1 digest.
629 Combining the name of the key and the key rdata as input to the
630 digest provides stronger assurance of the binding. Having the key
631 tag in the DS record adds greater assurance than the SHA-1 digest
632 alone, as there are now two different mapping functions.
634 This format allows concise representation of the keys that the child
635 will use, thus keeping down the size of the answer for the
636 delegation, reducing the probability of DNS message overflow. The
637 SHA-1 hash is strong enough to uniquely identify the key and is
638 similar to the PGP key footprint. The digest type field is present
639 for possible future expansion.
641 The DS record is well suited to listing trusted keys for islands of
642 security in configuration files.
6442.5. Presentation Format of the DS Record
646 The presentation format of the DS record consists of three numbers
647 (key tag, algorithm, and digest type) followed by the digest itself
650 example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890
6522.6. Transition Issues for Installed Base
654 No backwards compatibility with RFC 2535 is provided.
656 RFC 2535-compliant resolvers will assume that all DS-secured
657 delegations are locally secure. This is bad, but the DNSEXT Working
658 Group has determined that rather than dealing with both RFC 2535-
659 secured zones and DS-secured zones, a rapid adoption of DS is
660 preferable. Thus, the only option for early adopters is to upgrade
661 to DS as soon as possible.
6632.6.1. Backwards compatibility with RFC 2535 and RFC 1035
665 This section documents how a resolver determines the type of
674Gudmundsson Standards Track [Page 12]
676RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
679 RFC 1035 delegation (in parent) has:
683 RFC 2535 adds the following two cases:
685 Secure RFC 2535: NS + NXT + SIG(NXT)
686 NXT bit map contains: NS SIG NXT
687 Unsecure RFC 2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
688 NXT bit map contains: NS SIG KEY NXT
689 KEY must be a NULL key.
691 DNSSEC with DS has the following two states:
693 Secure DS: NS + DS + SIG(DS)
694 NXT bit map contains: NS SIG NXT DS
695 Unsecure DS: NS + NXT + SIG(NXT)
696 NXT bit map contains: NS SIG NXT
698 It is difficult for a resolver to determine if a delegation is secure
699 RFC 2535 or unsecure DS. This could be overcome by adding a flag to
700 the NXT bit map, but only upgraded resolvers would understand this
701 flag, anyway. Having both parent and child signatures for a KEY
702 RRset might allow old resolvers to accept a zone as secure, but the
703 cost of doing this for a long time is much higher than just
704 prohibiting RFC 2535-style signatures at child zone apexes and
705 forcing rapid deployment of DS-enabled nameservers and resolvers.
707 RFC 2535 and DS can, in theory, be deployed in parallel, but this
708 would require resolvers to deal with RFC 2535 configurations forever.
709 This document obsoletes the NULL KEY in parent zones, which is a
710 difficult enough change that to cause a flag day.
7122.7. KEY and corresponding DS record example
714 This is an example of a KEY record and the corresponding DS record.
716 dskey.example. KEY 256 3 1 (
717 AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
718 4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
720 DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
730Gudmundsson Standards Track [Page 13]
732RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
739 To create a chain of trust, a resolver goes from trusted KEY to DS to
742 Assume the key for domain "example." is trusted. Zone "example."
743 contains at least the following records:
744 example. SOA <soa stuff>
745 example. NS ns.example.
747 example. NXT secure.example. NS SOA KEY SIG NXT
752 secure.example. NS ns1.secure.example.
753 secure.example. DS tag=12345 alg=3 digest_type=1 <foofoo>
754 secure.example. NXT unsecure.example. NS SIG NXT DS
755 secure.example. SIG(NXT)
756 secure.example. SIG(DS)
757 unsecure.example NS ns1.unsecure.example.
758 unsecure.example. NXT example. NS SIG NXT
759 unsecure.example. SIG(NXT)
761 In zone "secure.example." following records exist:
762 secure.example. SOA <soa stuff>
763 secure.example. NS ns1.secure.example.
764 secure.example. KEY <tag=12345 alg=3>
765 secure.example. KEY <tag=54321 alg=5>
766 secure.example. NXT <nxt stuff>
767 secure.example. SIG(KEY) <key-tag=12345 alg=3>
768 secure.example. SIG(SOA) <key-tag=54321 alg=5>
769 secure.example. SIG(NS) <key-tag=54321 alg=5>
770 secure.example. SIG(NXT) <key-tag=54321 alg=5>
772 In this example, the private key for "example." signs the DS record
773 for "secure.example.", making that a secure delegation. The DS
774 record states which key is expected to sign the KEY RRset at
775 "secure.example.". Here "secure.example." signs its KEY RRset with
776 the KEY identified in the DS RRset, thus the KEY RRset is validated
779 This example has only one DS record for the child, but parents MUST
780 allow multiple DS records to facilitate key roll-over and multiple
786Gudmundsson Standards Track [Page 14]
788RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
791 The resolver determines the security status of "unsecure.example." by
792 examining the parent zone's NXT record for this name. The absence of
793 the DS bit indicates an unsecure delegation. Note the NXT record
794 SHOULD only be examined after verifying the corresponding signature.
7963.2. Resolver Cost Estimates for DS Records
798 From a RFC 2535 recursive resolver point of view, for each delegation
799 followed to chase down an answer, one KEY RRset has to be verified.
800 Additional RRsets might also need to be verified based on local
801 policy (e.g., the contents of the NS RRset). Once the resolver gets
802 to the appropriate delegation, validating the answer might require
803 verifying one or more signatures. A simple A record lookup requires
804 at least N delegations to be verified and one RRset. For a DS-
805 enabled recursive resolver, the cost is 2N+1. For an MX record,
806 where the target of the MX record is in the same zone as the MX
807 record, the costs are N+2 and 2N+2, for RFC 2535 and DS,
808 respectively. In the case of a negative answer, the same ratios hold
811 The recursive resolver has to do an extra query to get the DS record,
812 which will increase the overall cost of resolving this question, but
813 it will never be worse than chasing down NULL KEY records from the
814 parent in RFC 2535 DNSSEC.
816 DS adds processing overhead on resolvers and increases the size of
817 delegation answers, but much less than storing signatures in the
8204. Security Considerations
822 This document proposes a change to the validation chain of KEY
823 records in DNSSEC. The change is not believed to reduce security in
824 the overall system. In RFC 2535 DNSSEC, the child zone has to
825 communicate keys to its parent and prudent parents will require some
826 authentication with that transaction. The modified protocol will
827 require the same authentication, but allows the child to exert more
828 local control over its own KEY RRset.
830 There is a remote possibility that an attacker could generate a valid
831 KEY that matches all the DS fields, of a specific DS set, and thus
832 forge data from the child. This possibility is considered
833 impractical, as on average more than
835 2 ^ (160 - <Number of keys in DS set>)
837 keys would have to be generated before a match would be found.
842Gudmundsson Standards Track [Page 15]
844RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
847 An attacker that wants to match any DS record will have to generate
848 on average at least 2^80 keys.
850 The DS record represents a change to the DNSSEC protocol and there is
851 an installed base of implementations, as well as textbooks on how to
852 set up secure delegations. Implementations that do not understand
853 the DS record will not be able to follow the KEY to DS to KEY chain
854 and will consider all zones secured that way as unsecure.
8565. IANA Considerations
858 IANA has allocated an RR type code for DS from the standard RR type
861 IANA has established a new registry for the DS RR type for digest
862 algorithms. Defined types are:
867 Adding new reservations requires IETF standards action.
8696. Intellectual Property Statement
871 The IETF takes no position regarding the validity or scope of any
872 intellectual property or other rights that might be claimed to
873 pertain to the implementation or use of the technology described in
874 this document or the extent to which any license under such rights
875 might or might not be available; neither does it represent that it
876 has made any effort to identify any such rights. Information on the
877 IETF's procedures with respect to rights in standards-track and
878 standards-related documentation can be found in BCP-11. Copies of
879 claims of rights made available for publication and any assurances of
880 licenses to be made available, or the result of an attempt made to
881 obtain a general license or permission for the use of such
882 proprietary rights by implementors or users of this specification can
883 be obtained from the IETF Secretariat.
885 The IETF invites any interested party to bring to its attention any
886 copyrights, patents or patent applications, or other proprietary
887 rights which may cover technology that may be required to practice
888 this standard. Please address the information to the IETF Executive
898Gudmundsson Standards Track [Page 16]
900RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
905 Over the last few years a number of people have contributed ideas
906 that are captured in this document. The core idea of using one key
907 to sign only the KEY RRset comes from discussions with Bill Manning
908 and Perry Metzger on how to put in a single root key in all
909 resolvers. Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie,
910 Jakob Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt
911 Larson, Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker,
912 Miek Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David
913 Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark
914 Andrews, Harald Alvestrand, and others have provided useful comments.
9188.1. Normative References
920 [RFC1035] Mockapetris, P., "Domain Names - Implementation and
921 Specification", STD 13, RFC 1035, November 1987.
923 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
924 Requirement Levels", BCP 14, RFC 2119, March 1997.
926 [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
927 RFC 2535, March 1999.
929 [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
930 Signing Authority", RFC 3008, November 2000.
932 [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone
933 Status", RFC 3090, March 2001.
935 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
938 [RFC3445] Massey, D. and S. Rose, "Limiting the scope of the KEY
939 Resource Record (RR)", RFC 3445, December 2002.
9418.2. Informational References
943 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
944 Specification", RFC 2181, July 1997.
946 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
947 message size requirements", RFC 3226, December 2001.
954Gudmundsson Standards Track [Page 17]
956RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
962 3821 Village Park Drive
963 Chevy Chase, MD, 20815
965 EMail: ds-rfc@ogud.com
1010Gudmundsson Standards Track [Page 18]
1012RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003
101510. Full Copyright Statement
1017 Copyright (C) The Internet Society (2003). All Rights Reserved.
1019 This document and translations of it may be copied and furnished to
1020 others, and derivative works that comment on or otherwise explain it
1021 or assist in its implementation may be prepared, copied, published
1022 and distributed, in whole or in part, without restriction of any
1023 kind, provided that the above copyright notice and this paragraph are
1024 included on all such copies and derivative works. However, this
1025 document itself may not be modified in any way, such as by removing
1026 the copyright notice or references to the Internet Society or other
1027 Internet organizations, except as needed for the purpose of
1028 developing Internet standards in which case the procedures for
1029 copyrights defined in the Internet Standards process must be
1030 followed, or as required to translate it into languages other than
1033 The limited permissions granted above are perpetual and will not be
1034 revoked by the Internet Society or its successors or assignees.
1036 This document and the information contained herein is provided on an
1037 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1038 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1039 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1040 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1041 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1045 Funding for the RFC Editor function is currently provided by the
1066Gudmundsson Standards Track [Page 19]