1 Network Working Group R. Arends
2 Request for Comments: 4034 Telematica Instituut
3 Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
4 3755, 3757, 3845 ISC
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions).
RFC6840 has many significant updates to earlier DNSSEC-related RFCs. Updates and clarifications for RFC 4034 are given later in this document.
RFC6014 says that it updates RFC 4034, and talks about RFC 4034 in a few places, but doesn't seem to update any of the material in RFC 4034.
5 Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
6 3007, 3597, 3226 VeriSign
7 Category: Standards Track D. Massey
8 Colorado State University
9 S. Rose
10 NIST
11 March 2005
12
13
14 Resource Records for the DNS Security Extensions
15
16 Status of This Memo
17
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
23
24 Copyright Notice
25
26 Copyright (C) The Internet Society (2005).
27
28 Abstract
29
30 This document is part of a family of documents that describe the DNS
31 Security Extensions (DNSSEC). The DNS Security Extensions are a
32 collection of resource records and protocol modifications that
33 provide source authentication for the DNS. This document defines the
34 public key (DNSKEY), delegation signer (DS), resource record digital
35 signature (RRSIG), and authenticated denial of existence (NSEC)
36 resource records. The purpose and format of each resource record is
37 described in detail, and an example of each resource record is given.
38
39 This document obsoletes RFC 2535 and incorporates changes from all
40 updates to RFC 2535.
41
42
43
44
45
46
47
48
49
50
51
52 Arends, et al. Standards Track [Page 1]
53 RFC 4034 DNSSEC Resource Records March 2005
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
59 1.1. Background and Related Documents . . . . . . . . . . . 3
60 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . 3
61 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 4
62 2.1. DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . 4
63 2.1.1. The Flags Field. . . . . . . . . . . . . . . . 4
64 2.1.2. The Protocol Field . . . . . . . . . . . . . . 5
65 2.1.3. The Algorithm Field. . . . . . . . . . . . . . 5
66 2.1.4. The Public Key Field . . . . . . . . . . . . . 5
67 2.1.5. Notes on DNSKEY RDATA Design . . . . . . . . . 5
68 2.2. The DNSKEY RR Presentation Format. . . . . . . . . . . 5
69 2.3. DNSKEY RR Example . . . . . . . . . . . . . . . . . . 6
70 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 6
71 3.1. RRSIG RDATA Wire Format. . . . . . . . . . . . . . . . 7
72 3.1.1. The Type Covered Field . . . . . . . . . . . . 7
73 3.1.2. The Algorithm Number Field . . . . . . . . . . 8
74 3.1.3. The Labels Field . . . . . . . . . . . . . . . 8
75 3.1.4. Original TTL Field . . . . . . . . . . . . . . 8
76 3.1.5. Signature Expiration and Inception Fields. . . 9
77 3.1.6. The Key Tag Field. . . . . . . . . . . . . . . 9
78 3.1.7. The Signer's Name Field. . . . . . . . . . . . 9
79 3.1.8. The Signature Field. . . . . . . . . . . . . . 9
80 3.2. The RRSIG RR Presentation Format . . . . . . . . . . . 10
81 3.3. RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11
82 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12
83 4.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13
84 4.1.1. The Next Domain Name Field . . . . . . . . . . 13
85 4.1.2. The Type Bit Maps Field. . . . . . . . . . . . 13
86 4.1.3. Inclusion of Wildcard Names in NSEC RDATA. . . 14
87 4.2. The NSEC RR Presentation Format. . . . . . . . . . . . 14
88 4.3. NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15
89 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 15
90 5.1. DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16
91 5.1.1. The Key Tag Field. . . . . . . . . . . . . . . 16
92 5.1.2. The Algorithm Field. . . . . . . . . . . . . . 16
93 5.1.3. The Digest Type Field. . . . . . . . . . . . . 17
94 5.1.4. The Digest Field . . . . . . . . . . . . . . . 17
95 5.2. Processing of DS RRs When Validating Responses . . . . 17
96 5.3. The DS RR Presentation Format. . . . . . . . . . . . . 17
97 5.4. DS RR Example. . . . . . . . . . . . . . . . . . . . . 18
98 6. Canonical Form and Order of Resource Records . . . . . . . . 18
99 6.1. Canonical DNS Name Order . . . . . . . . . . . . . . . 18
100 6.2. Canonical RR Form. . . . . . . . . . . . . . . . . . . 19
101 6.3. Canonical RR Ordering within an RRset. . . . . . . . . 20
102 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20
103 8. Security Considerations. . . . . . . . . . . . . . . . . . . 21
104
105
106
107 Arends, et al. Standards Track [Page 2]
108 RFC 4034 DNSSEC Resource Records March 2005
109
110
111 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
112 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
113 10.1. Normative References . . . . . . . . . . . . . . . . . 22
114 10.2. Informative References . . . . . . . . . . . . . . . . 23
115 A. DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24
116 A.1. DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24
117 A.1.1. Private Algorithm Types. . . . . . . . . . . . 25
118 A.2. DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25
119 B. Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25
120 B.1. Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27
121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
122 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29
123
124 1. Introduction
125
126 The DNS Security Extensions (DNSSEC) introduce four new DNS resource
127 record types: DNS Public Key (DNSKEY), Resource Record Signature
128 (RRSIG), Next Secure (NSEC), and Delegation Signer (DS). This
129 document defines the purpose of each resource record (RR), the RR's
130 RDATA format, and its presentation format (ASCII representation).
131
132 1.1. Background and Related Documents
133
134 This document is part of a family of documents defining DNSSEC, which
135 should be read together as a set.
136
137 [RFC4033] contains an introduction to DNSSEC and definition of common
138 terms; the reader is assumed to be familiar with this document.
139 [RFC4033] also contains a list of other documents updated by and
140 obsoleted by this document set.
141
142 [RFC4035] defines the DNSSEC protocol operations.
143
144 The reader is also assumed to be familiar with the basic DNS concepts
145 described in [RFC1034], [RFC1035], and the subsequent documents that
146 update them, particularly [RFC2181] and [RFC2308].
147
148 This document defines the DNSSEC resource records. All numeric DNS
149 type codes given in this document are decimal integers.
150
151 1.2. Reserved Words
152
153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
155 document are to be interpreted as described in [RFC2119].
156
157
158
159
160
161
162 Arends, et al. Standards Track [Page 3]
163 RFC 4034 DNSSEC Resource Records March 2005
164
165
166 2. The DNSKEY Resource Record
167
168 DNSSEC uses public key cryptography to sign and authenticate DNS
169 resource record sets (RRsets). The public keys are stored in DNSKEY
170 resource records and are used in the DNSSEC authentication process
171 described in [RFC4035]: A zone signs its authoritative RRsets by
172 using a private key and stores the corresponding public key in a
173 DNSKEY RR. A resolver can then use the public key to validate
174 signatures covering the RRsets in the zone, and thus to authenticate
175 them.
176
177 The DNSKEY RR is not intended as a record for storing arbitrary
178 public keys and MUST NOT be used to store certificates or public keys
179 that do not directly relate to the DNS infrastructure.
180
181 The Type value for the DNSKEY RR type is 48.
182
183 The DNSKEY RR is class independent.
184
185 The DNSKEY RR has no special TTL requirements.
186
187 2.1. DNSKEY RDATA Wire Format
188
189 The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
190 octet Protocol Field, a 1 octet Algorithm Field, and the Public Key
191 Field.
192
193 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
194 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
195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
196 | Flags | Protocol | Algorithm |
197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
198 / /
199 / Public Key /
200 / /
201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
202
203 2.1.1. The Flags Field
204
205 Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1,
206 then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's
207 owner name MUST be the name of a zone. If bit 7 has value 0, then
208 the DNSKEY record holds some other type of DNS public key and MUST
209 NOT be used to verify RRSIGs that cover RRsets.
210
211 Bit 15 of the Flags field is the Secure Entry Point flag, described
212 in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a
213 key intended for use as a secure entry point. This flag is only
214
215
216
217 Arends, et al. Standards Track [Page 4]
218 RFC 4034 DNSSEC Resource Records March 2005
219
220
221 intended to be a hint to zone signing or debugging software as to the
222 intended use of this DNSKEY record; validators MUST NOT alter their
223 behavior during the signature validation process in any way based on
224 the setting of this bit. This also means that a DNSKEY RR with the
225 SEP bit set would also need the Zone Key flag set in order to be able
226 to generate signatures legally. A DNSKEY RR with the SEP set and the
227 Zone Key flag not set MUST NOT be used to verify RRSIGs that cover
228 RRsets.
229
230 Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
231 creation of the DNSKEY RR and MUST be ignored upon receipt.
232
233 2.1.2. The Protocol Field
234
235 The Protocol Field MUST have value 3, and the DNSKEY RR MUST be
236 treated as invalid during signature verification if it is found to be
237 some value other than 3.
238
239 2.1.3. The Algorithm Field
240
241 The Algorithm field identifies the public key's cryptographic
242 algorithm and determines the format of the Public Key field. A list
243 of DNSSEC algorithm types can be found in Appendix A.1
244
245 2.1.4. The Public Key Field
246
247 The Public Key Field holds the public key material. The format
248 depends on the algorithm of the key being stored and is described in
249 separate documents.
250
251 2.1.5. Notes on DNSKEY RDATA Design
252
253 Although the Protocol Field always has value 3, it is retained for
254 backward compatibility with early versions of the KEY record.
255
256 2.2. The DNSKEY RR Presentation Format
257
258 The presentation format of the RDATA portion is as follows:
259
260 The Flag field MUST be represented as an unsigned decimal integer.
261 Given the currently defined flags, the possible values are: 0, 256,
262 and 257.
263
264 The Protocol Field MUST be represented as an unsigned decimal integer
265 with a value of 3.
266
267 The Algorithm field MUST be represented either as an unsigned decimal
268 integer or as an algorithm mnemonic as specified in Appendix A.1.
269
270
271
272 Arends, et al. Standards Track [Page 5]
273 RFC 4034 DNSSEC Resource Records March 2005
274
275
276 The Public Key field MUST be represented as a Base64 encoding of the
277 Public Key. Whitespace is allowed within the Base64 text. For a
278 definition of Base64 encoding, see [RFC3548].
279
280 2.3. DNSKEY RR Example
281
282 The following DNSKEY RR stores a DNS zone key for example.com.
283
284 example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
285 Cbl+BBZH4b/0PY1kxkmvHjcZc8no
286 kfzj31GajIQKY+5CptLr3buXA10h
287 WqTkF7H6RfoRqXQeogmMHfpftf6z
288 Mv1LyBUgia7za6ZEzOJBOztyvhjL
289 742iU/TpPSEDhm2SNKLijfUppn1U
290 aNvv4w== )
291
292 The first four text fields specify the owner name, TTL, Class, and RR
293 type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in
294 the Flags field has value 1. Value 3 is the fixed Protocol value.
295 Value 5 indicates the public key algorithm. Appendix A.1 identifies
296 algorithm type 5 as RSA/SHA1 and indicates that the format of the
297 RSA/SHA1 public key field is defined in [RFC3110]. The remaining
298 text is a Base64 encoding of the public key.
299
300 3. The RRSIG Resource Record
301
302 DNSSEC uses public key cryptography to sign and authenticate DNS
303 resource record sets (RRsets). Digital signatures are stored in
304 RRSIG resource records and are used in the DNSSEC authentication
305 process described in [RFC4035]. A validator can use these RRSIG RRs
306 to authenticate RRsets from the zone. The RRSIG RR MUST only be used
307 to carry verification material (digital signatures) used to secure
308 DNS operations.
309
310 An RRSIG record contains the signature for an RRset with a particular
311 name, class, and type. The RRSIG RR specifies a validity interval
312 for the signature and uses the Algorithm, the Signer's Name, and the
313 Key Tag to identify the DNSKEY RR containing the public key that a
314 validator can use to verify the signature.
315
316 Because every authoritative RRset in a zone must be protected by a
317 digital signature, RRSIG RRs must be present for names containing a
318 CNAME RR. This is a change to the traditional DNS specification
319 [RFC1034], which stated that if a CNAME is present for a name, it is
320 the only type allowed at that name. A RRSIG and NSEC (see Section 4)
321 MUST exist for the same name as a CNAME resource record in a signed
322 zone.
323
324
325
326
327 Arends, et al. Standards Track [Page 6]
328 RFC 4034 DNSSEC Resource Records March 2005
329
330
331 The Type value for the RRSIG RR type is 46.
332
333 The RRSIG RR is class independent.
334
335 An RRSIG RR MUST have the same class as the RRset it covers.
336
337 The TTL value of an RRSIG RR MUST match the TTL value of the RRset it
338 covers. This is an exception to the [RFC2181] rules for TTL values
339 of individual RRs within a RRset: individual RRSIG RRs with the same
340 owner name will have different TTL values if the RRsets they cover
341 have different TTL values.
342
343 3.1. RRSIG RDATA Wire Format
344
345 The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
346 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
347 TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
348 Inception field, a 2 octet Key tag, the Signer's Name field, and the
349 Signature field.
350
351 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
352 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
353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
354 | Type Covered | Algorithm | Labels |
355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
356 | Original TTL |
357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
358 | Signature Expiration |
359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
360 | Signature Inception |
361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
362 | Key Tag | /
363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
364 / /
365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
366 / /
367 / Signature /
368 / /
369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
370
371 3.1.1. The Type Covered Field
372
373 The Type Covered field identifies the type of the RRset that is
374 covered by this RRSIG record.
375
376
377
378
379
380
381
382 Arends, et al. Standards Track [Page 7]
383 RFC 4034 DNSSEC Resource Records March 2005
384
385
386 3.1.2. The Algorithm Number Field
387
388 The Algorithm Number field identifies the cryptographic algorithm
389 used to create the signature. A list of DNSSEC algorithm types can
390 be found in Appendix A.1
391
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
392 3.1.3. The Labels Field
393
394 The Labels field specifies the number of labels in the original RRSIG
395 RR owner name. The significance of this field is that a validator
396 uses it to determine whether the answer was synthesized from a
397 wildcard. If so, it can be used to determine what owner name was
398 used in generating the signature.
399
400 To validate a signature, the validator needs the original owner name
401 that was used to create the signature. If the original owner name
402 contains a wildcard label ("*"), the owner name may have been
403 expanded by the server during the response process, in which case the
404 validator will have to reconstruct the original owner name in order
405 to validate the signature. [RFC4035] describes how to use the Labels
406 field to reconstruct the original owner name.
407
408 The value of the Labels field MUST NOT count either the null (root)
409 label that terminates the owner name or the wildcard label (if
410 present). The value of the Labels field MUST be less than or equal
411 to the number of labels in the RRSIG owner name. For example,
412 "www.example.com." has a Labels field value of 3, and
413 "*.example.com." has a Labels field value of 2. Root (".") has a
414 Labels field value of 0.
415
416 Although the wildcard label is not included in the count stored in
417 the Labels field of the RRSIG RR, the wildcard label is part of the
418 RRset's owner name when the signature is generated or verified.
419
420 3.1.4. Original TTL Field
421
422 The Original TTL field specifies the TTL of the covered RRset as it
423 appears in the authoritative zone.
424
425 The Original TTL field is necessary because a caching resolver
426 decrements the TTL value of a cached RRset. In order to validate a
427 signature, a validator requires the original TTL. [RFC4035]
428 describes how to use the Original TTL field value to reconstruct the
429 original TTL.
430
431
432
433
434
435
436
437 Arends, et al. Standards Track [Page 8]
438 RFC 4034 DNSSEC Resource Records March 2005
439
440
441 3.1.5. Signature Expiration and Inception Fields
442
443 The Signature Expiration and Inception fields specify a validity
444 period for the signature. The RRSIG record MUST NOT be used for
445 authentication prior to the inception date and MUST NOT be used for
446 authentication after the expiration date.
447
448 The Signature Expiration and Inception field values specify a date
449 and time in the form of a 32-bit unsigned number of seconds elapsed
450 since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
451 byte order. The longest interval that can be expressed by this
452 format without wrapping is approximately 136 years. An RRSIG RR can
453 have an Expiration field value that is numerically smaller than the
454 Inception field value if the expiration field value is near the
455 32-bit wrap-around point or if the signature is long lived. Because
456 of this, all comparisons involving these fields MUST use "Serial
457 number arithmetic", as defined in [RFC1982]. As a direct
458 consequence, the values contained in these fields cannot refer to
459 dates more than 68 years in either the past or the future.
460
461 3.1.6. The Key Tag Field
462
463 The Key Tag field contains the key tag value of the DNSKEY RR that
464 validates this signature, in network byte order. Appendix B explains
465 how to calculate Key Tag values.
466
467 3.1.7. The Signer's Name Field
468
469 The Signer's Name field value identifies the owner name of the DNSKEY
470 RR that a validator is supposed to use to validate this signature.
471 The Signer's Name field MUST contain the name of the zone of the
472 covered RRset. A sender MUST NOT use DNS name compression on the
473 Signer's Name field when transmitting a RRSIG RR.
474
475 3.1.8. The Signature Field
476
477 The Signature field contains the cryptographic signature that covers
478 the RRSIG RDATA (excluding the Signature field) and the RRset
479 specified by the RRSIG owner name, RRSIG class, and RRSIG Type
480 Covered field. The format of this field depends on the algorithm in
481 use, and these formats are described in separate companion documents.
482
483 3.1.8.1. Signature Calculation
484
485 A signature covers the RRSIG RDATA (excluding the Signature Field)
486 and covers the data RRset specified by the RRSIG owner name, RRSIG
487 class, and RRSIG Type Covered fields. The RRset is in canonical form
488 (see Section 6), and the set RR(1),...RR(n) is signed as follows:
489
490
491
492 Arends, et al. Standards Track [Page 9]
493 RFC 4034 DNSSEC Resource Records March 2005
494
495
496 signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
497
498 "|" denotes concatenation;
499
500 RRSIG_RDATA is the wire format of the RRSIG RDATA fields
501 with the Signer's Name field in canonical form and
502 the Signature field excluded;
503
504 RR(i) = owner | type | class | TTL | RDATA length | RDATA
505
506 "owner" is the fully qualified owner name of the RRset in
507 canonical form (for RRs with wildcard owner names, the
508 wildcard label is included in the owner name);
509
510 Each RR MUST have the same owner name as the RRSIG RR;
511
512 Each RR MUST have the same class as the RRSIG RR;
513
514 Each RR in the RRset MUST have the RR type listed in the
515 RRSIG RR's Type Covered field;
516
517 Each RR in the RRset MUST have the TTL listed in the
518 RRSIG Original TTL Field;
519
520 Any DNS names in the RDATA field of each RR MUST be in
521 canonical form; and
522
523 The RRset MUST be sorted in canonical order.
524
525 See Sections 6.2 and 6.3 for details on canonical form and ordering
526 of RRsets.
527
528 3.2. The RRSIG RR Presentation Format
529
530 The presentation format of the RDATA portion is as follows:
531
532 The Type Covered field is represented as an RR type mnemonic. When
533 the mnemonic is not known, the TYPE representation as described in
534 [RFC3597], Section 5, MUST be used.
535
536 The Algorithm field value MUST be represented either as an unsigned
537 decimal integer or as an algorithm mnemonic, as specified in Appendix
538 A.1.
539
540 The Labels field value MUST be represented as an unsigned decimal
541 integer.
542
543
544
545
546
547 Arends, et al. Standards Track [Page 10]
548 RFC 4034 DNSSEC Resource Records March 2005
549
550
551 The Original TTL field value MUST be represented as an unsigned
552 decimal integer.
553
554 The Signature Expiration Time and Inception Time field values MUST be
555 represented either as an unsigned decimal integer indicating seconds
556 since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in
557 UTC, where:
558
559 YYYY is the year (0001-9999, but see Section 3.1.5);
560 MM is the month number (01-12);
561 DD is the day of the month (01-31);
562 HH is the hour, in 24 hour notation (00-23);
563 mm is the minute (00-59); and
564 SS is the second (00-59).
565
566 Note that it is always possible to distinguish between these two
567 formats because the YYYYMMDDHHmmSS format will always be exactly 14
568 digits, while the decimal representation of a 32-bit unsigned integer
569 can never be longer than 10 digits.
570
571 The Key Tag field MUST be represented as an unsigned decimal integer.
572
573 The Signer's Name field value MUST be represented as a domain name.
574
575 The Signature field is represented as a Base64 encoding of the
576 signature. Whitespace is allowed within the Base64 text. See
577 Section 2.2.
578
579 3.3. RRSIG RR Example
580
581 The following RRSIG RR stores the signature for the A RRset of
582 host.example.com:
583
584 host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
585 20030220173103 2642 example.com.
586 oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
587 PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
588 B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
589 GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
590 J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
591
592 The first four fields specify the owner name, TTL, Class, and RR type
593 (RRSIG). The "A" represents the Type Covered field. The value 5
594 identifies the algorithm used (RSA/SHA1) to create the signature.
595 The value 3 is the number of Labels in the original owner name. The
596 value 86400 in the RRSIG RDATA is the Original TTL for the covered A
597 RRset. 20030322173103 and 20030220173103 are the expiration and
598
599
600
601
602 Arends, et al. Standards Track [Page 11]
603 RFC 4034 DNSSEC Resource Records March 2005
604
605
606 inception dates, respectively. 2642 is the Key Tag, and example.com.
607 is the Signer's Name. The remaining text is a Base64 encoding of the
608 signature.
609
610 Note that combination of RRSIG RR owner name, class, and Type Covered
611 indicates that this RRSIG covers the "host.example.com" A RRset. The
612 Label value of 3 indicates that no wildcard expansion was used. The
613 Algorithm, Signer's Name, and Key Tag indicate that this signature
614 can be authenticated using an example.com zone DNSKEY RR whose
615 algorithm is 5 and whose key tag is 2642.
616
617 4. The NSEC Resource Record
618
619 The NSEC resource record lists two separate things: the next owner
620 name (in the canonical ordering of the zone) that contains
621 authoritative data or a delegation point NS RRset, and the set of RR
622 types present at the NSEC RR's owner name [RFC3845]. The complete
623 set of NSEC RRs in a zone indicates which authoritative RRsets exist
624 in a zone and also form a chain of authoritative owner names in the
625 zone. This information is used to provide authenticated denial of
626 existence for DNS data, as described in [RFC4035].
627
628 Because every authoritative name in a zone must be part of the NSEC
629 chain, NSEC RRs must be present for names containing a CNAME RR.
630 This is a change to the traditional DNS specification [RFC1034],
631 which stated that if a CNAME is present for a name, it is the only
632 type allowed at that name. An RRSIG (see Section 3) and NSEC MUST
633 exist for the same name as does a CNAME resource record in a signed
634 zone.
635
636 See [RFC4035] for discussion of how a zone signer determines
637 precisely which NSEC RRs it has to include in a zone.
638
639 The type value for the NSEC RR is 47.
640
641 The NSEC RR is class independent.
642
The value of the Labels field MUST NOT count either the null (root) label that terminates the owner name or the wildcard label (if present).
The value of the Labels field MUST NOT count either the null (root) label that terminates the owner name or the leftmost label if it is a wildcard.
In RFC 4035, section 2.2, describing the same count uses this: ... "and not counting the leftmost label if it is a wildcard" to omit the leading wildcard label. (In 4034, the wildcard label is defined as "*" earlier in the same problematic section.) The text in 4034 could be confused with having to count "wildcard labels" in the middle of a name, such as in name.*.tld. The reason for suggesting this errata is for compliance considerations. --VERIFIER NOTES-- All wildcard labels start with * in the leftmost label. No other kind of wildcard label exists. From RFC 1034: 4.3.3. Wildcards In the previous algorithm, special treatment was given to RRs with owner names starting with the label "*".
643 The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
644 field. This is in the spirit of negative caching ([RFC2308]).
645
646
647
648
649
650
651
652
653
654
655
656
657 Arends, et al. Standards Track [Page 12]
658 RFC 4034 DNSSEC Resource Records March 2005
659
660
661 4.1. NSEC RDATA Wire Format
662
663 The RDATA of the NSEC RR is as shown below:
664
665 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
666 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
667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
668 / Next Domain Name /
669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
670 / Type Bit Maps /
671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
672
RFC9077 updates many RFCs to clarify how TTLs are calculated
when using DNSSEC. For RFC 4034, it replaces:
The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching ([RFC2308]).
with:
The TTL of the NSEC RR that is returned MUST be the lesser of the MINIMUM field of the SOA record and the TTL of the SOA itself. This matches the definition of the TTL for negative responses in [RFC2308]. Because some signers incrementally update the NSEC chain, a transient inconsistency between the observed and expected TTL MAY exist.
673 4.1.1. The Next Domain Name Field
674
675 The Next Domain field contains the next owner name (in the canonical
676 ordering of the zone) that has authoritative data or contains a
677 delegation point NS RRset; see Section 6.1 for an explanation of
678 canonical ordering. The value of the Next Domain Name field in the
679 last NSEC record in the zone is the name of the zone apex (the owner
680 name of the zone's SOA RR). This indicates that the owner name of
681 the NSEC RR is the last name in the canonical ordering of the zone.
682
683 A sender MUST NOT use DNS name compression on the Next Domain Name
684 field when transmitting an NSEC RR.
685
686 Owner names of RRsets for which the given zone is not authoritative
687 (such as glue records) MUST NOT be listed in the Next Domain Name
688 unless at least one authoritative RRset exists at the same owner
689 name.
690
691 4.1.2. The Type Bit Maps Field
692
693 The Type Bit Maps field identifies the RRset types that exist at the
694 NSEC RR's owner name.
695
696 The RR type space is split into 256 window blocks, each representing
697 the low-order 8 bits of the 16-bit RR type space. Each block that
698 has at least one active RR type is encoded using a single octet
699 window number (from 0 to 255), a single octet bitmap length (from 1
700 to 32) indicating the number of octets used for the window block's
701 bitmap, and up to 32 octets (256 bits) of bitmap.
702
703 Blocks are present in the NSEC RR RDATA in increasing numerical
704 order.
705
706 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
707
708 where "|" denotes concatenation.
709
710
711
712 Arends, et al. Standards Track [Page 13]
713 RFC 4034 DNSSEC Resource Records March 2005
714
715
716 Each bitmap encodes the low-order 8 bits of RR types within the
717 window block, in network bit order. The first bit is bit 0. For
718 window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
719 to RR type 2 (NS), and so forth. For window block 1, bit 1
720 corresponds to RR type 257, and bit 2 to RR type 258. If a bit is
721 set, it indicates that an RRset of that type is present for the NSEC
722 RR's owner name. If a bit is clear, it indicates that no RRset of
723 that type is present for the NSEC RR's owner name.
724
725 Bits representing pseudo-types MUST be clear, as they do not appear
726 in zone data. If encountered, they MUST be ignored upon being read.
727
728 Blocks with no types present MUST NOT be included. Trailing zero
729 octets in the bitmap MUST be omitted. The length of each block's
730 bitmap is determined by the type code with the largest numerical
731 value, within that block, among the set of RR types present at the
732 NSEC RR's owner name. Trailing zero octets not specified MUST be
733 interpreted as zero octets.
734
735 The bitmap for the NSEC RR at a delegation point requires special
736 attention. Bits corresponding to the delegation NS RRset and the RR
737 types for which the parent zone has authoritative data MUST be set;
738 bits corresponding to any non-NS RRset for which the parent is not
739 authoritative MUST be clear.
740
741 A zone MUST NOT include an NSEC RR for any domain name that only
742 holds glue records.
743
744 4.1.3. Inclusion of Wildcard Names in NSEC RDATA
745
746 If a wildcard owner name appears in a zone, the wildcard label ("*")
747 is treated as a literal symbol and is treated the same as any other
748 owner name for the purposes of generating NSEC RRs. Wildcard owner
749 names appear in the Next Domain Name field without any wildcard
750 expansion. [RFC4035] describes the impact of wildcards on
751 authenticated denial of existence.
752
753 4.2. The NSEC RR Presentation Format
754
755 The presentation format of the RDATA portion is as follows:
756
757 The Next Domain Name field is represented as a domain name.
758
759 The Type Bit Maps field is represented as a sequence of RR type
760 mnemonics. When the mnemonic is not known, the TYPE representation
761 described in [RFC3597], Section 5, MUST be used.
762
763
764
765
766
767 Arends, et al. Standards Track [Page 14]
768 RFC 4034 DNSSEC Resource Records March 2005
769
770
771 4.3. NSEC RR Example
772
773 The following NSEC RR identifies the RRsets associated with
774 alfa.example.com. and identifies the next authoritative name after
775 alfa.example.com.
776
777 alfa.example.com. 86400 IN NSEC host.example.com. (
778 A MX RRSIG NSEC TYPE1234 )
779
780 The first four text fields specify the name, TTL, Class, and RR type
781 (NSEC). The entry host.example.com. is the next authoritative name
782 after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC,
783 and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC,
784 and TYPE1234 RRsets associated with the name alfa.example.com.
785
786 The RDATA section of the NSEC RR above would be encoded as:
787
788 0x04 'h' 'o' 's' 't'
789 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
790 0x03 'c' 'o' 'm' 0x00
791 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
792 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
793 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
794 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
795 0x00 0x00 0x00 0x00 0x20
796
797 Assuming that the validator can authenticate this NSEC record, it
798 could be used to prove that beta.example.com does not exist, or to
799 prove that there is no AAAA record associated with alfa.example.com.
800 Authenticated denial of existence is discussed in [RFC4035].
801
802 5. The DS Resource Record
803
804 The DS Resource Record refers to a DNSKEY RR and is used in the DNS
805 DNSKEY authentication process. A DS RR refers to a DNSKEY RR by
806 storing the key tag, algorithm number, and a digest of the DNSKEY RR.
807 Note that while the digest should be sufficient to identify the
808 public key, storing the key tag and key algorithm helps make the
809 identification process more efficient. By authenticating the DS
810 record, a resolver can authenticate the DNSKEY RR to which the DS
811 record points. The key authentication process is described in
812 [RFC4035].
813
814 The DS RR and its corresponding DNSKEY RR have the same owner name,
815 but they are stored in different locations. The DS RR appears only
816 on the upper (parental) side of a delegation, and is authoritative
817 data in the parent zone. For example, the DS RR for "example.com" is
818 stored in the "com" zone (the parent zone) rather than in the
819
820
821
822 Arends, et al. Standards Track [Page 15]
823 RFC 4034 DNSSEC Resource Records March 2005
824
825
826 "example.com" zone (the child zone). The corresponding DNSKEY RR is
827 stored in the "example.com" zone (the child zone). This simplifies
828 DNS zone management and zone signing but introduces special response
829 processing requirements for the DS RR; these are described in
830 [RFC4035].
831
832 The type number for the DS record is 43.
833
834 The DS resource record is class independent.
835
836 The DS RR has no special TTL requirements.
837
838 5.1. DS RDATA Wire Format
839
840 The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet
841 Algorithm field, a 1 octet Digest Type field, and a Digest field.
842
843 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
844 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
845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
846 | Key Tag | Algorithm | Digest Type |
847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
848 / /
849 / Digest /
850 / /
851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
852
853 5.1.1. The Key Tag Field
854
855 The Key Tag field lists the key tag of the DNSKEY RR referred to by
856 the DS record, in network byte order.
857
858 The Key Tag used by the DS RR is identical to the Key Tag used by
859 RRSIG RRs. Appendix B describes how to compute a Key Tag.
860
861 5.1.2. The Algorithm Field
862
863 The Algorithm field lists the algorithm number of the DNSKEY RR
864 referred to by the DS record.
865
866 The algorithm number used by the DS RR is identical to the algorithm
867 number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the
868 algorithm number types.
869
870
871
872
873
874
875
876
877 Arends, et al. Standards Track [Page 16]
878 RFC 4034 DNSSEC Resource Records March 2005
879
880
881 5.1.3. The Digest Type Field
882
883 The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
884 RR. The Digest Type field identifies the algorithm used to construct
885 the digest. Appendix A.2 lists the possible digest algorithm types.
886
887 5.1.4. The Digest Field
888
889 The DS record refers to a DNSKEY RR by including a digest of that
890 DNSKEY RR.
891
892 The digest is calculated by concatenating the canonical form of the
893 fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
894 and then applying the digest algorithm.
895
896 digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
897
898 "|" denotes concatenation
899
900 DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
901
902 The size of the digest may vary depending on the digest algorithm and
903 DNSKEY RR size. As of the time of this writing, the only defined
904 digest algorithm is SHA-1, which produces a 20 octet digest.
905
906 5.2. Processing of DS RRs When Validating Responses
907
908 The DS RR links the authentication chain across zone boundaries, so
909 the DS RR requires extra care in processing. The DNSKEY RR referred
910 to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST
911 have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC
912 zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be
913 used in the validation process.
914
915 5.3. The DS RR Presentation Format
916
917 The presentation format of the RDATA portion is as follows:
918
919 The Key Tag field MUST be represented as an unsigned decimal integer.
920
921 The Algorithm field MUST be represented either as an unsigned decimal
922 integer or as an algorithm mnemonic specified in Appendix A.1.
923
924 The Digest Type field MUST be represented as an unsigned decimal
925 integer.
926
927
928
929
930
931
932 Arends, et al. Standards Track [Page 17]
933 RFC 4034 DNSSEC Resource Records March 2005
934
935
936 The Digest MUST be represented as a sequence of case-insensitive
937 hexadecimal digits. Whitespace is allowed within the hexadecimal
938 text.
939
940 5.4. DS RR Example
941
942 The following example shows a DNSKEY RR and its corresponding DS RR.
943
944 dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
945 fwJr1AYtsmx3TGkJaNXVbfi/
946 2pHm822aJ5iI9BMzNXxeYCmZ
947 DRD99WYwYqUSdjMmmAphXdvx
948 egXd/M5+X7OrzKBaMbCVdFLU
949 Uh6DhweJBjEVv5f2wwjM9Xzc
950 nOf+EPbtG9DMBmADjFDc2w/r
951 ljwvFw==
952 ) ; key id = 60485
953
954 dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
955 98631FAD1A292118 )
956
957 The first four text fields specify the name, TTL, Class, and RR type
958 (DS). Value 60485 is the key tag for the corresponding
959 "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
960 used by this "dskey.example.com." DNSKEY RR. The value 1 is the
961 algorithm used to construct the digest, and the rest of the RDATA
962 text is the digest in hexadecimal.
963
964 6. Canonical Form and Order of Resource Records
965
966 This section defines a canonical form for resource records, a
967 canonical ordering of DNS names, and a canonical ordering of resource
968 records within an RRset. A canonical name order is required to
969 construct the NSEC name chain. A canonical RR form and ordering
970 within an RRset are required in order to construct and verify RRSIG
971 RRs.
972
973 6.1. Canonical DNS Name Order
974
975 For the purposes of DNS security, owner names are ordered by treating
976 individual labels as unsigned left-justified octet strings. The
977 absence of a octet sorts before a zero value octet, and uppercase
978 US-ASCII letters are treated as if they were lowercase US-ASCII
979 letters.
980
981
982
983
984
985
986
987 Arends, et al. Standards Track [Page 18]
988 RFC 4034 DNSSEC Resource Records March 2005
989
990
991 To compute the canonical ordering of a set of DNS names, start by
992 sorting the names according to their most significant (rightmost)
993 labels. For names in which the most significant label is identical,
994 continue sorting according to their next most significant label, and
995 so forth.
996
997 For example, the following names are sorted in canonical DNS name
998 order. The most significant label is "example". At this level,
999 "example" sorts first, followed by names ending in "a.example", then
1000 by names ending "z.example". The names within each level are sorted
1001 in the same way.
1002
1003 example
1004 a.example
1005 yljkjljk.a.example
1006 Z.a.example
1007 zABC.a.EXAMPLE
1008 z.example
1009 \001.z.example
1010 *.z.example
1011 \200.z.example
1012
1013 6.2. Canonical RR Form
1014
1015 For the purposes of DNS security, the canonical form of an RR is the
1016 wire format of the RR where:
1017
1018 1. every domain name in the RR is fully expanded (no DNS name
1019 compression) and fully qualified;
1020
1021 2. all uppercase US-ASCII letters in the owner name of the RR are
1022 replaced by the corresponding lowercase US-ASCII letters;
1023
Section 3 of RFC4470 explicitly changes how the "next name" field is calculated. It says:
In the "next name" field of instantiated names' NSEC records, rather than list the next instantiated name in the zone, list any name that falls lexically after the NSEC's owner name and before the next instantiated name in the zone, according to the ordering function in RFC 4034 [2] Section 6.1. This relaxes the requirement in Section 4.1.1 of RFC 4034 that the "next name" field contains the next owner name in the zone. This change is expected to be fully compatible with all existing DNSSEC validators. These NSEC records are returned whenever proving something specifically about the owner name (e.g., that no resource records of a given type appear at that name).
1024 3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
1025 HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
1026 SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
1027 the DNS names contained within the RDATA are replaced by the
1028 corresponding lowercase US-ASCII letters;
1029
1030 4. if the owner name of the RR is a wildcard name, the owner name is
1031 in its original unexpanded form, including the "*" label (no
1032 wildcard substitution); and
1033
1034 5. the RR's TTL is set to its original value as it appears in the
1035 originating authoritative zone or the Original TTL field of the
1036 covering RRSIG RR.
1037
1038
1039
1040
1041
1042 Arends, et al. Standards Track [Page 19]
1043 RFC 4034 DNSSEC Resource Records March 2005
1044
1045
1046 6.3. Canonical RR Ordering within an RRset
1047
1048 For the purposes of DNS security, RRs with the same owner name,
1049 class, and type are sorted by treating the RDATA portion of the
1050 canonical form of each RR as a left-justified unsigned octet sequence
1051 in which the absence of an octet sorts before a zero octet.
1052
1053 [RFC2181] specifies that an RRset is not allowed to contain duplicate
1054 records (multiple RRs with the same owner name, class, type, and
1055 RDATA). Therefore, if an implementation detects duplicate RRs when
1056 putting the RRset in canonical form, it MUST treat this as a protocol
1057 error. If the implementation chooses to handle this protocol error
1058 in the spirit of the robustness principle (being liberal in what it
1059 accepts), it MUST remove all but one of the duplicate RR(s) for the
1060 purposes of calculating the canonical form of the RRset.
1061
3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
the DNS names contained within the RDATA are replaced by the
corresponding lowercase US-ASCII letters;
[not supplied]
"As a courtesy to implementors, it is hereby noted that the complete set of such previously published RR types that contain embedded domain names, and whose DNSSEC canonical form therefore involves downcasing according to the DNS rules for character comparisons, consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, and A6."
Section 5.1 of RFC6840 is titled "Errors in Canonical Form Type Code List". It specifies:
When canonicalizing DNS names (for both ordering and signing), DNS names in the RDATA section of NSEC resource records are not converted to lowercase. DNS names in the RDATA section of RRSIG resource records are converted to lowercase.
It makes this specification because:
The guidance in the above paragraph differs from what has been published before but is consistent with current common practice. Item 3 of Section 6.2 of [RFC4034] says that names in both of these RR types should be converted to lowercase. The earlier [RFC3755] says that they should not. Current practice follows neither document fully. Section 6.2 of [RFC4034] also erroneously lists HINFO as a record that needs conversion to lowercase, and twice at that. Since HINFO records contain no domain names, they are not subject to case conversion.
1062 7. IANA Considerations
1063
1064 This document introduces no new IANA considerations, as all of the
1065 protocol parameters used in this document have already been assigned
1066 by previous specifications. However, since the evolution of DNSSEC
1067 has been long and somewhat convoluted, this section attempts to
1068 describe the current state of the IANA registries and other protocol
1069 parameters that are (or once were) related to DNSSEC.
1070
1071 Please refer to [RFC4035] for additional IANA considerations.
1072
1073 DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
1074 the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS
1075 Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47,
1076 and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
1077 [RFC3755] also marked type 30 (NXT) as Obsolete and restricted use
1078 of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction
1079 security protocol described in [RFC2931] and to the transaction
1080 KEY Resource Record described in [RFC2930].
1081
1082 DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
1083 for DNSSEC Resource Record Algorithm field numbers and assigned
1084 values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755]
1085 altered this registry to include flags for each entry regarding
1086 its use with the DNS security extensions. Each algorithm entry
1087 could refer to an algorithm that can be used for zone signing,
1088 transaction security (see [RFC2931]), or both. Values 6-251 are
1089 available for assignment by IETF standards action ([RFC3755]).
1090 See Appendix A for a full listing of the DNS Security Algorithm
1091 Numbers entries at the time of this writing and their status for
1092 use in DNSSEC.
1093
1094
1095
1096
1097 Arends, et al. Standards Track [Page 20]
1098 RFC 4034 DNSSEC Resource Records March 2005
1099
1100
1101 [RFC3658] created an IANA registry for DNSSEC DS Digest Types and
1102 assigned value 0 to reserved and value 1 to SHA-1.
1103
1104 KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
1105 Protocol Values, but [RFC3445] reassigned all values other than 3
1106 to reserved and closed this IANA registry. The registry remains
1107 closed, and all KEY and DNSKEY records are required to have a
1108 Protocol Octet value of 3.
1109
1110 Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
1111 registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially,
1112 this registry only contains assignments for bit 7 (the ZONE bit)
1113 and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]).
1114 As stated in [RFC3755], bits 0-6 and 8-14 are available for
1115 assignment by IETF Standards Action.
1116
1117 8. Security Considerations
1118
1119 This document describes the format of four DNS resource records used
1120 by the DNS security extensions and presents an algorithm for
1121 calculating a key tag for a public key. Other than the items
1122 described below, the resource records themselves introduce no
1123 security considerations. Please see [RFC4033] and [RFC4035] for
1124 additional security considerations related to the use of these
1125 records.
1126
1127 The DS record points to a DNSKEY RR by using a cryptographic digest,
1128 the key algorithm type, and a key tag. The DS record is intended to
1129 identify an existing DNSKEY RR, but it is theoretically possible for
1130 an attacker to generate a DNSKEY that matches all the DS fields. The
1131 probability of constructing a matching DNSKEY depends on the type of
1132 digest algorithm in use. The only currently defined digest algorithm
1133 is SHA-1, and the working group believes that constructing a public
1134 key that would match the algorithm, key tag, and SHA-1 digest given
1135 in a DS record would be a sufficiently difficult problem that such an
1136 attack is not a serious threat at this time.
1137
1138 The key tag is used to help select DNSKEY resource records
1139 efficiently, but it does not uniquely identify a single DNSKEY
1140 resource record. It is possible for two distinct DNSKEY RRs to have
1141 the same owner name, the same algorithm type, and the same key tag.
1142 An implementation that uses only the key tag to select a DNSKEY RR
1143 might select the wrong public key in some circumstances. Please see
1144 Appendix B for further details.
1145
1146
1147
1148
1149
1150
1151
1152 Arends, et al. Standards Track [Page 21]
1153 RFC 4034 DNSSEC Resource Records March 2005
1154
1155
1156 The table of algorithms in Appendix A and the key tag calculation
1157 algorithms in Appendix B include the RSA/MD5 algorithm for
1158 completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as
1159 explained in [RFC3110].
1160
1161 9. Acknowledgements
1162
1163 This document was created from the input and ideas of the members of
1164 the DNS Extensions Working Group and working group mailing list. The
1165 editors would like to express their thanks for the comments and
1166 suggestions received during the revision of these security extension
1167 specifications. Although explicitly listing everyone who has
1168 contributed during the decade in which DNSSEC has been under
1169 development would be impossible, [RFC4033] includes a list of some of
1170 the participants who were kind enough to comment on these documents.
1171
1172 10. References
1173
1174 10.1. Normative References
1175
1176 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
1177 STD 13, RFC 1034, November 1987.
1178
1179 [RFC1035] Mockapetris, P., "Domain names - implementation and
1180 specification", STD 13, RFC 1035, November 1987.
1181
1182 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
1183 August 1996.
1184
1185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1186 Requirement Levels", BCP 14, RFC 2119, March 1997.
1187
1188 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1189 Specification", RFC 2181, July 1997.
1190
1191 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
1192 NCACHE)", RFC 2308, March 1998.
1193
1194 [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
1195 System (DNS)", RFC 2536, March 1999.
1196
1197 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
1198 ( SIG(0)s )", RFC 2931, September 2000.
1199
1200 [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
1201 Domain Name System (DNS)", RFC 3110, May 2001.
1202
1203
1204
1205
1206
1207 Arends, et al. Standards Track [Page 22]
1208 RFC 4034 DNSSEC Resource Records March 2005
1209
1210
1211 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
1212 Resource Record (RR)", RFC 3445, December 2002.
1213
1214 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
1215 Encodings", RFC 3548, July 2003.
1216
1217 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
1218 (RR) Types", RFC 3597, September 2003.
1219
1220 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
1221 (RR)", RFC 3658, December 2003.
1222
1223 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
1224 Signer (DS)", RFC 3755, May 2004.
1225
1226 [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
1227 System KEY (DNSKEY) Resource Record (RR) Secure Entry
1228 Point (SEP) Flag", RFC 3757, April 2004.
1229
1230 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1231 Rose, "DNS Security Introduction and Requirements", RFC
1232 4033, March 2005.
1233
1234 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1235 Rose, "Protocol Modifications for the DNS Security
1236 Extensions", RFC 4035, March 2005.
1237
1238 10.2. Informative References
1239
1240 [RFC2535] Eastlake 3rd, D., "Domain Name System Security
1241 Extensions", RFC 2535, March 1999.
1242
1243 [RFC2537] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain
1244 Name System (DNS)", RFC 2537, March 1999.
1245
1246 [RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
1247 Domain Name System (DNS)", RFC 2539, March 1999.
1248
1249 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
1250 RR)", RFC 2930, September 2000.
1251
1252 [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
1253 RDATA Format", RFC 3845, August 2004.
1254
1255
1256
1257
1258
1259
1260
1261
1262 Arends, et al. Standards Track [Page 23]
1263 RFC 4034 DNSSEC Resource Records March 2005
1264
1265
1266 Appendix A. DNSSEC Algorithm and Digest Types
1267
1268 The DNS security extensions are designed to be independent of the
1269 underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS
1270 resource records all use a DNSSEC Algorithm Number to identify the
1271 cryptographic algorithm in use by the resource record. The DS
1272 resource record also specifies a Digest Algorithm Number to identify
1273 the digest algorithm used to construct the DS record. The currently
1274 defined Algorithm and Digest Types are listed below. Additional
1275 Algorithm or Digest Types could be added as advances in cryptography
1276 warrant them.
1277
1278 A DNSSEC aware resolver or name server MUST implement all MANDATORY
1279 algorithms.
1280
1281 A.1. DNSSEC Algorithm Types
1282
1283 The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the
1284 security algorithm being used. These values are stored in the
1285 "Algorithm number" field in the resource record RDATA.
1286
1287 Some algorithms are usable only for zone signing (DNSSEC), some only
1288 for transaction security mechanisms (SIG(0) and TSIG), and some for
1289 both. Those usable for zone signing may appear in DNSKEY, RRSIG, and
1290 DS RRs. Those usable for transaction security would be present in
1291 SIG(0) and KEY RRs, as described in [RFC2931].
1292
1293 Zone
1294 Value Algorithm [Mnemonic] Signing References Status
1295 ----- -------------------- --------- ---------- ---------
1296 0 reserved
1297 1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED
1298 2 Diffie-Hellman [DH] n [RFC2539] -
1299 3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL
1300 4 Elliptic Curve [ECC] TBA -
1301 5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY
1302 252 Indirect [INDIRECT] n -
1303 253 Private [PRIVATEDNS] y see below OPTIONAL
1304 254 Private [PRIVATEOID] y see below OPTIONAL
1305 255 reserved
1306
1307 6 - 251 Available for assignment by IETF Standards Action.
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317 Arends, et al. Standards Track [Page 24]
1318 RFC 4034 DNSSEC Resource Records March 2005
1319
1320
1321 A.1.1. Private Algorithm Types
1322
1323 Algorithm number 253 is reserved for private use and will never be
1324 assigned to a specific algorithm. The public key area in the DNSKEY
1325 RR and the signature area in the RRSIG RR begin with a wire encoded
1326 domain name, which MUST NOT be compressed. The domain name indicates
1327 the private algorithm to use, and the remainder of the public key
1328 area is determined by that algorithm. Entities should only use
1329 domain names they control to designate their private algorithms.
1330
1331 Algorithm number 254 is reserved for private use and will never be
1332 assigned to a specific algorithm. The public key area in the DNSKEY
1333 RR and the signature area in the RRSIG RR begin with an unsigned
1334 length byte followed by a BER encoded Object Identifier (ISO OID) of
1335 that length. The OID indicates the private algorithm in use, and the
1336 remainder of the area is whatever is required by that algorithm.
1337 Entities should only use OIDs they control to designate their private
1338 algorithms.
1339
1340 A.2. DNSSEC Digest Types
1341
1342 A "Digest Type" field in the DS resource record types identifies the
1343 cryptographic digest algorithm used by the resource record. The
1344 following table lists the currently defined digest algorithm types.
1345
1346 VALUE Algorithm STATUS
1347 0 Reserved -
1348 1 SHA-1 MANDATORY
1349 2-255 Unassigned -
1350
1351 Appendix B. Key Tag Calculation
1352
1353 The Key Tag field in the RRSIG and DS resource record types provides
1354 a mechanism for selecting a public key efficiently. In most cases, a
1355 combination of owner name, algorithm, and key tag can efficiently
1356 identify a DNSKEY record. Both the RRSIG and DS resource records
1357 have corresponding DNSKEY records. The Key Tag field in the RRSIG
1358 and DS records can be used to help select the corresponding DNSKEY RR
1359 efficiently when more than one candidate DNSKEY RR is available.
1360
1361 However, it is essential to note that the key tag is not a unique
1362 identifier. It is theoretically possible for two distinct DNSKEY RRs
1363 to have the same owner name, the same algorithm, and the same key
1364 tag. The key tag is used to limit the possible candidate keys, but
1365 it does not uniquely identify a DNSKEY record. Implementations MUST
1366 NOT assume that the key tag uniquely identifies a DNSKEY RR.
1367
1368
1369
1370
1371
1372 Arends, et al. Standards Track [Page 25]
1373 RFC 4034 DNSSEC Resource Records March 2005
1374
1375
1376 The key tag is the same for all DNSKEY algorithm types except
1377 algorithm 1 (please see Appendix B.1 for the definition of the key
1378 tag for algorithm 1). The key tag algorithm is the sum of the wire
1379 format of the DNSKEY RDATA broken into 2 octet groups. First, the
1380 RDATA (in wire format) is treated as a series of 2 octet groups.
The key tag is the same for all DNSKEY algorithm types except algorithm 1 (please see Appendix B.1 for the definition of the key tag for algorithm 1). The key tag algorithm is the sum of the wire format of the DNSKEY RDATA broken into 2 octet groups. First, the RDATA (in wire format) is treated as a series of 2 octet groups. These groups are then added together, ignoring any carry bits.
The key tag is the same for all DNSKEY algorithm types except algorithm 1 (please see Appendix B.1 for the definition of the key tag for algorithm 1). The key tag algorithm is the sum of the wire format of the DNSKEY RDATA broken into 2 octet groups. First, the RDATA (in wire format) is treated as a series of 2 octet groups. These groups are then added together, ignoring any carry bitswith at least 32-bit precision, retaining any carry bits. The carry bits are then added to the result, and finally, only the lower 16 bits of the result are used as the key tag.
ac += (ac >> 16) & 0xFFFF;
1381 These groups are then added together, ignoring any carry bits.
1382
1383 A reference implementation of the key tag algorithm is as an ANSI C
1384 function is given below, with the RDATA portion of the DNSKEY RR is
1385 used as input. It is not necessary to use the following reference
1386 code verbatim, but the numerical value of the Key Tag MUST be
1387 identical to what the reference implementation would generate for the
1388 same input.
1389
1390 Please note that the algorithm for calculating the Key Tag is almost
1391 but not completely identical to the familiar ones-complement checksum
1392 used in many other Internet protocols. Key Tags MUST be calculated
1393 using the algorithm described here rather than the ones complement
1394 checksum.
1395
1396 The following ANSI C reference implementation calculates the value of
1397 a Key Tag. This reference implementation applies to all algorithm
1398 types except algorithm 1 (see Appendix B.1). The input is the wire
1399 format of the RDATA portion of the DNSKEY RR. The code is written
1400 for clarity, not efficiency.
1401
1402 /*
1403 * Assumes that int is at least 16 bits.
1404 * First octet of the key tag is the most significant 8 bits of the
1405 * return value;
1406 * Second octet of the key tag is the least significant 8 bits of the
1407 * return value.
1408 */
1409
1410 unsigned int
1411 keytag (
1412 unsigned char key[], /* the RDATA part of the DNSKEY RR */
1413 unsigned int keysize /* the RDLENGTH */
1414 )
1415 {
1416 unsigned long ac; /* assumed to be 32 bits or larger */
1417 int i; /* loop index */
1418
1419 for ( ac = 0, i = 0; i < keysize; ++i )
1420 ac += (i & 1) ? key[i] : key[i] << 8;
1421 ac += (ac >> 16) & 0xFFFF;
1422 return ac & 0xFFFF;
1423 }
1424
1425
1426
1427 Arends, et al. Standards Track [Page 26]
1428 RFC 4034 DNSSEC Resource Records March 2005
1429
1430
These groups are then added together, ignoring any carry bits.
These groups are then added together, ignoring any carry bitswith at least 32-bit precision, retaining any carry bits. The carry bits are then added to the result, and finally, only the lower 16 bits of the result are used as the key tag. Note that this means any carries generated during the addition of the carry bits are ignored. This, in turn, means that the keytag calculation is often the same as reduction modulo 65535, but not always.
1431 B.1. Key Tag for Algorithm 1 (RSA/MD5)
1432
1433 The key tag for algorithm 1 (RSA/MD5) is defined differently from the
Section 5.5 of RFC6840 is titled "Key Tag Calculation". It says:
Appendix B.1 of [RFC4034] incorrectly defines the Key Tag field calculation for algorithm 1. It correctly says that the Key Tag is the most significant 16 of the least significant 24 bits of the public key modulus. However, [RFC4034] then goes on to incorrectly say that this is fourth-to-last and third-to-last octets of the public key modulus. It is, in fact, the third-to-last and second-to- last octets.
1434 key tag for all other algorithms, for historical reasons. For a
1435 DNSKEY RR with algorithm 1, the key tag is defined to be the most
1436 significant 16 bits of the least significant 24 bits in the public
1437 key modulus (in other words, the 4th to last and 3rd to last octets
1438 of the public key modulus).
1439
1440 Please note that Algorithm 1 is NOT RECOMMENDED.
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482 Arends, et al. Standards Track [Page 27]
1483 RFC 4034 DNSSEC Resource Records March 2005
1484
1485
1486 Authors' Addresses
1487
1488 Roy Arends
1489 Telematica Instituut
1490 Brouwerijstraat 1
1491 7523 XC Enschede
1492 NL
1493
1494 EMail: roy.arends@telin.nl
1495
1496
1497 Rob Austein
1498 Internet Systems Consortium
1499 950 Charter Street
1500 Redwood City, CA 94063
1501 USA
1502
1503 EMail: sra@isc.org
1504
1505
1506 Matt Larson
1507 VeriSign, Inc.
1508 21345 Ridgetop Circle
1509 Dulles, VA 20166-6503
1510 USA
1511
1512 EMail: mlarson@verisign.com
1513
1514
1515 Dan Massey
1516 Colorado State University
1517 Department of Computer Science
1518 Fort Collins, CO 80523-1873
1519
1520 EMail: massey@cs.colostate.edu
1521
1522
1523 Scott Rose
1524 National Institute for Standards and Technology
1525 100 Bureau Drive
1526 Gaithersburg, MD 20899-8920
1527 USA
1528
1529 EMail: scott.rose@nist.gov
1530
1531
1532
1533
1534
1535
1536
1537 Arends, et al. Standards Track [Page 28]
1538 RFC 4034 DNSSEC Resource Records March 2005
1539
1540
1541 Full Copyright Statement
1542
1543 Copyright (C) The Internet Society (2005).
1544
1545 This document is subject to the rights, licenses and restrictions
1546 contained in BCP 78, and except as set forth therein, the authors
1547 retain all their rights.
1548
1549 This document and the information contained herein are provided on an
1550 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1551 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1552 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1553 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1554 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1555 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1556
1557 Intellectual Property
1558
1559 The IETF takes no position regarding the validity or scope of any
1560 Intellectual Property Rights or other rights that might be claimed to
1561 pertain to the implementation or use of the technology described in
1562 this document or the extent to which any license under such rights
1563 might or might not be available; nor does it represent that it has
1564 made any independent effort to identify any such rights. Information
1565 on the procedures with respect to rights in RFC documents can be
1566 found in BCP 78 and BCP 79.
1567
1568 Copies of IPR disclosures made to the IETF Secretariat and any
1569 assurances of licenses to be made available, or the result of an
1570 attempt made to obtain a general license or permission for the use of
1571 such proprietary rights by implementers or users of this
1572 specification can be obtained from the IETF on-line IPR repository at
1573 http://www.ietf.org/ipr.
1574
1575 The IETF invites any interested party to bring to its attention any
1576 copyrights, patents or patent applications, or other proprietary
1577 rights that may cover technology that may be required to implement
1578 this standard. Please address the information to the IETF at ietf-
1579 ipr@ietf.org.
1580
1581 Acknowledgement
1582
1583 Funding for the RFC Editor function is currently provided by the
1584 Internet Society.
1585
1586
1587
1588
1589
1590
1591
1592 Arends, et al. Standards Track [Page 29]
1593
For a
DNSKEY RR with algorithm 1, the key tag is defined to be the most
significant 16 bits of the least significant 24 bits in the public
key modulus (in other words, the 4th to last and 3rd to last octets
of the public key modulus).
For a
DNSKEY RR with algorithm 1, the key tag is defined to be the most
significant 16 bits of the least significant 24 bits in the public
key modulus (in other words, the 4th3rd to last and 3rd2nd to last octets
of the public key modulus).