Network Working Group                                          R. ArendsRequest for Comments: 4034                          Telematica InstituutObsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein           3755, 3757, 3845                                          ISCUpdates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson         3007, 3597, 3226                                       VeriSignCategory: Standards Track                                      D. Massey                                               Colorado State University                                                                 S. Rose                                                                    NIST                                                              March 2005            Resource Records for the DNS Security ExtensionsStatus 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 2005Table 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. . . . . . . . . . . . . . . . . . . 21Arends, 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 . . . . . . . . . . . . . . . . . . . . 291.  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 20052.  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 onlyArends, 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.12.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.