diff options
Diffstat (limited to 'doc/rfc/rfc4034.txt')
| -rw-r--r-- | doc/rfc/rfc4034.txt | 1627 |
1 files changed, 1627 insertions, 0 deletions
diff --git a/doc/rfc/rfc4034.txt b/doc/rfc/rfc4034.txt new file mode 100644 index 0000000..6a12c6b --- /dev/null +++ b/doc/rfc/rfc4034.txt @@ -0,0 +1,1627 @@ + + + + + + +Network Working Group R. Arends +Request for Comments: 4034 Telematica Instituut +Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein + 3755, 3757, 3845 ISC +Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson + 3007, 3597, 3226 VeriSign +Category: Standards Track D. Massey + Colorado State University + S. Rose + NIST + March 2005 + + + Resource Records for the DNS Security Extensions + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document is part of a family of documents that describe the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of resource records and protocol modifications that + provide source authentication for the DNS. This document defines the + public key (DNSKEY), delegation signer (DS), resource record digital + signature (RRSIG), and authenticated denial of existence (NSEC) + resource records. The purpose and format of each resource record is + described in detail, and an example of each resource record is given. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + + + + + + + + + + + +Arends, et al. Standards Track [Page 1] + +RFC 4034 DNSSEC Resource Records March 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Background and Related Documents . . . . . . . . . . . 3 + 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . 3 + 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 4 + 2.1. DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . 4 + 2.1.1. The Flags Field. . . . . . . . . . . . . . . . 4 + 2.1.2. The Protocol Field . . . . . . . . . . . . . . 5 + 2.1.3. The Algorithm Field. . . . . . . . . . . . . . 5 + 2.1.4. The Public Key Field . . . . . . . . . . . . . 5 + 2.1.5. Notes on DNSKEY RDATA Design . . . . . . . . . 5 + 2.2. The DNSKEY RR Presentation Format. . . . . . . . . . . 5 + 2.3. DNSKEY RR Example . . . . . . . . . . . . . . . . . . 6 + 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 6 + 3.1. RRSIG RDATA Wire Format. . . . . . . . . . . . . . . . 7 + 3.1.1. The Type Covered Field . . . . . . . . . . . . 7 + 3.1.2. The Algorithm Number Field . . . . . . . . . . 8 + 3.1.3. The Labels Field . . . . . . . . . . . . . . . 8 + 3.1.4. Original TTL Field . . . . . . . . . . . . . . 8 + 3.1.5. Signature Expiration and Inception Fields. . . 9 + 3.1.6. The Key Tag Field. . . . . . . . . . . . . . . 9 + 3.1.7. The Signer's Name Field. . . . . . . . . . . . 9 + 3.1.8. The Signature Field. . . . . . . . . . . . . . 9 + 3.2. The RRSIG RR Presentation Format . . . . . . . . . . . 10 + 3.3. RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11 + 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12 + 4.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13 + 4.1.1. The Next Domain Name Field . . . . . . . . . . 13 + 4.1.2. The Type Bit Maps Field. . . . . . . . . . . . 13 + 4.1.3. Inclusion of Wildcard Names in NSEC RDATA. . . 14 + 4.2. The NSEC RR Presentation Format. . . . . . . . . . . . 14 + 4.3. NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15 + 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 15 + 5.1. DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16 + 5.1.1. The Key Tag Field. . . . . . . . . . . . . . . 16 + 5.1.2. The Algorithm Field. . . . . . . . . . . . . . 16 + 5.1.3. The Digest Type Field. . . . . . . . . . . . . 17 + 5.1.4. The Digest Field . . . . . . . . . . . . . . . 17 + 5.2. Processing of DS RRs When Validating Responses . . . . 17 + 5.3. The DS RR Presentation Format. . . . . . . . . . . . . 17 + 5.4. DS RR Example. . . . . . . . . . . . . . . . . . . . . 18 + 6. Canonical Form and Order of Resource Records . . . . . . . . 18 + 6.1. Canonical DNS Name Order . . . . . . . . . . . . . . . 18 + 6.2. Canonical RR Form. . . . . . . . . . . . . . . . . . . 19 + 6.3. Canonical RR Ordering within an RRset. . . . . . . . . 20 + 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20 + 8. Security Considerations. . . . . . . . . . . . . . . . . . . 21 + + + +Arends, et al. Standards Track [Page 2] + +RFC 4034 DNSSEC Resource Records March 2005 + + + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 10.1. Normative References . . . . . . . . . . . . . . . . . 22 + 10.2. Informative References . . . . . . . . . . . . . . . . 23 + A. DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24 + A.1. DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24 + A.1.1. Private Algorithm Types. . . . . . . . . . . . 25 + A.2. DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25 + B. Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25 + B.1. Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29 + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduce four new DNS resource + record types: DNS Public Key (DNSKEY), Resource Record Signature + (RRSIG), Next Secure (NSEC), and Delegation Signer (DS). This + document defines the purpose of each resource record (RR), the RR's + RDATA format, and its presentation format (ASCII representation). + +1.1. Background and Related Documents + + This document is part of a family of documents defining DNSSEC, which + should be read together as a set. + + [RFC4033] contains an introduction to DNSSEC and definition of common + terms; the reader is assumed to be familiar with this document. + [RFC4033] also contains a list of other documents updated by and + obsoleted by this document set. + + [RFC4035] defines the DNSSEC protocol operations. + + The reader is also assumed to be familiar with the basic DNS concepts + described in [RFC1034], [RFC1035], and the subsequent documents that + update them, particularly [RFC2181] and [RFC2308]. + + This document defines the DNSSEC resource records. All numeric DNS + type codes given in this document are decimal integers. + +1.2. Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + + +Arends, et al. Standards Track [Page 3] + +RFC 4034 DNSSEC Resource Records March 2005 + + +2. The DNSKEY Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). The public keys are stored in DNSKEY + resource records and are used in the DNSSEC authentication process + described in [RFC4035]: A zone signs its authoritative RRsets by + using a private key and stores the corresponding public key in a + DNSKEY RR. A resolver can then use the public key to validate + signatures covering the RRsets in the zone, and thus to authenticate + them. + + The DNSKEY RR is not intended as a record for storing arbitrary + public keys and MUST NOT be used to store certificates or public keys + that do not directly relate to the DNS infrastructure. + + The Type value for the DNSKEY RR type is 48. + + The DNSKEY RR is class independent. + + The DNSKEY RR has no special TTL requirements. + +2.1. DNSKEY RDATA Wire Format + + The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 + octet Protocol Field, a 1 octet Algorithm Field, and the Public Key + Field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Protocol | Algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Public Key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.1.1. The Flags Field + + Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, + then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's + owner name MUST be the name of a zone. If bit 7 has value 0, then + the DNSKEY record holds some other type of DNS public key and MUST + NOT be used to verify RRSIGs that cover RRsets. + + Bit 15 of the Flags field is the Secure Entry Point flag, described + in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a + key intended for use as a secure entry point. This flag is only + + + +Arends, et al. Standards Track [Page 4] + +RFC 4034 DNSSEC Resource Records March 2005 + + + intended to be a hint to zone signing or debugging software as to the + intended use of this DNSKEY record; validators MUST NOT alter their + behavior during the signature validation process in any way based on + the setting of this bit. This also means that a DNSKEY RR with the + SEP bit set would also need the Zone Key flag set in order to be able + to generate signatures legally. A DNSKEY RR with the SEP set and the + Zone Key flag not set MUST NOT be used to verify RRSIGs that cover + RRsets. + + Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon + creation of the DNSKEY RR and MUST be ignored upon receipt. + +2.1.2. The Protocol Field + + The Protocol Field MUST have value 3, and the DNSKEY RR MUST be + treated as invalid during signature verification if it is found to be + some value other than 3. + +2.1.3. The Algorithm Field + + The Algorithm field identifies the public key's cryptographic + algorithm and determines the format of the Public Key field. A list + of DNSSEC algorithm types can be found in Appendix A.1 + +2.1.4. The Public Key Field + + The Public Key Field holds the public key material. The format + depends on the algorithm of the key being stored and is described in + separate documents. + +2.1.5. Notes on DNSKEY RDATA Design + + Although the Protocol Field always has value 3, it is retained for + backward compatibility with early versions of the KEY record. + +2.2. The DNSKEY RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Flag field MUST be represented as an unsigned decimal integer. + Given the currently defined flags, the possible values are: 0, 256, + and 257. + + The Protocol Field MUST be represented as an unsigned decimal integer + with a value of 3. + + The Algorithm field MUST be represented either as an unsigned decimal + integer or as an algorithm mnemonic as specified in Appendix A.1. + + + +Arends, et al. Standards Track [Page 5] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The Public Key field MUST be represented as a Base64 encoding of the + Public Key. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding, see [RFC3548]. + +2.3. DNSKEY RR Example + + The following DNSKEY RR stores a DNS zone key for example.com. + + example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 + Cbl+BBZH4b/0PY1kxkmvHjcZc8no + kfzj31GajIQKY+5CptLr3buXA10h + WqTkF7H6RfoRqXQeogmMHfpftf6z + Mv1LyBUgia7za6ZEzOJBOztyvhjL + 742iU/TpPSEDhm2SNKLijfUppn1U + aNvv4w== ) + + The first four text fields specify the owner name, TTL, Class, and RR + type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in + the Flags field has value 1. Value 3 is the fixed Protocol value. + Value 5 indicates the public key algorithm. Appendix A.1 identifies + algorithm type 5 as RSA/SHA1 and indicates that the format of the + RSA/SHA1 public key field is defined in [RFC3110]. The remaining + text is a Base64 encoding of the public key. + +3. The RRSIG Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). Digital signatures are stored in + RRSIG resource records and are used in the DNSSEC authentication + process described in [RFC4035]. A validator can use these RRSIG RRs + to authenticate RRsets from the zone. The RRSIG RR MUST only be used + to carry verification material (digital signatures) used to secure + DNS operations. + + An RRSIG record contains the signature for an RRset with a particular + name, class, and type. The RRSIG RR specifies a validity interval + for the signature and uses the Algorithm, the Signer's Name, and the + Key Tag to identify the DNSKEY RR containing the public key that a + validator can use to verify the signature. + + Because every authoritative RRset in a zone must be protected by a + digital signature, RRSIG RRs must be present for names containing a + CNAME RR. This is a change to the traditional DNS specification + [RFC1034], which stated that if a CNAME is present for a name, it is + the only type allowed at that name. A RRSIG and NSEC (see Section 4) + MUST exist for the same name as a CNAME resource record in a signed + zone. + + + + +Arends, et al. Standards Track [Page 6] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The Type value for the RRSIG RR type is 46. + + The RRSIG RR is class independent. + + An RRSIG RR MUST have the same class as the RRset it covers. + + The TTL value of an RRSIG RR MUST match the TTL value of the RRset it + covers. This is an exception to the [RFC2181] rules for TTL values + of individual RRs within a RRset: individual RRSIG RRs with the same + owner name will have different TTL values if the RRsets they cover + have different TTL values. + +3.1. RRSIG RDATA Wire Format + + The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a + 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original + TTL field, a 4 octet Signature Expiration field, a 4 octet Signature + Inception field, a 2 octet Key tag, the Signer's Name field, and the + Signature field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type Covered | Algorithm | Labels | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Original TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Expiration | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Inception | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Signature / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +3.1.1. The Type Covered Field + + The Type Covered field identifies the type of the RRset that is + covered by this RRSIG record. + + + + + + + +Arends, et al. Standards Track [Page 7] + +RFC 4034 DNSSEC Resource Records March 2005 + + +3.1.2. The Algorithm Number Field + + The Algorithm Number field identifies the cryptographic algorithm + used to create the signature. A list of DNSSEC algorithm types can + be found in Appendix A.1 + +3.1.3. The Labels Field + + The Labels field specifies the number of labels in the original RRSIG + RR owner name. The significance of this field is that a validator + uses it to determine whether the answer was synthesized from a + wildcard. If so, it can be used to determine what owner name was + used in generating the signature. + + To validate a signature, the validator needs the original owner name + that was used to create the signature. If the original owner name + contains a wildcard label ("*"), the owner name may have been + expanded by the server during the response process, in which case the + validator will have to reconstruct the original owner name in order + to validate the signature. [RFC4035] describes how to use the Labels + field to reconstruct the original owner name. + + 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 be less than or equal + to the number of labels in the RRSIG owner name. For example, + "www.example.com." has a Labels field value of 3, and + "*.example.com." has a Labels field value of 2. Root (".") has a + Labels field value of 0. + + Although the wildcard label is not included in the count stored in + the Labels field of the RRSIG RR, the wildcard label is part of the + RRset's owner name when the signature is generated or verified. + +3.1.4. Original TTL Field + + The Original TTL field specifies the TTL of the covered RRset as it + appears in the authoritative zone. + + The Original TTL field is necessary because a caching resolver + decrements the TTL value of a cached RRset. In order to validate a + signature, a validator requires the original TTL. [RFC4035] + describes how to use the Original TTL field value to reconstruct the + original TTL. + + + + + + + +Arends, et al. Standards Track [Page 8] + +RFC 4034 DNSSEC Resource Records March 2005 + + +3.1.5. Signature Expiration and Inception Fields + + The Signature Expiration and Inception fields specify a validity + period for the signature. The RRSIG record MUST NOT be used for + authentication prior to the inception date and MUST NOT be used for + authentication after the expiration date. + + The Signature Expiration and Inception field values specify a date + and time in the form of a 32-bit unsigned number of seconds elapsed + since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network + byte order. The longest interval that can be expressed by this + format without wrapping is approximately 136 years. An RRSIG RR can + have an Expiration field value that is numerically smaller than the + Inception field value if the expiration field value is near the + 32-bit wrap-around point or if the signature is long lived. Because + of this, all comparisons involving these fields MUST use "Serial + number arithmetic", as defined in [RFC1982]. As a direct + consequence, the values contained in these fields cannot refer to + dates more than 68 years in either the past or the future. + +3.1.6. The Key Tag Field + + The Key Tag field contains the key tag value of the DNSKEY RR that + validates this signature, in network byte order. Appendix B explains + how to calculate Key Tag values. + +3.1.7. The Signer's Name Field + + The Signer's Name field value identifies the owner name of the DNSKEY + RR that a validator is supposed to use to validate this signature. + The Signer's Name field MUST contain the name of the zone of the + covered RRset. A sender MUST NOT use DNS name compression on the + Signer's Name field when transmitting a RRSIG RR. + +3.1.8. The Signature Field + + The Signature field contains the cryptographic signature that covers + the RRSIG RDATA (excluding the Signature field) and the RRset + specified by the RRSIG owner name, RRSIG class, and RRSIG Type + Covered field. The format of this field depends on the algorithm in + use, and these formats are described in separate companion documents. + +3.1.8.1. Signature Calculation + + A signature covers the RRSIG RDATA (excluding the Signature Field) + and covers the data RRset specified by the RRSIG owner name, RRSIG + class, and RRSIG Type Covered fields. The RRset is in canonical form + (see Section 6), and the set RR(1),...RR(n) is signed as follows: + + + +Arends, et al. Standards Track [Page 9] + +RFC 4034 DNSSEC Resource Records March 2005 + + + signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where + + "|" denotes concatenation; + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signer's Name field in canonical form and + the Signature field excluded; + + RR(i) = owner | type | class | TTL | RDATA length | RDATA + + "owner" is the fully qualified owner name of the RRset in + canonical form (for RRs with wildcard owner names, the + wildcard label is included in the owner name); + + Each RR MUST have the same owner name as the RRSIG RR; + + Each RR MUST have the same class as the RRSIG RR; + + Each RR in the RRset MUST have the RR type listed in the + RRSIG RR's Type Covered field; + + Each RR in the RRset MUST have the TTL listed in the + RRSIG Original TTL Field; + + Any DNS names in the RDATA field of each RR MUST be in + canonical form; and + + The RRset MUST be sorted in canonical order. + + See Sections 6.2 and 6.3 for details on canonical form and ordering + of RRsets. + +3.2. The RRSIG RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Type Covered field is represented as an RR type mnemonic. When + the mnemonic is not known, the TYPE representation as described in + [RFC3597], Section 5, MUST be used. + + The Algorithm field value MUST be represented either as an unsigned + decimal integer or as an algorithm mnemonic, as specified in Appendix + A.1. + + The Labels field value MUST be represented as an unsigned decimal + integer. + + + + + +Arends, et al. Standards Track [Page 10] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The Original TTL field value MUST be represented as an unsigned + decimal integer. + + The Signature Expiration Time and Inception Time field values MUST be + represented either as an unsigned decimal integer indicating seconds + since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in + UTC, where: + + YYYY is the year (0001-9999, but see Section 3.1.5); + MM is the month number (01-12); + DD is the day of the month (01-31); + HH is the hour, in 24 hour notation (00-23); + mm is the minute (00-59); and + SS is the second (00-59). + + Note that it is always possible to distinguish between these two + formats because the YYYYMMDDHHmmSS format will always be exactly 14 + digits, while the decimal representation of a 32-bit unsigned integer + can never be longer than 10 digits. + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Signer's Name field value MUST be represented as a domain name. + + The Signature field is represented as a Base64 encoding of the + signature. Whitespace is allowed within the Base64 text. See + Section 2.2. + +3.3. RRSIG RR Example + + The following RRSIG RR stores the signature for the A RRset of + host.example.com: + + host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( + 20030220173103 2642 example.com. + oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr + PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o + B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t + GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG + J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) + + The first four fields specify the owner name, TTL, Class, and RR type + (RRSIG). The "A" represents the Type Covered field. The value 5 + identifies the algorithm used (RSA/SHA1) to create the signature. + The value 3 is the number of Labels in the original owner name. The + value 86400 in the RRSIG RDATA is the Original TTL for the covered A + RRset. 20030322173103 and 20030220173103 are the expiration and + + + + +Arends, et al. Standards Track [Page 11] + +RFC 4034 DNSSEC Resource Records March 2005 + + + inception dates, respectively. 2642 is the Key Tag, and example.com. + is the Signer's Name. The remaining text is a Base64 encoding of the + signature. + + Note that combination of RRSIG RR owner name, class, and Type Covered + indicates that this RRSIG covers the "host.example.com" A RRset. The + Label value of 3 indicates that no wildcard expansion was used. The + Algorithm, Signer's Name, and Key Tag indicate that this signature + can be authenticated using an example.com zone DNSKEY RR whose + algorithm is 5 and whose key tag is 2642. + +4. The NSEC Resource Record + + The NSEC resource record lists two separate things: the next owner + name (in the canonical ordering of the zone) that contains + authoritative data or a delegation point NS RRset, and the set of RR + types present at the NSEC RR's owner name [RFC3845]. The complete + set of NSEC RRs in a zone indicates which authoritative RRsets exist + in a zone and also form a chain of authoritative owner names in the + zone. This information is used to provide authenticated denial of + existence for DNS data, as described in [RFC4035]. + + Because every authoritative name in a zone must be part of the NSEC + chain, NSEC RRs must be present for names containing a CNAME RR. + This is a change to the traditional DNS specification [RFC1034], + which stated that if a CNAME is present for a name, it is the only + type allowed at that name. An RRSIG (see Section 3) and NSEC MUST + exist for the same name as does a CNAME resource record in a signed + zone. + + See [RFC4035] for discussion of how a zone signer determines + precisely which NSEC RRs it has to include in a zone. + + The type value for the NSEC RR is 47. + + The NSEC RR is class independent. + + The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching ([RFC2308]). + + + + + + + + + + + + +Arends, et al. Standards Track [Page 12] + +RFC 4034 DNSSEC Resource Records March 2005 + + +4.1. NSEC RDATA Wire Format + + The RDATA of the NSEC RR is as shown below: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Domain Name / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Maps / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +4.1.1. The Next Domain Name Field + + The Next Domain field contains the next owner name (in the canonical + ordering of the zone) that has authoritative data or contains a + delegation point NS RRset; see Section 6.1 for an explanation of + canonical ordering. The value of the Next Domain Name field in the + last NSEC record in the zone is the name of the zone apex (the owner + name of the zone's SOA RR). This indicates that the owner name of + the NSEC RR is the last name in the canonical ordering of the zone. + + A sender MUST NOT use DNS name compression on the Next Domain Name + field when transmitting an NSEC RR. + + Owner names of RRsets for which the given zone is not authoritative + (such as glue records) MUST NOT be listed in the Next Domain Name + unless at least one authoritative RRset exists at the same owner + name. + +4.1.2. The Type Bit Maps Field + + The Type Bit Maps field identifies the RRset types that exist at the + NSEC RR's owner name. + + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that + has at least one active RR type is encoded using a single octet + window number (from 0 to 255), a single octet bitmap length (from 1 + to 32) indicating the number of octets used for the window block's + bitmap, and up to 32 octets (256 bits) of bitmap. + + Blocks are present in the NSEC RR RDATA in increasing numerical + order. + + Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ + + where "|" denotes concatenation. + + + +Arends, et al. Standards Track [Page 13] + +RFC 4034 DNSSEC Resource Records March 2005 + + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, and bit 2 to RR type 258. If a bit is + set, it indicates that an RRset of that type is present for the NSEC + RR's owner name. If a bit is clear, it indicates that no RRset of + that type is present for the NSEC RR's owner name. + + Bits representing pseudo-types MUST be clear, as they do not appear + in zone data. If encountered, they MUST be ignored upon being read. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC RR's owner name. Trailing zero octets not specified MUST be + interpreted as zero octets. + + The bitmap for the NSEC RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and the RR + types for which the parent zone has authoritative data MUST be set; + bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be clear. + + A zone MUST NOT include an NSEC RR for any domain name that only + holds glue records. + +4.1.3. Inclusion of Wildcard Names in NSEC RDATA + + If a wildcard owner name appears in a zone, the wildcard label ("*") + is treated as a literal symbol and is treated the same as any other + owner name for the purposes of generating NSEC RRs. Wildcard owner + names appear in the Next Domain Name field without any wildcard + expansion. [RFC4035] describes the impact of wildcards on + authenticated denial of existence. + +4.2. The NSEC RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Next Domain Name field is represented as a domain name. + + The Type Bit Maps field is represented as a sequence of RR type + mnemonics. When the mnemonic is not known, the TYPE representation + described in [RFC3597], Section 5, MUST be used. + + + + + +Arends, et al. Standards Track [Page 14] + +RFC 4034 DNSSEC Resource Records March 2005 + + +4.3. NSEC RR Example + + The following NSEC RR identifies the RRsets associated with + alfa.example.com. and identifies the next authoritative name after + alfa.example.com. + + alfa.example.com. 86400 IN NSEC host.example.com. ( + A MX RRSIG NSEC TYPE1234 ) + + The first four text fields specify the name, TTL, Class, and RR type + (NSEC). The entry host.example.com. is the next authoritative name + after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, + and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC, + and TYPE1234 RRsets associated with the name alfa.example.com. + + The RDATA section of the NSEC RR above would be encoded as: + + 0x04 'h' 'o' 's' 't' + 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' + 0x03 'c' 'o' 'm' 0x00 + 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 + 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x20 + + Assuming that the validator can authenticate this NSEC record, it + could be used to prove that beta.example.com does not exist, or to + prove that there is no AAAA record associated with alfa.example.com. + Authenticated denial of existence is discussed in [RFC4035]. + +5. The DS Resource Record + + The DS Resource Record refers to a DNSKEY RR and is used in the DNS + DNSKEY authentication process. A DS RR refers to a DNSKEY RR by + storing the key tag, algorithm number, and a digest of the DNSKEY RR. + Note that while the digest should be sufficient to identify the + public key, storing the key tag and key algorithm helps make the + identification process more efficient. By authenticating the DS + record, a resolver can authenticate the DNSKEY RR to which the DS + record points. The key authentication process is described in + [RFC4035]. + + The DS RR and its corresponding DNSKEY RR have the same owner name, + but they are stored in different locations. The DS RR appears only + on the upper (parental) side of a delegation, and is authoritative + data in the parent zone. For example, the DS RR for "example.com" is + stored in the "com" zone (the parent zone) rather than in the + + + +Arends, et al. Standards Track [Page 15] + +RFC 4034 DNSSEC Resource Records March 2005 + + + "example.com" zone (the child zone). The corresponding DNSKEY RR is + stored in the "example.com" zone (the child zone). This simplifies + DNS zone management and zone signing but introduces special response + processing requirements for the DS RR; these are described in + [RFC4035]. + + The type number for the DS record is 43. + + The DS resource record is class independent. + + The DS RR has no special TTL requirements. + +5.1. DS RDATA Wire Format + + The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet + Algorithm field, a 1 octet Digest Type field, and a Digest field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | Algorithm | Digest Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Digest / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +5.1.1. The Key Tag Field + + The Key Tag field lists the key tag of the DNSKEY RR referred to by + the DS record, in network byte order. + + The Key Tag used by the DS RR is identical to the Key Tag used by + RRSIG RRs. Appendix B describes how to compute a Key Tag. + +5.1.2. The Algorithm Field + + The Algorithm field lists the algorithm number of the DNSKEY RR + referred to by the DS record. + + The algorithm number used by the DS RR is identical to the algorithm + number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the + algorithm number types. + + + + + + + + +Arends, et al. Standards Track [Page 16] + +RFC 4034 DNSSEC Resource Records March 2005 + + +5.1.3. The Digest Type Field + + The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY + RR. The Digest Type field identifies the algorithm used to construct + the digest. Appendix A.2 lists the possible digest algorithm types. + +5.1.4. The Digest Field + + The DS record refers to a DNSKEY RR by including a digest of that + DNSKEY RR. + + The digest is calculated by concatenating the canonical form of the + fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, + and then applying the digest algorithm. + + digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); + + "|" denotes concatenation + + DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. + + The size of the digest may vary depending on the digest algorithm and + DNSKEY RR size. As of the time of this writing, the only defined + digest algorithm is SHA-1, which produces a 20 octet digest. + +5.2. Processing of DS RRs When Validating Responses + + The DS RR links the authentication chain across zone boundaries, so + the DS RR requires extra care in processing. The DNSKEY RR referred + to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST + have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC + zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be + used in the validation process. + +5.3. The DS RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Algorithm field MUST be represented either as an unsigned decimal + integer or as an algorithm mnemonic specified in Appendix A.1. + + The Digest Type field MUST be represented as an unsigned decimal + integer. + + + + + + +Arends, et al. Standards Track [Page 17] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The Digest MUST be represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is allowed within the hexadecimal + text. + +5.4. DS RR Example + + The following example shows a DNSKEY RR and its corresponding DS RR. + + dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz + fwJr1AYtsmx3TGkJaNXVbfi/ + 2pHm822aJ5iI9BMzNXxeYCmZ + DRD99WYwYqUSdjMmmAphXdvx + egXd/M5+X7OrzKBaMbCVdFLU + Uh6DhweJBjEVv5f2wwjM9Xzc + nOf+EPbtG9DMBmADjFDc2w/r + ljwvFw== + ) ; key id = 60485 + + dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A + 98631FAD1A292118 ) + + The first four text fields specify the name, TTL, Class, and RR type + (DS). Value 60485 is the key tag for the corresponding + "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm + used by this "dskey.example.com." DNSKEY RR. The value 1 is the + algorithm used to construct the digest, and the rest of the RDATA + text is the digest in hexadecimal. + +6. Canonical Form and Order of Resource Records + + This section defines a canonical form for resource records, a + canonical ordering of DNS names, and a canonical ordering of resource + records within an RRset. A canonical name order is required to + construct the NSEC name chain. A canonical RR form and ordering + within an RRset are required in order to construct and verify RRSIG + RRs. + +6.1. Canonical DNS Name Order + + For the purposes of DNS security, owner names are ordered by treating + individual labels as unsigned left-justified octet strings. The + absence of a octet sorts before a zero value octet, and uppercase + US-ASCII letters are treated as if they were lowercase US-ASCII + letters. + + + + + + + +Arends, et al. Standards Track [Page 18] + +RFC 4034 DNSSEC Resource Records March 2005 + + + To compute the canonical ordering of a set of DNS names, start by + sorting the names according to their most significant (rightmost) + labels. For names in which the most significant label is identical, + continue sorting according to their next most significant label, and + so forth. + + For example, the following names are sorted in canonical DNS name + order. The most significant label is "example". At this level, + "example" sorts first, followed by names ending in "a.example", then + by names ending "z.example". The names within each level are sorted + in the same way. + + example + a.example + yljkjljk.a.example + Z.a.example + zABC.a.EXAMPLE + z.example + \001.z.example + *.z.example + \200.z.example + +6.2. Canonical RR Form + + For the purposes of DNS security, the canonical form of an RR is the + wire format of the RR where: + + 1. every domain name in the RR is fully expanded (no DNS name + compression) and fully qualified; + + 2. all uppercase US-ASCII letters in the owner name of the RR are + replaced by the corresponding lowercase US-ASCII letters; + + 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; + + 4. if the owner name of the RR is a wildcard name, the owner name is + in its original unexpanded form, including the "*" label (no + wildcard substitution); and + + 5. the RR's TTL is set to its original value as it appears in the + originating authoritative zone or the Original TTL field of the + covering RRSIG RR. + + + + + +Arends, et al. Standards Track [Page 19] + +RFC 4034 DNSSEC Resource Records March 2005 + + +6.3. Canonical RR Ordering within an RRset + + For the purposes of DNS security, RRs with the same owner name, + class, and type are sorted by treating the RDATA portion of the + canonical form of each RR as a left-justified unsigned octet sequence + in which the absence of an octet sorts before a zero octet. + + [RFC2181] specifies that an RRset is not allowed to contain duplicate + records (multiple RRs with the same owner name, class, type, and + RDATA). Therefore, if an implementation detects duplicate RRs when + putting the RRset in canonical form, it MUST treat this as a protocol + error. If the implementation chooses to handle this protocol error + in the spirit of the robustness principle (being liberal in what it + accepts), it MUST remove all but one of the duplicate RR(s) for the + purposes of calculating the canonical form of the RRset. + +7. IANA Considerations + + This document introduces no new IANA considerations, as all of the + protocol parameters used in this document have already been assigned + by previous specifications. However, since the evolution of DNSSEC + has been long and somewhat convoluted, this section attempts to + describe the current state of the IANA registries and other protocol + parameters that are (or once were) related to DNSSEC. + + Please refer to [RFC4035] for additional IANA considerations. + + DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to + the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS + Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, + and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. + [RFC3755] also marked type 30 (NXT) as Obsolete and restricted use + of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction + security protocol described in [RFC2931] and to the transaction + KEY Resource Record described in [RFC2930]. + + DNS Security Algorithm Numbers: [RFC2535] created an IANA registry + for DNSSEC Resource Record Algorithm field numbers and assigned + values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] + altered this registry to include flags for each entry regarding + its use with the DNS security extensions. Each algorithm entry + could refer to an algorithm that can be used for zone signing, + transaction security (see [RFC2931]), or both. Values 6-251 are + available for assignment by IETF standards action ([RFC3755]). + See Appendix A for a full listing of the DNS Security Algorithm + Numbers entries at the time of this writing and their status for + use in DNSSEC. + + + + +Arends, et al. Standards Track [Page 20] + +RFC 4034 DNSSEC Resource Records March 2005 + + + [RFC3658] created an IANA registry for DNSSEC DS Digest Types and + assigned value 0 to reserved and value 1 to SHA-1. + + KEY Protocol Values: [RFC2535] created an IANA Registry for KEY + Protocol Values, but [RFC3445] reassigned all values other than 3 + to reserved and closed this IANA registry. The registry remains + closed, and all KEY and DNSKEY records are required to have a + Protocol Octet value of 3. + + Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA + registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, + this registry only contains assignments for bit 7 (the ZONE bit) + and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]). + As stated in [RFC3755], bits 0-6 and 8-14 are available for + assignment by IETF Standards Action. + +8. Security Considerations + + This document describes the format of four DNS resource records used + by the DNS security extensions and presents an algorithm for + calculating a key tag for a public key. Other than the items + described below, the resource records themselves introduce no + security considerations. Please see [RFC4033] and [RFC4035] for + additional security considerations related to the use of these + records. + + The DS record points to a DNSKEY RR by using a cryptographic digest, + the key algorithm type, and a key tag. The DS record is intended to + identify an existing DNSKEY RR, but it is theoretically possible for + an attacker to generate a DNSKEY that matches all the DS fields. The + probability of constructing a matching DNSKEY depends on the type of + digest algorithm in use. The only currently defined digest algorithm + is SHA-1, and the working group believes that constructing a public + key that would match the algorithm, key tag, and SHA-1 digest given + in a DS record would be a sufficiently difficult problem that such an + attack is not a serious threat at this time. + + The key tag is used to help select DNSKEY resource records + efficiently, but it does not uniquely identify a single DNSKEY + resource record. It is possible for two distinct DNSKEY RRs to have + the same owner name, the same algorithm type, and the same key tag. + An implementation that uses only the key tag to select a DNSKEY RR + might select the wrong public key in some circumstances. Please see + Appendix B for further details. + + + + + + + +Arends, et al. Standards Track [Page 21] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The table of algorithms in Appendix A and the key tag calculation + algorithms in Appendix B include the RSA/MD5 algorithm for + completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as + explained in [RFC3110]. + +9. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. Although explicitly listing everyone who has + contributed during the decade in which DNSSEC has been under + development would be impossible, [RFC4033] includes a list of some of + the participants who were kind enough to comment on these documents. + +10. References + +10.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name + System (DNS)", RFC 2536, March 1999. + + [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures + ( SIG(0)s )", RFC 2931, September 2000. + + [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the + Domain Name System (DNS)", RFC 3110, May 2001. + + + + + +Arends, et al. Standards Track [Page 22] + +RFC 4034 DNSSEC Resource Records March 2005 + + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + + [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 3548, July 2003. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer (DS)", RFC 3755, May 2004. + + [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name + System KEY (DNSKEY) Resource Record (RR) Secure Entry + Point (SEP) Flag", RFC 3757, April 2004. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC + 4033, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + +10.2. Informative References + + [RFC2535] Eastlake 3rd, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. + + [RFC2537] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain + Name System (DNS)", RFC 2537, March 1999. + + [RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the + Domain Name System (DNS)", RFC 2539, March 1999. + + [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) + RDATA Format", RFC 3845, August 2004. + + + + + + + + +Arends, et al. Standards Track [Page 23] + +RFC 4034 DNSSEC Resource Records March 2005 + + +Appendix A. DNSSEC Algorithm and Digest Types + + The DNS security extensions are designed to be independent of the + underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS + resource records all use a DNSSEC Algorithm Number to identify the + cryptographic algorithm in use by the resource record. The DS + resource record also specifies a Digest Algorithm Number to identify + the digest algorithm used to construct the DS record. The currently + defined Algorithm and Digest Types are listed below. Additional + Algorithm or Digest Types could be added as advances in cryptography + warrant them. + + A DNSSEC aware resolver or name server MUST implement all MANDATORY + algorithms. + +A.1. DNSSEC Algorithm Types + + The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the + security algorithm being used. These values are stored in the + "Algorithm number" field in the resource record RDATA. + + Some algorithms are usable only for zone signing (DNSSEC), some only + for transaction security mechanisms (SIG(0) and TSIG), and some for + both. Those usable for zone signing may appear in DNSKEY, RRSIG, and + DS RRs. Those usable for transaction security would be present in + SIG(0) and KEY RRs, as described in [RFC2931]. + + Zone + Value Algorithm [Mnemonic] Signing References Status + ----- -------------------- --------- ---------- --------- + 0 reserved + 1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED + 2 Diffie-Hellman [DH] n [RFC2539] - + 3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL + 4 Elliptic Curve [ECC] TBA - + 5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY + 252 Indirect [INDIRECT] n - + 253 Private [PRIVATEDNS] y see below OPTIONAL + 254 Private [PRIVATEOID] y see below OPTIONAL + 255 reserved + + 6 - 251 Available for assignment by IETF Standards Action. + + + + + + + + + +Arends, et al. Standards Track [Page 24] + +RFC 4034 DNSSEC Resource Records March 2005 + + +A.1.1. Private Algorithm Types + + Algorithm number 253 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with a wire encoded + domain name, which MUST NOT be compressed. The domain name indicates + the private algorithm to use, and the remainder of the public key + area is determined by that algorithm. Entities should only use + domain names they control to designate their private algorithms. + + Algorithm number 254 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with an unsigned + length byte followed by a BER encoded Object Identifier (ISO OID) of + that length. The OID indicates the private algorithm in use, and the + remainder of the area is whatever is required by that algorithm. + Entities should only use OIDs they control to designate their private + algorithms. + +A.2. DNSSEC Digest Types + + A "Digest Type" field in the DS resource record types identifies the + cryptographic digest algorithm used by the resource record. The + following table lists the currently defined digest algorithm types. + + VALUE Algorithm STATUS + 0 Reserved - + 1 SHA-1 MANDATORY + 2-255 Unassigned - + +Appendix B. Key Tag Calculation + + The Key Tag field in the RRSIG and DS resource record types provides + a mechanism for selecting a public key efficiently. In most cases, a + combination of owner name, algorithm, and key tag can efficiently + identify a DNSKEY record. Both the RRSIG and DS resource records + have corresponding DNSKEY records. The Key Tag field in the RRSIG + and DS records can be used to help select the corresponding DNSKEY RR + efficiently when more than one candidate DNSKEY RR is available. + + However, it is essential to note that the key tag is not a unique + identifier. It is theoretically possible for two distinct DNSKEY RRs + to have the same owner name, the same algorithm, and the same key + tag. The key tag is used to limit the possible candidate keys, but + it does not uniquely identify a DNSKEY record. Implementations MUST + NOT assume that the key tag uniquely identifies a DNSKEY RR. + + + + + +Arends, et al. Standards Track [Page 25] + +RFC 4034 DNSSEC Resource Records March 2005 + + + 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. + + A reference implementation of the key tag algorithm is as an ANSI C + function is given below, with the RDATA portion of the DNSKEY RR is + used as input. It is not necessary to use the following reference + code verbatim, but the numerical value of the Key Tag MUST be + identical to what the reference implementation would generate for the + same input. + + Please note that the algorithm for calculating the Key Tag is almost + but not completely identical to the familiar ones-complement checksum + used in many other Internet protocols. Key Tags MUST be calculated + using the algorithm described here rather than the ones complement + checksum. + + The following ANSI C reference implementation calculates the value of + a Key Tag. This reference implementation applies to all algorithm + types except algorithm 1 (see Appendix B.1). The input is the wire + format of the RDATA portion of the DNSKEY RR. The code is written + for clarity, not efficiency. + + /* + * Assumes that int is at least 16 bits. + * First octet of the key tag is the most significant 8 bits of the + * return value; + * Second octet of the key tag is the least significant 8 bits of the + * return value. + */ + + unsigned int + keytag ( + unsigned char key[], /* the RDATA part of the DNSKEY RR */ + unsigned int keysize /* the RDLENGTH */ + ) + { + unsigned long ac; /* assumed to be 32 bits or larger */ + int i; /* loop index */ + + for ( ac = 0, i = 0; i < keysize; ++i ) + ac += (i & 1) ? key[i] : key[i] << 8; + ac += (ac >> 16) & 0xFFFF; + return ac & 0xFFFF; + } + + + +Arends, et al. Standards Track [Page 26] + +RFC 4034 DNSSEC Resource Records March 2005 + + +B.1. Key Tag for Algorithm 1 (RSA/MD5) + + The key tag for algorithm 1 (RSA/MD5) is defined differently from the + key tag for all other algorithms, for historical reasons. 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). + + Please note that Algorithm 1 is NOT RECOMMENDED. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Standards Track [Page 27] + +RFC 4034 DNSSEC Resource Records March 2005 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + Colorado State University + Department of Computer Science + Fort Collins, CO 80523-1873 + + EMail: massey@cs.colostate.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + +Arends, et al. Standards Track [Page 28] + +RFC 4034 DNSSEC Resource Records March 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Arends, et al. Standards Track [Page 29] + |