contrib/bind9/doc/rfc/rfc4034.txt

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