7Network Working Group R. Arends
8Request for Comments: 4034 Telematica Instituut
9Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
11Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
12 3007, 3597, 3226 VeriSign
13Category: Standards Track D. Massey
14 Colorado State University
20 Resource Records for the DNS Security Extensions
24 This document specifies an Internet standards track protocol for the
25 Internet community, and requests discussion and suggestions for
26 improvements. Please refer to the current edition of the "Internet
27 Official Protocol Standards" (STD 1) for the standardization state
28 and status of this protocol. Distribution of this memo is unlimited.
32 Copyright (C) The Internet Society (2005).
36 This document is part of a family of documents that describe the DNS
37 Security Extensions (DNSSEC). The DNS Security Extensions are a
38 collection of resource records and protocol modifications that
39 provide source authentication for the DNS. This document defines the
40 public key (DNSKEY), delegation signer (DS), resource record digital
41 signature (RRSIG), and authenticated denial of existence (NSEC)
42 resource records. The purpose and format of each resource record is
43 described in detail, and an example of each resource record is given.
45 This document obsoletes RFC 2535 and incorporates changes from all
58Arends, et al. Standards Track [Page 1]
60RFC 4034 DNSSEC Resource Records March 2005
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
66 1.1. Background and Related Documents . . . . . . . . . . . 3
67 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . 3
68 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 4
69 2.1. DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . 4
70 2.1.1. The Flags Field. . . . . . . . . . . . . . . . 4
71 2.1.2. The Protocol Field . . . . . . . . . . . . . . 5
72 2.1.3. The Algorithm Field. . . . . . . . . . . . . . 5
73 2.1.4. The Public Key Field . . . . . . . . . . . . . 5
74 2.1.5. Notes on DNSKEY RDATA Design . . . . . . . . . 5
75 2.2. The DNSKEY RR Presentation Format. . . . . . . . . . . 5
76 2.3. DNSKEY RR Example . . . . . . . . . . . . . . . . . . 6
77 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 6
78 3.1. RRSIG RDATA Wire Format. . . . . . . . . . . . . . . . 7
79 3.1.1. The Type Covered Field . . . . . . . . . . . . 7
80 3.1.2. The Algorithm Number Field . . . . . . . . . . 8
81 3.1.3. The Labels Field . . . . . . . . . . . . . . . 8
82 3.1.4. Original TTL Field . . . . . . . . . . . . . . 8
83 3.1.5. Signature Expiration and Inception Fields. . . 9
84 3.1.6. The Key Tag Field. . . . . . . . . . . . . . . 9
85 3.1.7. The Signer's Name Field. . . . . . . . . . . . 9
86 3.1.8. The Signature Field. . . . . . . . . . . . . . 9
87 3.2. The RRSIG RR Presentation Format . . . . . . . . . . . 10
88 3.3. RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11
89 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12
90 4.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13
91 4.1.1. The Next Domain Name Field . . . . . . . . . . 13
92 4.1.2. The Type Bit Maps Field. . . . . . . . . . . . 13
93 4.1.3. Inclusion of Wildcard Names in NSEC RDATA. . . 14
94 4.2. The NSEC RR Presentation Format. . . . . . . . . . . . 14
95 4.3. NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15
96 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 15
97 5.1. DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16
98 5.1.1. The Key Tag Field. . . . . . . . . . . . . . . 16
99 5.1.2. The Algorithm Field. . . . . . . . . . . . . . 16
100 5.1.3. The Digest Type Field. . . . . . . . . . . . . 17
101 5.1.4. The Digest Field . . . . . . . . . . . . . . . 17
102 5.2. Processing of DS RRs When Validating Responses . . . . 17
103 5.3. The DS RR Presentation Format. . . . . . . . . . . . . 17
104 5.4. DS RR Example. . . . . . . . . . . . . . . . . . . . . 18
105 6. Canonical Form and Order of Resource Records . . . . . . . . 18
106 6.1. Canonical DNS Name Order . . . . . . . . . . . . . . . 18
107 6.2. Canonical RR Form. . . . . . . . . . . . . . . . . . . 19
108 6.3. Canonical RR Ordering within an RRset. . . . . . . . . 20
109 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20
110 8. Security Considerations. . . . . . . . . . . . . . . . . . . 21
114Arends, et al. Standards Track [Page 2]
116RFC 4034 DNSSEC Resource Records March 2005
119 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
120 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
121 10.1. Normative References . . . . . . . . . . . . . . . . . 22
122 10.2. Informative References . . . . . . . . . . . . . . . . 23
123 A. DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24
124 A.1. DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24
125 A.1.1. Private Algorithm Types. . . . . . . . . . . . 25
126 A.2. DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25
127 B. Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25
128 B.1. Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27
129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
130 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29
134 The DNS Security Extensions (DNSSEC) introduce four new DNS resource
135 record types: DNS Public Key (DNSKEY), Resource Record Signature
136 (RRSIG), Next Secure (NSEC), and Delegation Signer (DS). This
137 document defines the purpose of each resource record (RR), the RR's
138 RDATA format, and its presentation format (ASCII representation).
1401.1. Background and Related Documents
142 This document is part of a family of documents defining DNSSEC, which
143 should be read together as a set.
145 [RFC4033] contains an introduction to DNSSEC and definition of common
146 terms; the reader is assumed to be familiar with this document.
147 [RFC4033] also contains a list of other documents updated by and
148 obsoleted by this document set.
150 [RFC4035] defines the DNSSEC protocol operations.
152 The reader is also assumed to be familiar with the basic DNS concepts
153 described in [RFC1034], [RFC1035], and the subsequent documents that
154 update them, particularly [RFC2181] and [RFC2308].
156 This document defines the DNSSEC resource records. All numeric DNS
157 type codes given in this document are decimal integers.
161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
163 document are to be interpreted as described in [RFC2119].
170Arends, et al. Standards Track [Page 3]
172RFC 4034 DNSSEC Resource Records March 2005
1752. The DNSKEY Resource Record
177 DNSSEC uses public key cryptography to sign and authenticate DNS
178 resource record sets (RRsets). The public keys are stored in DNSKEY
179 resource records and are used in the DNSSEC authentication process
180 described in [RFC4035]: A zone signs its authoritative RRsets by
181 using a private key and stores the corresponding public key in a
182 DNSKEY RR. A resolver can then use the public key to validate
183 signatures covering the RRsets in the zone, and thus to authenticate
186 The DNSKEY RR is not intended as a record for storing arbitrary
187 public keys and MUST NOT be used to store certificates or public keys
188 that do not directly relate to the DNS infrastructure.
190 The Type value for the DNSKEY RR type is 48.
192 The DNSKEY RR is class independent.
194 The DNSKEY RR has no special TTL requirements.
1962.1. DNSKEY RDATA Wire Format
198 The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
199 octet Protocol Field, a 1 octet Algorithm Field, and the Public Key
202 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
203 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
204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
205 | Flags | Protocol | Algorithm |
206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2122.1.1. The Flags Field
214 Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1,
215 then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's
216 owner name MUST be the name of a zone. If bit 7 has value 0, then
217 the DNSKEY record holds some other type of DNS public key and MUST
218 NOT be used to verify RRSIGs that cover RRsets.
220 Bit 15 of the Flags field is the Secure Entry Point flag, described
221 in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a
222 key intended for use as a secure entry point. This flag is only
226Arends, et al. Standards Track [Page 4]
228RFC 4034 DNSSEC Resource Records March 2005
231 intended to be a hint to zone signing or debugging software as to the
232 intended use of this DNSKEY record; validators MUST NOT alter their
233 behavior during the signature validation process in any way based on
234 the setting of this bit. This also means that a DNSKEY RR with the
235 SEP bit set would also need the Zone Key flag set in order to be able
236 to generate signatures legally. A DNSKEY RR with the SEP set and the
237 Zone Key flag not set MUST NOT be used to verify RRSIGs that cover
240 Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
241 creation of the DNSKEY RR and MUST be ignored upon receipt.
2432.1.2. The Protocol Field
245 The Protocol Field MUST have value 3, and the DNSKEY RR MUST be
246 treated as invalid during signature verification if it is found to be
247 some value other than 3.
2492.1.3. The Algorithm Field
251 The Algorithm field identifies the public key's cryptographic
252 algorithm and determines the format of the Public Key field. A list
253 of DNSSEC algorithm types can be found in Appendix A.1
2552.1.4. The Public Key Field
257 The Public Key Field holds the public key material. The format
258 depends on the algorithm of the key being stored and is described in
2612.1.5. Notes on DNSKEY RDATA Design
263 Although the Protocol Field always has value 3, it is retained for
264 backward compatibility with early versions of the KEY record.
2662.2. The DNSKEY RR Presentation Format
268 The presentation format of the RDATA portion is as follows:
270 The Flag field MUST be represented as an unsigned decimal integer.
271 Given the currently defined flags, the possible values are: 0, 256,
274 The Protocol Field MUST be represented as an unsigned decimal integer
277 The Algorithm field MUST be represented either as an unsigned decimal
278 integer or as an algorithm mnemonic as specified in Appendix A.1.
282Arends, et al. Standards Track [Page 5]
284RFC 4034 DNSSEC Resource Records March 2005
287 The Public Key field MUST be represented as a Base64 encoding of the
288 Public Key. Whitespace is allowed within the Base64 text. For a
289 definition of Base64 encoding, see [RFC3548].
2912.3. DNSKEY RR Example
293 The following DNSKEY RR stores a DNS zone key for example.com.
295 example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
296 Cbl+BBZH4b/0PY1kxkmvHjcZc8no
297 kfzj31GajIQKY+5CptLr3buXA10h
298 WqTkF7H6RfoRqXQeogmMHfpftf6z
299 Mv1LyBUgia7za6ZEzOJBOztyvhjL
300 742iU/TpPSEDhm2SNKLijfUppn1U
303 The first four text fields specify the owner name, TTL, Class, and RR
304 type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in
305 the Flags field has value 1. Value 3 is the fixed Protocol value.
306 Value 5 indicates the public key algorithm. Appendix A.1 identifies
307 algorithm type 5 as RSA/SHA1 and indicates that the format of the
308 RSA/SHA1 public key field is defined in [RFC3110]. The remaining
309 text is a Base64 encoding of the public key.
3113. The RRSIG Resource Record
313 DNSSEC uses public key cryptography to sign and authenticate DNS
314 resource record sets (RRsets). Digital signatures are stored in
315 RRSIG resource records and are used in the DNSSEC authentication
316 process described in [RFC4035]. A validator can use these RRSIG RRs
317 to authenticate RRsets from the zone. The RRSIG RR MUST only be used
318 to carry verification material (digital signatures) used to secure
321 An RRSIG record contains the signature for an RRset with a particular
322 name, class, and type. The RRSIG RR specifies a validity interval
323 for the signature and uses the Algorithm, the Signer's Name, and the
324 Key Tag to identify the DNSKEY RR containing the public key that a
325 validator can use to verify the signature.
327 Because every authoritative RRset in a zone must be protected by a
328 digital signature, RRSIG RRs must be present for names containing a
329 CNAME RR. This is a change to the traditional DNS specification
330 [RFC1034], which stated that if a CNAME is present for a name, it is
331 the only type allowed at that name. A RRSIG and NSEC (see Section 4)
332 MUST exist for the same name as a CNAME resource record in a signed
338Arends, et al. Standards Track [Page 6]
340RFC 4034 DNSSEC Resource Records March 2005
343 The Type value for the RRSIG RR type is 46.
345 The RRSIG RR is class independent.
347 An RRSIG RR MUST have the same class as the RRset it covers.
349 The TTL value of an RRSIG RR MUST match the TTL value of the RRset it
350 covers. This is an exception to the [RFC2181] rules for TTL values
351 of individual RRs within a RRset: individual RRSIG RRs with the same
352 owner name will have different TTL values if the RRsets they cover
353 have different TTL values.
3553.1. RRSIG RDATA Wire Format
357 The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
358 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
359 TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
360 Inception field, a 2 octet Key tag, the Signer's Name field, and the
363 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
364 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
365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
366 | Type Covered | Algorithm | Labels |
367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
370 | Signature Expiration |
371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
372 | Signature Inception |
373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3833.1.1. The Type Covered Field
385 The Type Covered field identifies the type of the RRset that is
386 covered by this RRSIG record.
394Arends, et al. Standards Track [Page 7]
396RFC 4034 DNSSEC Resource Records March 2005
3993.1.2. The Algorithm Number Field
401 The Algorithm Number field identifies the cryptographic algorithm
402 used to create the signature. A list of DNSSEC algorithm types can
403 be found in Appendix A.1
4053.1.3. The Labels Field
407 The Labels field specifies the number of labels in the original RRSIG
408 RR owner name. The significance of this field is that a validator
409 uses it to determine whether the answer was synthesized from a
410 wildcard. If so, it can be used to determine what owner name was
411 used in generating the signature.
413 To validate a signature, the validator needs the original owner name
414 that was used to create the signature. If the original owner name
415 contains a wildcard label ("*"), the owner name may have been
416 expanded by the server during the response process, in which case the
417 validator will have to reconstruct the original owner name in order
418 to validate the signature. [RFC4035] describes how to use the Labels
419 field to reconstruct the original owner name.
421 The value of the Labels field MUST NOT count either the null (root)
422 label that terminates the owner name or the wildcard label (if
423 present). The value of the Labels field MUST be less than or equal
424 to the number of labels in the RRSIG owner name. For example,
425 "www.example.com." has a Labels field value of 3, and
426 "*.example.com." has a Labels field value of 2. Root (".") has a
427 Labels field value of 0.
429 Although the wildcard label is not included in the count stored in
430 the Labels field of the RRSIG RR, the wildcard label is part of the
431 RRset's owner name when the signature is generated or verified.
4333.1.4. Original TTL Field
435 The Original TTL field specifies the TTL of the covered RRset as it
436 appears in the authoritative zone.
438 The Original TTL field is necessary because a caching resolver
439 decrements the TTL value of a cached RRset. In order to validate a
440 signature, a validator requires the original TTL. [RFC4035]
441 describes how to use the Original TTL field value to reconstruct the
450Arends, et al. Standards Track [Page 8]
452RFC 4034 DNSSEC Resource Records March 2005
4553.1.5. Signature Expiration and Inception Fields
457 The Signature Expiration and Inception fields specify a validity
458 period for the signature. The RRSIG record MUST NOT be used for
459 authentication prior to the inception date and MUST NOT be used for
460 authentication after the expiration date.
462 The Signature Expiration and Inception field values specify a date
463 and time in the form of a 32-bit unsigned number of seconds elapsed
464 since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
465 byte order. The longest interval that can be expressed by this
466 format without wrapping is approximately 136 years. An RRSIG RR can
467 have an Expiration field value that is numerically smaller than the
468 Inception field value if the expiration field value is near the
469 32-bit wrap-around point or if the signature is long lived. Because
470 of this, all comparisons involving these fields MUST use "Serial
471 number arithmetic", as defined in [RFC1982]. As a direct
472 consequence, the values contained in these fields cannot refer to
473 dates more than 68 years in either the past or the future.
4753.1.6. The Key Tag Field
477 The Key Tag field contains the key tag value of the DNSKEY RR that
478 validates this signature, in network byte order. Appendix B explains
479 how to calculate Key Tag values.
4813.1.7. The Signer's Name Field
483 The Signer's Name field value identifies the owner name of the DNSKEY
484 RR that a validator is supposed to use to validate this signature.
485 The Signer's Name field MUST contain the name of the zone of the
486 covered RRset. A sender MUST NOT use DNS name compression on the
487 Signer's Name field when transmitting a RRSIG RR.
4893.1.8. The Signature Field
491 The Signature field contains the cryptographic signature that covers
492 the RRSIG RDATA (excluding the Signature field) and the RRset
493 specified by the RRSIG owner name, RRSIG class, and RRSIG Type
494 Covered field. The format of this field depends on the algorithm in
495 use, and these formats are described in separate companion documents.
4973.1.8.1. Signature Calculation
499 A signature covers the RRSIG RDATA (excluding the Signature Field)
500 and covers the data RRset specified by the RRSIG owner name, RRSIG
501 class, and RRSIG Type Covered fields. The RRset is in canonical form
502 (see Section 6), and the set RR(1),...RR(n) is signed as follows:
506Arends, et al. Standards Track [Page 9]
508RFC 4034 DNSSEC Resource Records March 2005
511 signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
513 "|" denotes concatenation;
515 RRSIG_RDATA is the wire format of the RRSIG RDATA fields
516 with the Signer's Name field in canonical form and
517 the Signature field excluded;
519 RR(i) = owner | type | class | TTL | RDATA length | RDATA
521 "owner" is the fully qualified owner name of the RRset in
522 canonical form (for RRs with wildcard owner names, the
523 wildcard label is included in the owner name);
525 Each RR MUST have the same owner name as the RRSIG RR;
527 Each RR MUST have the same class as the RRSIG RR;
529 Each RR in the RRset MUST have the RR type listed in the
530 RRSIG RR's Type Covered field;
532 Each RR in the RRset MUST have the TTL listed in the
533 RRSIG Original TTL Field;
535 Any DNS names in the RDATA field of each RR MUST be in
538 The RRset MUST be sorted in canonical order.
540 See Sections 6.2 and 6.3 for details on canonical form and ordering
5433.2. The RRSIG RR Presentation Format
545 The presentation format of the RDATA portion is as follows:
547 The Type Covered field is represented as an RR type mnemonic. When
548 the mnemonic is not known, the TYPE representation as described in
549 [RFC3597], Section 5, MUST be used.
551 The Algorithm field value MUST be represented either as an unsigned
552 decimal integer or as an algorithm mnemonic, as specified in Appendix
555 The Labels field value MUST be represented as an unsigned decimal
562Arends, et al. Standards Track [Page 10]
564RFC 4034 DNSSEC Resource Records March 2005
567 The Original TTL field value MUST be represented as an unsigned
570 The Signature Expiration Time and Inception Time field values MUST be
571 represented either as an unsigned decimal integer indicating seconds
572 since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in
575 YYYY is the year (0001-9999, but see Section 3.1.5);
576 MM is the month number (01-12);
577 DD is the day of the month (01-31);
578 HH is the hour, in 24 hour notation (00-23);
579 mm is the minute (00-59); and
580 SS is the second (00-59).
582 Note that it is always possible to distinguish between these two
583 formats because the YYYYMMDDHHmmSS format will always be exactly 14
584 digits, while the decimal representation of a 32-bit unsigned integer
585 can never be longer than 10 digits.
587 The Key Tag field MUST be represented as an unsigned decimal integer.
589 The Signer's Name field value MUST be represented as a domain name.
591 The Signature field is represented as a Base64 encoding of the
592 signature. Whitespace is allowed within the Base64 text. See
597 The following RRSIG RR stores the signature for the A RRset of
600 host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
601 20030220173103 2642 example.com.
602 oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
603 PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
604 B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
605 GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
606 J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
608 The first four fields specify the owner name, TTL, Class, and RR type
609 (RRSIG). The "A" represents the Type Covered field. The value 5
610 identifies the algorithm used (RSA/SHA1) to create the signature.
611 The value 3 is the number of Labels in the original owner name. The
612 value 86400 in the RRSIG RDATA is the Original TTL for the covered A
613 RRset. 20030322173103 and 20030220173103 are the expiration and
618Arends, et al. Standards Track [Page 11]
620RFC 4034 DNSSEC Resource Records March 2005
623 inception dates, respectively. 2642 is the Key Tag, and example.com.
624 is the Signer's Name. The remaining text is a Base64 encoding of the
627 Note that combination of RRSIG RR owner name, class, and Type Covered
628 indicates that this RRSIG covers the "host.example.com" A RRset. The
629 Label value of 3 indicates that no wildcard expansion was used. The
630 Algorithm, Signer's Name, and Key Tag indicate that this signature
631 can be authenticated using an example.com zone DNSKEY RR whose
632 algorithm is 5 and whose key tag is 2642.
6344. The NSEC Resource Record
636 The NSEC resource record lists two separate things: the next owner
637 name (in the canonical ordering of the zone) that contains
638 authoritative data or a delegation point NS RRset, and the set of RR
639 types present at the NSEC RR's owner name [RFC3845]. The complete
640 set of NSEC RRs in a zone indicates which authoritative RRsets exist
641 in a zone and also form a chain of authoritative owner names in the
642 zone. This information is used to provide authenticated denial of
643 existence for DNS data, as described in [RFC4035].
645 Because every authoritative name in a zone must be part of the NSEC
646 chain, NSEC RRs must be present for names containing a CNAME RR.
647 This is a change to the traditional DNS specification [RFC1034],
648 which stated that if a CNAME is present for a name, it is the only
649 type allowed at that name. An RRSIG (see Section 3) and NSEC MUST
650 exist for the same name as does a CNAME resource record in a signed
653 See [RFC4035] for discussion of how a zone signer determines
654 precisely which NSEC RRs it has to include in a zone.
656 The type value for the NSEC RR is 47.
658 The NSEC RR is class independent.
660 The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
661 field. This is in the spirit of negative caching ([RFC2308]).
674Arends, et al. Standards Track [Page 12]
676RFC 4034 DNSSEC Resource Records March 2005
6794.1. NSEC RDATA Wire Format
681 The RDATA of the NSEC RR is as shown below:
683 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
684 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
685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6914.1.1. The Next Domain Name Field
693 The Next Domain field contains the next owner name (in the canonical
694 ordering of the zone) that has authoritative data or contains a
695 delegation point NS RRset; see Section 6.1 for an explanation of
696 canonical ordering. The value of the Next Domain Name field in the
697 last NSEC record in the zone is the name of the zone apex (the owner
698 name of the zone's SOA RR). This indicates that the owner name of
699 the NSEC RR is the last name in the canonical ordering of the zone.
701 A sender MUST NOT use DNS name compression on the Next Domain Name
702 field when transmitting an NSEC RR.
704 Owner names of RRsets for which the given zone is not authoritative
705 (such as glue records) MUST NOT be listed in the Next Domain Name
706 unless at least one authoritative RRset exists at the same owner
7094.1.2. The Type Bit Maps Field
711 The Type Bit Maps field identifies the RRset types that exist at the
712 NSEC RR's owner name.
714 The RR type space is split into 256 window blocks, each representing
715 the low-order 8 bits of the 16-bit RR type space. Each block that
716 has at least one active RR type is encoded using a single octet
717 window number (from 0 to 255), a single octet bitmap length (from 1
718 to 32) indicating the number of octets used for the window block's
719 bitmap, and up to 32 octets (256 bits) of bitmap.
721 Blocks are present in the NSEC RR RDATA in increasing numerical
724 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
726 where "|" denotes concatenation.
730Arends, et al. Standards Track [Page 13]
732RFC 4034 DNSSEC Resource Records March 2005
735 Each bitmap encodes the low-order 8 bits of RR types within the
736 window block, in network bit order. The first bit is bit 0. For
737 window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
738 to RR type 2 (NS), and so forth. For window block 1, bit 1
739 corresponds to RR type 257, and bit 2 to RR type 258. If a bit is
740 set, it indicates that an RRset of that type is present for the NSEC
741 RR's owner name. If a bit is clear, it indicates that no RRset of
742 that type is present for the NSEC RR's owner name.
744 Bits representing pseudo-types MUST be clear, as they do not appear
745 in zone data. If encountered, they MUST be ignored upon being read.
747 Blocks with no types present MUST NOT be included. Trailing zero
748 octets in the bitmap MUST be omitted. The length of each block's
749 bitmap is determined by the type code with the largest numerical
750 value, within that block, among the set of RR types present at the
751 NSEC RR's owner name. Trailing zero octets not specified MUST be
752 interpreted as zero octets.
754 The bitmap for the NSEC RR at a delegation point requires special
755 attention. Bits corresponding to the delegation NS RRset and the RR
756 types for which the parent zone has authoritative data MUST be set;
757 bits corresponding to any non-NS RRset for which the parent is not
758 authoritative MUST be clear.
760 A zone MUST NOT include an NSEC RR for any domain name that only
7634.1.3. Inclusion of Wildcard Names in NSEC RDATA
765 If a wildcard owner name appears in a zone, the wildcard label ("*")
766 is treated as a literal symbol and is treated the same as any other
767 owner name for the purposes of generating NSEC RRs. Wildcard owner
768 names appear in the Next Domain Name field without any wildcard
769 expansion. [RFC4035] describes the impact of wildcards on
770 authenticated denial of existence.
7724.2. The NSEC RR Presentation Format
774 The presentation format of the RDATA portion is as follows:
776 The Next Domain Name field is represented as a domain name.
778 The Type Bit Maps field is represented as a sequence of RR type
779 mnemonics. When the mnemonic is not known, the TYPE representation
780 described in [RFC3597], Section 5, MUST be used.
786Arends, et al. Standards Track [Page 14]
788RFC 4034 DNSSEC Resource Records March 2005
793 The following NSEC RR identifies the RRsets associated with
794 alfa.example.com. and identifies the next authoritative name after
797 alfa.example.com. 86400 IN NSEC host.example.com. (
798 A MX RRSIG NSEC TYPE1234 )
800 The first four text fields specify the name, TTL, Class, and RR type
801 (NSEC). The entry host.example.com. is the next authoritative name
802 after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC,
803 and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC,
804 and TYPE1234 RRsets associated with the name alfa.example.com.
806 The RDATA section of the NSEC RR above would be encoded as:
809 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
810 0x03 'c' 'o' 'm' 0x00
811 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
812 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
813 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
814 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
815 0x00 0x00 0x00 0x00 0x20
817 Assuming that the validator can authenticate this NSEC record, it
818 could be used to prove that beta.example.com does not exist, or to
819 prove that there is no AAAA record associated with alfa.example.com.
820 Authenticated denial of existence is discussed in [RFC4035].
8225. The DS Resource Record
824 The DS Resource Record refers to a DNSKEY RR and is used in the DNS
825 DNSKEY authentication process. A DS RR refers to a DNSKEY RR by
826 storing the key tag, algorithm number, and a digest of the DNSKEY RR.
827 Note that while the digest should be sufficient to identify the
828 public key, storing the key tag and key algorithm helps make the
829 identification process more efficient. By authenticating the DS
830 record, a resolver can authenticate the DNSKEY RR to which the DS
831 record points. The key authentication process is described in
834 The DS RR and its corresponding DNSKEY RR have the same owner name,
835 but they are stored in different locations. The DS RR appears only
836 on the upper (parental) side of a delegation, and is authoritative
837 data in the parent zone. For example, the DS RR for "example.com" is
838 stored in the "com" zone (the parent zone) rather than in the
842Arends, et al. Standards Track [Page 15]
844RFC 4034 DNSSEC Resource Records March 2005
847 "example.com" zone (the child zone). The corresponding DNSKEY RR is
848 stored in the "example.com" zone (the child zone). This simplifies
849 DNS zone management and zone signing but introduces special response
850 processing requirements for the DS RR; these are described in
853 The type number for the DS record is 43.
855 The DS resource record is class independent.
857 The DS RR has no special TTL requirements.
8595.1. DS RDATA Wire Format
861 The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet
862 Algorithm field, a 1 octet Digest Type field, and a Digest field.
864 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
865 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
866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
867 | Key Tag | Algorithm | Digest Type |
868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8745.1.1. The Key Tag Field
876 The Key Tag field lists the key tag of the DNSKEY RR referred to by
877 the DS record, in network byte order.
879 The Key Tag used by the DS RR is identical to the Key Tag used by
880 RRSIG RRs. Appendix B describes how to compute a Key Tag.
8825.1.2. The Algorithm Field
884 The Algorithm field lists the algorithm number of the DNSKEY RR
885 referred to by the DS record.
887 The algorithm number used by the DS RR is identical to the algorithm
888 number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the
889 algorithm number types.
898Arends, et al. Standards Track [Page 16]
900RFC 4034 DNSSEC Resource Records March 2005
9035.1.3. The Digest Type Field
905 The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
906 RR. The Digest Type field identifies the algorithm used to construct
907 the digest. Appendix A.2 lists the possible digest algorithm types.
9095.1.4. The Digest Field
911 The DS record refers to a DNSKEY RR by including a digest of that
914 The digest is calculated by concatenating the canonical form of the
915 fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
916 and then applying the digest algorithm.
918 digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
920 "|" denotes concatenation
922 DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
924 The size of the digest may vary depending on the digest algorithm and
925 DNSKEY RR size. As of the time of this writing, the only defined
926 digest algorithm is SHA-1, which produces a 20 octet digest.
9285.2. Processing of DS RRs When Validating Responses
930 The DS RR links the authentication chain across zone boundaries, so
931 the DS RR requires extra care in processing. The DNSKEY RR referred
932 to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST
933 have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC
934 zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be
935 used in the validation process.
9375.3. The DS RR Presentation Format
939 The presentation format of the RDATA portion is as follows:
941 The Key Tag field MUST be represented as an unsigned decimal integer.
943 The Algorithm field MUST be represented either as an unsigned decimal
944 integer or as an algorithm mnemonic specified in Appendix A.1.
946 The Digest Type field MUST be represented as an unsigned decimal
954Arends, et al. Standards Track [Page 17]
956RFC 4034 DNSSEC Resource Records March 2005
959 The Digest MUST be represented as a sequence of case-insensitive
960 hexadecimal digits. Whitespace is allowed within the hexadecimal
965 The following example shows a DNSKEY RR and its corresponding DS RR.
967 dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
968 fwJr1AYtsmx3TGkJaNXVbfi/
969 2pHm822aJ5iI9BMzNXxeYCmZ
970 DRD99WYwYqUSdjMmmAphXdvx
971 egXd/M5+X7OrzKBaMbCVdFLU
972 Uh6DhweJBjEVv5f2wwjM9Xzc
973 nOf+EPbtG9DMBmADjFDc2w/r
977 dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
980 The first four text fields specify the name, TTL, Class, and RR type
981 (DS). Value 60485 is the key tag for the corresponding
982 "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
983 used by this "dskey.example.com." DNSKEY RR. The value 1 is the
984 algorithm used to construct the digest, and the rest of the RDATA
985 text is the digest in hexadecimal.
9876. Canonical Form and Order of Resource Records
989 This section defines a canonical form for resource records, a
990 canonical ordering of DNS names, and a canonical ordering of resource
991 records within an RRset. A canonical name order is required to
992 construct the NSEC name chain. A canonical RR form and ordering
993 within an RRset are required in order to construct and verify RRSIG
9966.1. Canonical DNS Name Order
998 For the purposes of DNS security, owner names are ordered by treating
999 individual labels as unsigned left-justified octet strings. The
1000 absence of a octet sorts before a zero value octet, and uppercase
1001 US-ASCII letters are treated as if they were lowercase US-ASCII
1010Arends, et al. Standards Track [Page 18]
1012RFC 4034 DNSSEC Resource Records March 2005
1015 To compute the canonical ordering of a set of DNS names, start by
1016 sorting the names according to their most significant (rightmost)
1017 labels. For names in which the most significant label is identical,
1018 continue sorting according to their next most significant label, and
1021 For example, the following names are sorted in canonical DNS name
1022 order. The most significant label is "example". At this level,
1023 "example" sorts first, followed by names ending in "a.example", then
1024 by names ending "z.example". The names within each level are sorted
10376.2. Canonical RR Form
1039 For the purposes of DNS security, the canonical form of an RR is the
1040 wire format of the RR where:
1042 1. every domain name in the RR is fully expanded (no DNS name
1043 compression) and fully qualified;
1045 2. all uppercase US-ASCII letters in the owner name of the RR are
1046 replaced by the corresponding lowercase US-ASCII letters;
1048 3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
1049 HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
1050 SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
1051 the DNS names contained within the RDATA are replaced by the
1052 corresponding lowercase US-ASCII letters;
1054 4. if the owner name of the RR is a wildcard name, the owner name is
1055 in its original unexpanded form, including the "*" label (no
1056 wildcard substitution); and
1058 5. the RR's TTL is set to its original value as it appears in the
1059 originating authoritative zone or the Original TTL field of the
1066Arends, et al. Standards Track [Page 19]
1068RFC 4034 DNSSEC Resource Records March 2005
10716.3. Canonical RR Ordering within an RRset
1073 For the purposes of DNS security, RRs with the same owner name,
1074 class, and type are sorted by treating the RDATA portion of the
1075 canonical form of each RR as a left-justified unsigned octet sequence
1076 in which the absence of an octet sorts before a zero octet.
1078 [RFC2181] specifies that an RRset is not allowed to contain duplicate
1079 records (multiple RRs with the same owner name, class, type, and
1080 RDATA). Therefore, if an implementation detects duplicate RRs when
1081 putting the RRset in canonical form, it MUST treat this as a protocol
1082 error. If the implementation chooses to handle this protocol error
1083 in the spirit of the robustness principle (being liberal in what it
1084 accepts), it MUST remove all but one of the duplicate RR(s) for the
1085 purposes of calculating the canonical form of the RRset.
10877. IANA Considerations
1089 This document introduces no new IANA considerations, as all of the
1090 protocol parameters used in this document have already been assigned
1091 by previous specifications. However, since the evolution of DNSSEC
1092 has been long and somewhat convoluted, this section attempts to
1093 describe the current state of the IANA registries and other protocol
1094 parameters that are (or once were) related to DNSSEC.
1096 Please refer to [RFC4035] for additional IANA considerations.
1098 DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
1099 the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS
1100 Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47,
1101 and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
1102 [RFC3755] also marked type 30 (NXT) as Obsolete and restricted use
1103 of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction
1104 security protocol described in [RFC2931] and to the transaction
1105 KEY Resource Record described in [RFC2930].
1107 DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
1108 for DNSSEC Resource Record Algorithm field numbers and assigned
1109 values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755]
1110 altered this registry to include flags for each entry regarding
1111 its use with the DNS security extensions. Each algorithm entry
1112 could refer to an algorithm that can be used for zone signing,
1113 transaction security (see [RFC2931]), or both. Values 6-251 are
1114 available for assignment by IETF standards action ([RFC3755]).
1115 See Appendix A for a full listing of the DNS Security Algorithm
1116 Numbers entries at the time of this writing and their status for
1122Arends, et al. Standards Track [Page 20]
1124RFC 4034 DNSSEC Resource Records March 2005
1127 [RFC3658] created an IANA registry for DNSSEC DS Digest Types and
1128 assigned value 0 to reserved and value 1 to SHA-1.
1130 KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
1131 Protocol Values, but [RFC3445] reassigned all values other than 3
1132 to reserved and closed this IANA registry. The registry remains
1133 closed, and all KEY and DNSKEY records are required to have a
1134 Protocol Octet value of 3.
1136 Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
1137 registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially,
1138 this registry only contains assignments for bit 7 (the ZONE bit)
1139 and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]).
1140 As stated in [RFC3755], bits 0-6 and 8-14 are available for
1141 assignment by IETF Standards Action.
11438. Security Considerations
1145 This document describes the format of four DNS resource records used
1146 by the DNS security extensions and presents an algorithm for
1147 calculating a key tag for a public key. Other than the items
1148 described below, the resource records themselves introduce no
1149 security considerations. Please see [RFC4033] and [RFC4035] for
1150 additional security considerations related to the use of these
1153 The DS record points to a DNSKEY RR by using a cryptographic digest,
1154 the key algorithm type, and a key tag. The DS record is intended to
1155 identify an existing DNSKEY RR, but it is theoretically possible for
1156 an attacker to generate a DNSKEY that matches all the DS fields. The
1157 probability of constructing a matching DNSKEY depends on the type of
1158 digest algorithm in use. The only currently defined digest algorithm
1159 is SHA-1, and the working group believes that constructing a public
1160 key that would match the algorithm, key tag, and SHA-1 digest given
1161 in a DS record would be a sufficiently difficult problem that such an
1162 attack is not a serious threat at this time.
1164 The key tag is used to help select DNSKEY resource records
1165 efficiently, but it does not uniquely identify a single DNSKEY
1166 resource record. It is possible for two distinct DNSKEY RRs to have
1167 the same owner name, the same algorithm type, and the same key tag.
1168 An implementation that uses only the key tag to select a DNSKEY RR
1169 might select the wrong public key in some circumstances. Please see
1170 Appendix B for further details.
1178Arends, et al. Standards Track [Page 21]
1180RFC 4034 DNSSEC Resource Records March 2005
1183 The table of algorithms in Appendix A and the key tag calculation
1184 algorithms in Appendix B include the RSA/MD5 algorithm for
1185 completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as
1186 explained in [RFC3110].
1190 This document was created from the input and ideas of the members of
1191 the DNS Extensions Working Group and working group mailing list. The
1192 editors would like to express their thanks for the comments and
1193 suggestions received during the revision of these security extension
1194 specifications. Although explicitly listing everyone who has
1195 contributed during the decade in which DNSSEC has been under
1196 development would be impossible, [RFC4033] includes a list of some of
1197 the participants who were kind enough to comment on these documents.
120110.1. Normative References
1203 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
1204 STD 13, RFC 1034, November 1987.
1206 [RFC1035] Mockapetris, P., "Domain names - implementation and
1207 specification", STD 13, RFC 1035, November 1987.
1209 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
1212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1213 Requirement Levels", BCP 14, RFC 2119, March 1997.
1215 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1216 Specification", RFC 2181, July 1997.
1218 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
1219 NCACHE)", RFC 2308, March 1998.
1221 [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
1222 System (DNS)", RFC 2536, March 1999.
1224 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
1225 ( SIG(0)s )", RFC 2931, September 2000.
1227 [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
1228 Domain Name System (DNS)", RFC 3110, May 2001.
1234Arends, et al. Standards Track [Page 22]
1236RFC 4034 DNSSEC Resource Records March 2005
1239 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
1240 Resource Record (RR)", RFC 3445, December 2002.
1242 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
1243 Encodings", RFC 3548, July 2003.
1245 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
1246 (RR) Types", RFC 3597, September 2003.
1248 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
1249 (RR)", RFC 3658, December 2003.
1251 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
1252 Signer (DS)", RFC 3755, May 2004.
1254 [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
1255 System KEY (DNSKEY) Resource Record (RR) Secure Entry
1256 Point (SEP) Flag", RFC 3757, April 2004.
1258 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1259 Rose, "DNS Security Introduction and Requirements", RFC
1262 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1263 Rose, "Protocol Modifications for the DNS Security
1264 Extensions", RFC 4035, March 2005.
126610.2. Informative References
1268 [RFC2535] Eastlake 3rd, D., "Domain Name System Security
1269 Extensions", RFC 2535, March 1999.
1271 [RFC2537] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain
1272 Name System (DNS)", RFC 2537, March 1999.
1274 [RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
1275 Domain Name System (DNS)", RFC 2539, March 1999.
1277 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
1278 RR)", RFC 2930, September 2000.
1280 [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
1281 RDATA Format", RFC 3845, August 2004.
1290Arends, et al. Standards Track [Page 23]
1292RFC 4034 DNSSEC Resource Records March 2005
1295Appendix A. DNSSEC Algorithm and Digest Types
1297 The DNS security extensions are designed to be independent of the
1298 underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS
1299 resource records all use a DNSSEC Algorithm Number to identify the
1300 cryptographic algorithm in use by the resource record. The DS
1301 resource record also specifies a Digest Algorithm Number to identify
1302 the digest algorithm used to construct the DS record. The currently
1303 defined Algorithm and Digest Types are listed below. Additional
1304 Algorithm or Digest Types could be added as advances in cryptography
1307 A DNSSEC aware resolver or name server MUST implement all MANDATORY
1310A.1. DNSSEC Algorithm Types
1312 The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the
1313 security algorithm being used. These values are stored in the
1314 "Algorithm number" field in the resource record RDATA.
1316 Some algorithms are usable only for zone signing (DNSSEC), some only
1317 for transaction security mechanisms (SIG(0) and TSIG), and some for
1318 both. Those usable for zone signing may appear in DNSKEY, RRSIG, and
1319 DS RRs. Those usable for transaction security would be present in
1320 SIG(0) and KEY RRs, as described in [RFC2931].
1323 Value Algorithm [Mnemonic] Signing References Status
1324 ----- -------------------- --------- ---------- ---------
1326 1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED
1327 2 Diffie-Hellman [DH] n [RFC2539] -
1328 3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL
1329 4 Elliptic Curve [ECC] TBA -
1330 5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY
1331 252 Indirect [INDIRECT] n -
1332 253 Private [PRIVATEDNS] y see below OPTIONAL
1333 254 Private [PRIVATEOID] y see below OPTIONAL
1336 6 - 251 Available for assignment by IETF Standards Action.
1346Arends, et al. Standards Track [Page 24]
1348RFC 4034 DNSSEC Resource Records March 2005
1351A.1.1. Private Algorithm Types
1353 Algorithm number 253 is reserved for private use and will never be
1354 assigned to a specific algorithm. The public key area in the DNSKEY
1355 RR and the signature area in the RRSIG RR begin with a wire encoded
1356 domain name, which MUST NOT be compressed. The domain name indicates
1357 the private algorithm to use, and the remainder of the public key
1358 area is determined by that algorithm. Entities should only use
1359 domain names they control to designate their private algorithms.
1361 Algorithm number 254 is reserved for private use and will never be
1362 assigned to a specific algorithm. The public key area in the DNSKEY
1363 RR and the signature area in the RRSIG RR begin with an unsigned
1364 length byte followed by a BER encoded Object Identifier (ISO OID) of
1365 that length. The OID indicates the private algorithm in use, and the
1366 remainder of the area is whatever is required by that algorithm.
1367 Entities should only use OIDs they control to designate their private
1370A.2. DNSSEC Digest Types
1372 A "Digest Type" field in the DS resource record types identifies the
1373 cryptographic digest algorithm used by the resource record. The
1374 following table lists the currently defined digest algorithm types.
1376 VALUE Algorithm STATUS
1381Appendix B. Key Tag Calculation
1383 The Key Tag field in the RRSIG and DS resource record types provides
1384 a mechanism for selecting a public key efficiently. In most cases, a
1385 combination of owner name, algorithm, and key tag can efficiently
1386 identify a DNSKEY record. Both the RRSIG and DS resource records
1387 have corresponding DNSKEY records. The Key Tag field in the RRSIG
1388 and DS records can be used to help select the corresponding DNSKEY RR
1389 efficiently when more than one candidate DNSKEY RR is available.
1391 However, it is essential to note that the key tag is not a unique
1392 identifier. It is theoretically possible for two distinct DNSKEY RRs
1393 to have the same owner name, the same algorithm, and the same key
1394 tag. The key tag is used to limit the possible candidate keys, but
1395 it does not uniquely identify a DNSKEY record. Implementations MUST
1396 NOT assume that the key tag uniquely identifies a DNSKEY RR.
1402Arends, et al. Standards Track [Page 25]
1404RFC 4034 DNSSEC Resource Records March 2005
1407 The key tag is the same for all DNSKEY algorithm types except
1408 algorithm 1 (please see Appendix B.1 for the definition of the key
1409 tag for algorithm 1). The key tag algorithm is the sum of the wire
1410 format of the DNSKEY RDATA broken into 2 octet groups. First, the
1411 RDATA (in wire format) is treated as a series of 2 octet groups.
1412 These groups are then added together, ignoring any carry bits.
1414 A reference implementation of the key tag algorithm is as an ANSI C
1415 function is given below, with the RDATA portion of the DNSKEY RR is
1416 used as input. It is not necessary to use the following reference
1417 code verbatim, but the numerical value of the Key Tag MUST be
1418 identical to what the reference implementation would generate for the
1421 Please note that the algorithm for calculating the Key Tag is almost
1422 but not completely identical to the familiar ones-complement checksum
1423 used in many other Internet protocols. Key Tags MUST be calculated
1424 using the algorithm described here rather than the ones complement
1427 The following ANSI C reference implementation calculates the value of
1428 a Key Tag. This reference implementation applies to all algorithm
1429 types except algorithm 1 (see Appendix B.1). The input is the wire
1430 format of the RDATA portion of the DNSKEY RR. The code is written
1431 for clarity, not efficiency.
1434 * Assumes that int is at least 16 bits.
1435 * First octet of the key tag is the most significant 8 bits of the
1437 * Second octet of the key tag is the least significant 8 bits of the
1443 unsigned char key[], /* the RDATA part of the DNSKEY RR */
1444 unsigned int keysize /* the RDLENGTH */
1447 unsigned long ac; /* assumed to be 32 bits or larger */
1448 int i; /* loop index */
1450 for ( ac = 0, i = 0; i < keysize; ++i )
1451 ac += (i & 1) ? key[i] : key[i] << 8;
1452 ac += (ac >> 16) & 0xFFFF;
1458Arends, et al. Standards Track [Page 26]
1460RFC 4034 DNSSEC Resource Records March 2005
1463B.1. Key Tag for Algorithm 1 (RSA/MD5)
1465 The key tag for algorithm 1 (RSA/MD5) is defined differently from the
1466 key tag for all other algorithms, for historical reasons. For a
1467 DNSKEY RR with algorithm 1, the key tag is defined to be the most
1468 significant 16 bits of the least significant 24 bits in the public
1469 key modulus (in other words, the 4th to last and 3rd to last octets
1470 of the public key modulus).
1472 Please note that Algorithm 1 is NOT RECOMMENDED.
1514Arends, et al. Standards Track [Page 27]
1516RFC 4034 DNSSEC Resource Records March 2005
1522 Telematica Instituut
1527 EMail: roy.arends@telin.nl
1531 Internet Systems Consortium
1533 Redwood City, CA 94063
1541 21345 Ridgetop Circle
1542 Dulles, VA 20166-6503
1545 EMail: mlarson@verisign.com
1549 Colorado State University
1550 Department of Computer Science
1551 Fort Collins, CO 80523-1873
1553 EMail: massey@cs.colostate.edu
1557 National Institute for Standards and Technology
1559 Gaithersburg, MD 20899-8920
1562 EMail: scott.rose@nist.gov
1570Arends, et al. Standards Track [Page 28]
1572RFC 4034 DNSSEC Resource Records March 2005
1575Full Copyright Statement
1577 Copyright (C) The Internet Society (2005).
1579 This document is subject to the rights, licenses and restrictions
1580 contained in BCP 78, and except as set forth therein, the authors
1581 retain all their rights.
1583 This document and the information contained herein are provided on an
1584 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1585 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1586 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1587 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1588 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1589 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1591Intellectual Property
1593 The IETF takes no position regarding the validity or scope of any
1594 Intellectual Property Rights or other rights that might be claimed to
1595 pertain to the implementation or use of the technology described in
1596 this document or the extent to which any license under such rights
1597 might or might not be available; nor does it represent that it has
1598 made any independent effort to identify any such rights. Information
1599 on the procedures with respect to rights in RFC documents can be
1600 found in BCP 78 and BCP 79.
1602 Copies of IPR disclosures made to the IETF Secretariat and any
1603 assurances of licenses to be made available, or the result of an
1604 attempt made to obtain a general license or permission for the use of
1605 such proprietary rights by implementers or users of this
1606 specification can be obtained from the IETF on-line IPR repository at
1607 http://www.ietf.org/ipr.
1609 The IETF invites any interested party to bring to its attention any
1610 copyrights, patents or patent applications, or other proprietary
1611 rights that may cover technology that may be required to implement
1612 this standard. Please address the information to the IETF at ietf-
1617 Funding for the RFC Editor function is currently provided by the
1626Arends, et al. Standards Track [Page 29]