contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-04.txt

   1
   2
   3
   4 Network Working Group                                          B. Laurie
   5 Internet-Draft                                                 G. Sisson
   6 Expires: August 5, 2006                                        R. Arends
   7                                                                  Nominet
   8                                                            February 2006
   9
  10
  11              DNSSEC Hash Authenticated Denial of Existence
  12                        draft-ietf-dnsext-nsec3-04
  13
  14 Status of this Memo
  15
  16    By submitting this Internet-Draft, each author represents that any
  17    applicable patent or other IPR claims of which he or she is aware
  18    have been or will be disclosed, and any of which he or she becomes
  19    aware will be disclosed, in accordance with Section 6 of BCP 79.
  20
  21    Internet-Drafts are working documents of the Internet Engineering
  22    Task Force (IETF), its areas, and its working groups.  Note that
  23    other groups may also distribute working documents as Internet-
  24    Drafts.
  25
  26    Internet-Drafts are draft documents valid for a maximum of six months
  27    and may be updated, replaced, or obsoleted by other documents at any
  28    time.  It is inappropriate to use Internet-Drafts as reference
  29    material or to cite them other than as "work in progress."
  30
  31    The list of current Internet-Drafts can be accessed at
  32    http://www.ietf.org/ietf/1id-abstracts.txt.
  33
  34    The list of Internet-Draft Shadow Directories can be accessed at
  35    http://www.ietf.org/shadow.html.
  36
  37    This Internet-Draft will expire on August 5, 2006.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The Internet Society (2006).
  42
  43 Abstract
  44
  45    The DNS Security Extensions introduces the NSEC resource record for
  46    authenticated denial of existence.  This document introduces a new
  47    resource record as an alternative to NSEC that provides measures
  48    against zone enumeration and allows for gradual expansion of
  49    delegation-centric zones.
  50
  51
  52
  53
  54
  55 Laurie, et al.           Expires August 5, 2006                 [Page 1]
  56 \f
  57 Internet-Draft                    nsec3                    February 2006
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
  63      1.1.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . .  4
  64      1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  4
  65      1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
  66    2.  NSEC versus NSEC3  . . . . . . . . . . . . . . . . . . . . . .  5
  67    3.  The NSEC3 Resource Record  . . . . . . . . . . . . . . . . . .  5
  68      3.1.  NSEC3 RDATA Wire Format  . . . . . . . . . . . . . . . . .  6
  69        3.1.1.  The Hash Function Field  . . . . . . . . . . . . . . .  6
  70        3.1.2.  The Opt-In Flag Field  . . . . . . . . . . . . . . . .  7
  71        3.1.3.  The Iterations Field . . . . . . . . . . . . . . . . .  8
  72        3.1.4.  The Salt Length Field  . . . . . . . . . . . . . . . .  8
  73        3.1.5.  The Salt Field . . . . . . . . . . . . . . . . . . . .  8
  74        3.1.6.  The Next Hashed Ownername Field  . . . . . . . . . . .  9
  75        3.1.7.  The Type Bit Maps Field  . . . . . . . . . . . . . . .  9
  76      3.2.  The NSEC3 RR Presentation Format . . . . . . . . . . . . . 10
  77    4.  Creating Additional NSEC3 RRs for Empty Non-Terminals  . . . . 11
  78    5.  Calculation of the Hash  . . . . . . . . . . . . . . . . . . . 11
  79    6.  Including NSEC3 RRs in a Zone  . . . . . . . . . . . . . . . . 11
  80    7.  Responding to NSEC3 Queries  . . . . . . . . . . . . . . . . . 12
  81    8.  Special Considerations . . . . . . . . . . . . . . . . . . . . 13
  82      8.1.  Proving Nonexistence . . . . . . . . . . . . . . . . . . . 13
  83      8.2.  Salting  . . . . . . . . . . . . . . . . . . . . . . . . . 14
  84      8.3.  Iterations . . . . . . . . . . . . . . . . . . . . . . . . 15
  85      8.4.  Hash Collision . . . . . . . . . . . . . . . . . . . . . . 16
  86        8.4.1.  Avoiding Hash Collisions during generation . . . . . . 16
  87        8.4.2.  Second Preimage Requirement Analysis . . . . . . . . . 16
  88        8.4.3.  Possible Hash Value Truncation Method  . . . . . . . . 17
  89        8.4.4.  Server Response to a Run-time Collision  . . . . . . . 17
  90        8.4.5.  Parameters that Cover the Zone . . . . . . . . . . . . 18
  91    9.  Performance Considerations . . . . . . . . . . . . . . . . . . 18
  92    10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
  93    11. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
  94    12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
  95      12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
  96      12.2. Informative References . . . . . . . . . . . . . . . . . . 22
  97    Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
  98    Appendix A.  Example Zone  . . . . . . . . . . . . . . . . . . . . 22
  99    Appendix B.  Example Responses . . . . . . . . . . . . . . . . . . 27
 100      B.1.  answer . . . . . . . . . . . . . . . . . . . . . . . . . . 27
 101        B.1.1.  Authenticating the Example DNSKEY RRset  . . . . . . . 29
 102      B.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . . 30
 103      B.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . . 32
 104        B.3.1.  No Data Error, Empty Non-Terminal  . . . . . . . . . . 33
 105      B.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . . 34
 106      B.5.  Referral to Unsigned Zone using the Opt-In Flag  . . . . . 35
 107      B.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 36
 108
 109
 110
 111 Laurie, et al.           Expires August 5, 2006                 [Page 2]
 112 \f
 113 Internet-Draft                    nsec3                    February 2006
 114
 115
 116      B.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . . 38
 117      B.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . . 39
 118    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
 119    Intellectual Property and Copyright Statements . . . . . . . . . . 42
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167 Laurie, et al.           Expires August 5, 2006                 [Page 3]
 168 \f
 169 Internet-Draft                    nsec3                    February 2006
 170
 171
 172 1.  Introduction
 173
 174 1.1.  Rationale
 175
 176    The DNS Security Extensions included the NSEC RR to provide
 177    authenticated denial of existence.  Though the NSEC RR meets the
 178    requirements for authenticated denial of existence, it introduced a
 179    side-effect in that the contents of a zone can be enumerated.  This
 180    property introduces undesired policy issues.
 181
 182    An enumerated zone can be used either directly as a source of
 183    probable e-mail addresses for spam, or indirectly as a key for
 184    multiple WHOIS queries to reveal registrant data which many
 185    registries may be under strict legal obligations to protect.  Many
 186    registries therefore prohibit copying of their zone file; however the
 187    use of NSEC RRs renders these policies unenforceable.
 188
 189    A second problem was the requirement that the existence of all record
 190    types in a zone - including unsigned delegation points - must be
 191    accounted for, despite the fact that unsigned delegation point
 192    records are not signed.  This requirement has a side-effect that the
 193    overhead of signed zones is not related to the increase in security
 194    of subzones.  This requirement does not allow the zones' size to grow
 195    in relation to the growth of signed subzones.
 196
 197    In the past, solutions (draft-ietf-dnsext-dnssec-opt-in) have been
 198    proposed as a measure against these side effects but at the time were
 199    regarded as secondary over the need to have a stable DNSSEC
 200    specification.  With (draft-vixie-dnssec-ter) [14] a graceful
 201    transition path to future enhancements is introduced, while current
 202    DNSSEC deployment can continue.  This document presents the NSEC3
 203    Resource Record which mitigates these issues with the NSEC RR.
 204
 205    The reader is assumed to be familiar with the basic DNS and DNSSEC
 206    concepts described in RFC 1034 [1], RFC 1035 [2], RFC 4033 [3], RFC
 207    4034 [4], RFC 4035 [5] and subsequent RFCs that update them: RFC 2136
 208    [6], RFC2181 [7] and RFC2308 [8].
 209
 210 1.2.  Reserved Words
 211
 212    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 213    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 214    document are to be interpreted as described in RFC 2119 [9].
 215
 216 1.3.  Terminology
 217
 218    The practice of discovering the contents of a zone, i.e. enumerating
 219    the domains within a zone, is known as "zone enumeration".  Zone
 220
 221
 222
 223 Laurie, et al.           Expires August 5, 2006                 [Page 4]
 224 \f
 225 Internet-Draft                    nsec3                    February 2006
 226
 227
 228    enumeration was not practical prior to the introduction of DNSSEC.
 229
 230    In this document the term "original ownername" refers to a standard
 231    ownername.  Because this proposal uses the result of a hash function
 232    over the original (unmodified) ownername, this result is referred to
 233    as "hashed ownername".
 234
 235    "Hash order" means the order in which hashed ownernames are arranged
 236    according to their numerical value, treating the leftmost (lowest
 237    numbered) octet as the most significant octet.  Note that this is the
 238    same as the canonical ordering specified in RFC 4034 [4].
 239
 240    An "empty non-terminal" is a domain name that owns no resource
 241    records but has subdomains that do.
 242
 243    The "closest encloser" of a (nonexistent) domain name is the longest
 244    domain name, including empty non-terminals, that matches the
 245    rightmost part of the nonexistent domain name.
 246
 247    "Base32 encoding" is "Base 32 Encoding with Extended Hex Alphabet" as
 248    specified in RFC 3548bis [15].
 249
 250
 251 2.  NSEC versus NSEC3
 252
 253    This document does NOT obsolete the NSEC record, but gives an
 254    alternative for authenticated denial of existence.  NSEC and NSEC3
 255    RRs can not co-exist in a zone.  See draft-vixie-dnssec-ter [14] for
 256    a signaling mechanism to allow for graceful transition towards NSEC3.
 257
 258
 259 3.  The NSEC3 Resource Record
 260
 261    The NSEC3 RR provides Authenticated Denial of Existence for DNS
 262    Resource Record Sets.
 263
 264    The NSEC3 Resource Record (RR) lists RR types present at the NSEC3
 265    RR's original ownername.  It includes the next hashed ownername in
 266    the hash order of the zone.  The complete set of NSEC3 RRs in a zone
 267    indicates which RRsets exist for the original ownername of the RRset
 268    and form a chain of hashed ownernames in the zone.  This information
 269    is used to provide authenticated denial of existence for DNS data, as
 270    described in RFC 4035 [5].  To provide protection against zone
 271    enumeration, the ownernames used in the NSEC3 RR are cryptographic
 272    hashes of the original ownername prepended to the name of the zone.
 273    The NSEC3 RR indicates which hash function is used to construct the
 274    hash, which salt is used, and how many iterations of the hash
 275    function are performed over the original ownername.  The hashing
 276
 277
 278
 279 Laurie, et al.           Expires August 5, 2006                 [Page 5]
 280 \f
 281 Internet-Draft                    nsec3                    February 2006
 282
 283
 284    technique is described fully in Section 5.
 285
 286    Hashed ownernames of unsigned delegations may be excluded from the
 287    chain.  An NSEC3 record which span covers the hash of an unsigned
 288    delegation's ownername is referred to as an Opt-In NSEC3 record and
 289    is indicated by the presence of a flag.
 290
 291    The ownername for the NSEC3 RR is the base32 encoding of the hashed
 292    ownername prepended to the name of the zone..
 293
 294    The type value for the NSEC3 RR is XX.
 295
 296    The NSEC3 RR RDATA format is class independent and is described
 297    below.
 298
 299    The class MUST be the same as the original ownername's class.
 300
 301    The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
 302    field.  This is in the spirit of negative caching [8].
 303
 304 3.1.  NSEC3 RDATA Wire Format
 305
 306    The RDATA of the NSEC3 RR is as shown below:
 307
 308                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 309     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
 310    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 311    | Hash Function |O|                Iterations                   |
 312    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 313    |  Salt Length  |                     Salt                      /
 314    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 315    /                     Next Hashed Ownername                     /
 316    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 317    /                         Type Bit Maps                         /
 318    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 319
 320    "O" is the Opt-In Flag field.
 321
 322 3.1.1.  The Hash Function Field
 323
 324    The Hash Function field identifies the cryptographic hash function
 325    used to construct the hash-value.
 326
 327    The values are as defined for the DS record (see RFC 3658 [10]).
 328
 329    On reception, a resolver MUST ignore an NSEC3 RR with an unknown hash
 330    function value.
 331
 332
 333
 334
 335 Laurie, et al.           Expires August 5, 2006                 [Page 6]
 336 \f
 337 Internet-Draft                    nsec3                    February 2006
 338
 339
 340 3.1.2.  The Opt-In Flag Field
 341
 342    The Opt-In Flag field indicates whether this NSEC3 RR covers unsigned
 343    delegations.
 344
 345    In DNSSEC, NS RRsets at delegation points are not signed, and may be
 346    accompanied by a DS record.  The security status of the subzone is
 347    determined by the presence or absence of the DS RRset,
 348    cryptographically proven by the NSEC record or the signed DS RRset.
 349    The presence of the Opt-In flag expands this definition by allowing
 350    insecure delegations to exist within an otherwise signed zone without
 351    the corresponding NSEC3 record at the delegation's (hashed) owner
 352    name.  These delegations are proven insecure by using a covering
 353    NSEC3 record.
 354
 355    Resolvers must be able to distinguish between NSEC3 records and
 356    Opt-In NSEC3 records.  This is accomplished by setting the Opt-In
 357    flag of the NSEC3 records that cover (or potentially cover) insecure
 358    delegation nodes.
 359
 360    An Opt-In NSEC3 record does not assert the existence or non-existence
 361    of the insecure delegations that it covers.  This allows for the
 362    addition or removal of these delegations without recalculating or
 363    resigning records in the NSEC3 chain.  However, Opt-In NSEC3 records
 364    do assert the (non)existence of other, authoritative RRsets.
 365
 366    An Opt-In NSEC3 record MAY have the same original owner name as an
 367    insecure delegation.  In this case, the delegation is proven insecure
 368    by the lack of a DS bit in type map and the signed NSEC3 record does
 369    assert the existence of the delegation.
 370
 371    Zones using Opt-In MAY contain a mixture of Opt-In NSEC3 records and
 372    non-Opt-In NSEC3 records.  If an NSEC3 record is not Opt-In, there
 373    MUST NOT be any hashed ownernames of insecure delegations (nor any
 374    other records) between it and the RRsets indicated by the 'Next
 375    Hashed Ownername' in the NSEC3 RDATA.  If it is Opt-In, there MUST
 376    only be hashed ownernames of insecure delegations between it and the
 377    next node indicated by the 'Next Hashed Ownername' in the NSEC3
 378    RDATA.
 379
 380    In summary,
 381    o  An Opt-In NSEC3 type is identified by an Opt-In Flag field value
 382       of 1.
 383    o  A non Opt-In NSEC3 type is identified by an Opt-In Flag field
 384       value of 0.
 385    and,
 386
 387
 388
 389
 390
 391 Laurie, et al.           Expires August 5, 2006                 [Page 7]
 392 \f
 393 Internet-Draft                    nsec3                    February 2006
 394
 395
 396    o  An Opt-In NSEC3 record does not assert the non-existence of a hash
 397       ownername between its ownername and next hashed ownername,
 398       although it does assert that any hashed name in this span MUST be
 399       of an insecure delegation.
 400    o  An Opt-In NSEC3 record does assert the (non)existence of RRsets
 401       with the same hashed owner name.
 402
 403 3.1.3.  The Iterations Field
 404
 405    The Iterations field defines the number of times the hash has been
 406    iterated.  More iterations results in greater resiliency of the hash
 407    value against dictionary attacks, but at a higher cost for both the
 408    server and resolver.  See Section 5 for details of this field's use.
 409
 410    Iterations make an attack more costly by making the hash computation
 411    more computationally intensive, e.g. by iterating the hash function a
 412    number of times.
 413
 414    When generating a few hashes this performance loss will not be a
 415    problem, as a validator can handle a delay of a few milliseconds.
 416    But when doing a dictionary attack it will also multiply the attack
 417    workload by a factor, which is a problem for the attacker.
 418
 419 3.1.4.  The Salt Length Field
 420
 421    The salt length field defines the length of the salt in octets.
 422
 423 3.1.5.  The Salt Field
 424
 425    The Salt field is not present when the Salt Length Field has a value
 426    of 0.
 427
 428    The Salt field is appended to the original ownername before hashing
 429    in order to defend against precalculated dictionary attacks.  See
 430    Section 5 for details on how the salt is used.
 431
 432    Salt is used to make dictionary attacks using precomputation more
 433    costly.  A dictionary can only be computed after the attacker has the
 434    salt, hence a new salt means that the dictionary has to be
 435    regenerated with the new salt.
 436
 437    There MUST be a complete set of NSEC3 records covering the entire
 438    zone that use the same salt value.  The requirement exists so that,
 439    given any qname within a zone, at least one covering NSEC3 RRset may
 440    be found.  While it may be theoretically possible to produce a set of
 441    NSEC3s that use different salts that cover the entire zone, it is
 442    computationally infeasible to generate such a set.  See Section 8.2
 443    for further discussion.
 444
 445
 446
 447 Laurie, et al.           Expires August 5, 2006                 [Page 8]
 448 \f
 449 Internet-Draft                    nsec3                    February 2006
 450
 451
 452    The salt value SHOULD be changed from time to time - this is to
 453    prevent the use of a precomputed dictionary to reduce the cost of
 454    enumeration.
 455
 456 3.1.6.  The Next Hashed Ownername Field
 457
 458    The Next Hashed Ownername field contains the next hashed ownername in
 459    hash order.  That is, given the set of all hashed owernames, the Next
 460    Hashed Ownername contains the hash value that immediately follows the
 461    owner hash value for the given NSEC3 record.  The value of the Next
 462    Hashed Ownername Field in the last NSEC3 record in the zone is the
 463    same as the ownername of the first NSEC3 RR in the zone in hash
 464    order.
 465
 466    Hashed ownernames of glue RRsets MUST NOT be listed in the Next
 467    Hashed Ownername unless at least one authoritative RRset exists at
 468    the same ownername.  Hashed ownernames of delegation NS RRsets MUST
 469    be listed if the Opt-In bit is clear.
 470
 471    Note that the Next Hashed Ownername field is not encoded, unlike the
 472    NSEC3 RR's ownername.  It is the unmodified binary hash value.  It
 473    does not include the name of the containing zone.
 474
 475    The length of this field is the length of the hash value produced by
 476    the hash function selected by the Hash Function field.
 477
 478 3.1.7.  The Type Bit Maps Field
 479
 480    The Type Bit Maps field identifies the RRset types which exist at the
 481    NSEC3 RR's original ownername.
 482
 483    The Type bits for the NSEC3 RR and RRSIG RR MUST be set during
 484    generation, and MUST be ignored during processing.
 485
 486    The RR type space is split into 256 window blocks, each representing
 487    the low-order 8 bits of the 16-bit RR type space.  Each block that
 488    has at least one active RR type is encoded using a single octet
 489    window number (from 0 to 255), a single octet bitmap length (from 1
 490    to 32) indicating the number of octets used for the window block's
 491    bitmap, and up to 32 octets (256 bits) of bitmap.
 492
 493    Blocks are present in the NSEC3 RR RDATA in increasing numerical
 494    order.
 495
 496    "|" denotes concatenation
 497
 498    Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
 499
 500
 501
 502
 503 Laurie, et al.           Expires August 5, 2006                 [Page 9]
 504 \f
 505 Internet-Draft                    nsec3                    February 2006
 506
 507
 508    Each bitmap encodes the low-order 8 bits of RR types within the
 509    window block, in network bit order.  The first bit is bit 0.  For
 510    window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
 511    to RR type 2 (NS), and so forth.  For window block 1, bit 1
 512    corresponds to RR type 257, bit 2 to RR type 258.  If a bit is set to
 513    1, it indicates that an RRset of that type is present for the NSEC3
 514    RR's ownername.  If a bit is set to 0, it indicates that no RRset of
 515    that type is present for the NSEC3 RR's ownername.
 516
 517    Since bit 0 in window block 0 refers to the non-existing RR type 0,
 518    it MUST be set to 0.  After verification, the validator MUST ignore
 519    the value of bit 0 in window block 0.
 520
 521    Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [11]
 522    (section 3.1) or within the range reserved for assignment only to
 523    QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
 524    zone data.  If encountered, they must be ignored upon reading.
 525
 526    Blocks with no types present MUST NOT be included.  Trailing zero
 527    octets in the bitmap MUST be omitted.  The length of each block's
 528    bitmap is determined by the type code with the largest numerical
 529    value, within that block, among the set of RR types present at the
 530    NSEC3 RR's actual ownername.  Trailing zero octets not specified MUST
 531    be interpreted as zero octets.
 532
 533 3.2.  The NSEC3 RR Presentation Format
 534
 535    The presentation format of the RDATA portion is as follows:
 536
 537    The Opt-In Flag Field is represented as an unsigned decimal integer.
 538    The value is either 0 or 1.
 539
 540    The Hash field is presented as a mnemonic of the hash or as an
 541    unsigned decimal integer.  The value has a maximum of 127.
 542
 543    The Iterations field is presented as an unsigned decimal integer.
 544
 545    The Salt Length field is not presented.
 546
 547    The Salt field is represented as a sequence of case-insensitive
 548    hexadecimal digits.  Whitespace is not allowed within the sequence.
 549    The Salt Field is represented as "-" (without the quotes) when the
 550    Salt Length field has value 0.
 551
 552    The Next Hashed Ownername field is represented as a sequence of case-
 553    insensitive base32 digits, without whitespace.
 554
 555    The Type Bit Maps Field is represented as a sequence of RR type
 556
 557
 558
 559 Laurie, et al.           Expires August 5, 2006                [Page 10]
 560 \f
 561 Internet-Draft                    nsec3                    February 2006
 562
 563
 564    mnemonics.  When the mnemonic is not known, the TYPE representation
 565    as described in RFC 3597 [12] (section 5) MUST be used.
 566
 567
 568 4.  Creating Additional NSEC3 RRs for Empty Non-Terminals
 569
 570    In order to prove the non-existence of a record that might be covered
 571    by a wildcard, it is necessary to prove the existence of its closest
 572    encloser.  A closest encloser might be an empty non-terminal.
 573
 574    Additional NSEC3 RRs are generated for empty non-terminals.  These
 575    additional NSEC3 RRs are identical in format to NSEC3 RRs that cover
 576    existing RRs in the zone except that their type-maps only indicated
 577    the existence of an NSEC3 RRset and an RRSIG RRset.
 578
 579    This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs
 580    not appear at names that did not exist before the zone was signed.
 581    [Comment.1]
 582
 583
 584 5.  Calculation of the Hash
 585
 586    Define H(x) to be the hash of x using the hash function selected by
 587    the NSEC3 record and || to indicate concatenation.  Then define:
 588
 589    IH(salt,x,0)=H(x || salt)
 590
 591    IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0
 592
 593    Then the calculated hash of an ownername is
 594    IH(salt,ownername,iterations-1), where the ownername is the canonical
 595    form.
 596
 597    The canonical form of the ownername is the wire format of the
 598    ownername where:
 599    1.  The ownername is fully expanded (no DNS name compression) and
 600        fully qualified;
 601    2.  All uppercase US-ASCII letters are replaced by the corresponding
 602        lowercase US-ASCII letters;
 603    3.  If the ownername is a wildcard name, the ownername is in its
 604        original unexpanded form, including the "*" label (no wildcard
 605        substitution);
 606    This form is as defined in section 6.2 of RFC 4034 ([4]).
 607
 608
 609 6.  Including NSEC3 RRs in a Zone
 610
 611    Each ownername within the zone that owns authoritative RRsets MUST
 612
 613
 614
 615 Laurie, et al.           Expires August 5, 2006                [Page 11]
 616 \f
 617 Internet-Draft                    nsec3                    February 2006
 618
 619
 620    have a corresponding NSEC3 RR.  Ownernames that correspond to
 621    unsigned delegations MAY have a corresponding NSEC3 RR, however, if
 622    there is not, there MUST be a covering NSEC3 RR with the Opt-In flag
 623    set to 1.  Other non-authoritative RRs are not included in the set of
 624    NSEC3 RRs.
 625
 626    Each empty non-terminal MUST have an NSEC3 record.
 627
 628    The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL
 629    value field in the zone SOA RR.
 630
 631    The type bitmap of every NSEC3 resource record in a signed zone MUST
 632    indicate the presence of both the NSEC3 RR type itself and its
 633    corresponding RRSIG RR type.
 634
 635    The following steps describe the proper construction of NSEC3
 636    records.  [Comment.2]
 637    1.  For each unique original ownername in the zone, add an NSEC3
 638        RRset.  If Opt-In is being used, ownernames of unsigned
 639        delegations may be excluded, but must be considered for empty-
 640        non-terminals.  The ownername of the NSEC3 RR is the hashed
 641        equivalent of the original owner name, prepended to the zone
 642        name.  The Next Hashed Ownername field is left blank for the
 643        moment.  If Opt-In is being used, set the Opt-In bit to one.
 644    2.  For each RRset at the original owner name, set the corresponding
 645        bit in the type bit map.
 646    3.  If the difference in number of labels between the apex and the
 647        original ownername is greater then 1, additional NSEC3s need to
 648        be added for every empty non-terminal between the apex and the
 649        original ownername.  This process may generate NSEC3 RRs with
 650        duplicate hashed ownernames.
 651    4.  Sort the set of NSEC3 RRs into hash order.  Hash order is the
 652        ascending numerical order of the non-encoded hash values.
 653    5.  Combine NSEC3 RRs with identical hashed ownernames by replacing
 654        with a single NSEC3 RR with the type map consisting of the union
 655        of the types represented by the set of NSEC3 RRs.
 656    6.  In each NSEC3 RR, insert the Next Hashed Ownername by using the
 657        value of the next NSEC3 RR in hash order.  The Next Hashed
 658        Ownername of the last NSEC3 in the zone contains the value of the
 659        hashed ownername of the first NSEC3 in the hash order.
 660
 661
 662 7.  Responding to NSEC3 Queries
 663
 664    Since NSEC3 ownernames are not represented in the NSEC3 chain like
 665    other zone ownernames, direct queries for NSEC3 ownernames present a
 666    special case.
 667
 668
 669
 670
 671 Laurie, et al.           Expires August 5, 2006                [Page 12]
 672 \f
 673 Internet-Draft                    nsec3                    February 2006
 674
 675
 676    The special case arises when the following are all true:
 677    o  The QNAME equals an existing NSEC3 ownername, and
 678    o  There are no other record types that exist at QNAME, and
 679    o  The QTYPE does not equal NSEC3.
 680    These conditions describe a particular case: the answer should be a
 681    NOERROR/NODATA response, but there is no NSEC3 RRset for H(QNAME) to
 682    include in the authority section.
 683
 684    However, the NSEC3 RRset with ownername equal to QNAME is able to
 685    prove its own existence.  Thus, when answering this query, the
 686    authoritative server MUST include the NSEC3 RRset whose ownername
 687    equals QNAME.  This RRset proves that QNAME is an existing name with
 688    types NSEC3 and RRSIG.  The authoritative server MUST also include
 689    the NSEC3 RRset that covers the hash of QNAME.  This RRset proves
 690    that no other types exist.
 691
 692    When validating a NOERROR/NODATA response, validators MUST check for
 693    a NSEC3 RRset with ownername equals to QNAME, and MUST accept that
 694    (validated) NSEC3 RRset as proof that QNAME exists.  The validator
 695    MUST also check for an NSEC3 RRset that covers the hash of QNAME as
 696    proof that QTYPE doesn't exist.
 697
 698    Other cases where the QNAME equals an existing NSEC3 ownername may be
 699    answered normally.
 700
 701
 702 8.  Special Considerations
 703
 704    The following paragraphs clarify specific behaviour explain special
 705    considerations for implementations.
 706
 707 8.1.  Proving Nonexistence
 708
 709    If a wildcard resource record appears in a zone, its asterisk label
 710    is treated as a literal symbol and is treated in the same way as any
 711    other ownername for purposes of generating NSEC3 RRs.  RFC 4035 [5]
 712    describes the impact of wildcards on authenticated denial of
 713    existence.
 714
 715    In order to prove there exist no RRs for a domain, as well as no
 716    source of synthesis, an RR must be shown for the closest encloser,
 717    and non-existence must be shown for all closer labels and for the
 718    wildcard at the closest encloser.
 719
 720    This can be done as follows.  If the QNAME in the query is
 721    omega.alfa.beta.example, and the closest encloser is beta.example
 722    (the nearest ancestor to omega.alfa.beta.example), then the server
 723    should return an NSEC3 that demonstrates the nonexistence of
 724
 725
 726
 727 Laurie, et al.           Expires August 5, 2006                [Page 13]
 728 \f
 729 Internet-Draft                    nsec3                    February 2006
 730
 731
 732    alfa.beta.example, an NSEC3 that demonstrates the nonexistence of
 733    *.beta.example, and an NSEC3 that demonstrates the existence of
 734    beta.example.  This takes between one and three NSEC3 records, since
 735    a single record can, by chance, prove more than one of these facts.
 736
 737    When a verifier checks this response, then the existence of
 738    beta.example together with the non-existence of alfa.beta.example
 739    proves that the closest encloser is indeed beta.example.  The non-
 740    existence of *.beta.example shows that there is no wildcard at the
 741    closest encloser, and so no source of synthesis for
 742    omega.alfa.beta.example.  These two facts are sufficient to satisfy
 743    the resolver that the QNAME cannot be resolved.
 744
 745    In practice, since the NSEC3 owner and next names are hashed, if the
 746    server responds with an NSEC3 for beta.example, the resolver will
 747    have to try successively longer names, starting with example, moving
 748    to beta.example, alfa.beta.example, and so on, until one of them
 749    hashes to a value that matches the interval (but not the ownername
 750    nor next owner name) of one of the returned NSEC3s (this name will be
 751    alfa.beta.example).  Once it has done this, it knows the closest
 752    encloser (i.e. beta.example), and can then easily check the other two
 753    required proofs.
 754
 755    Note that it is not possible for one of the shorter names tried by
 756    the resolver to be denied by one of the returned NSEC3s, since, by
 757    definition, all these names exist and so cannot appear within the
 758    range covered by an NSEC3.  Note, however, that the first name that
 759    the resolver tries MUST be the apex of the zone, since names above
 760    the apex could be denied by one of the returned NSEC3s.
 761
 762 8.2.  Salting
 763
 764    Augmenting original ownernames with salt before hashing increases the
 765    cost of a dictionary of pre-generated hash-values.  For every bit of
 766    salt, the cost of a precomputed dictionary doubles (because there
 767    must be an entry for each word combined with each possible salt
 768    value).  The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
 769    salt, multiplying the cost by 2^2040.  This means that an attacker
 770    must, in practice, recompute the dictionary each time the salt is
 771    changed.
 772
 773    There MUST be at least one complete set of NSEC3s for the zone using
 774    the same salt value.
 775
 776    The salt SHOULD be changed periodically to prevent precomputation
 777    using a single salt.  It is RECOMMENDED that the salt be changed for
 778    every resigning.
 779
 780
 781
 782
 783 Laurie, et al.           Expires August 5, 2006                [Page 14]
 784 \f
 785 Internet-Draft                    nsec3                    February 2006
 786
 787
 788    Note that this could cause a resolver to see records with different
 789    salt values for the same zone.  This is harmless, since each record
 790    stands alone (that is, it denies the set of ownernames whose hashes,
 791    using the salt in the NSEC3 record, fall between the two hashes in
 792    the NSEC3 record) - it is only the server that needs a complete set
 793    of NSEC3 records with the same salt in order to be able to answer
 794    every possible query.
 795
 796    There is no prohibition with having NSEC3 with different salts within
 797    the same zone.  However, in order for authoritative servers to be
 798    able to consistently find covering NSEC3 RRs, the authoritative
 799    server MUST choose a single set of parameters (algorithm, salt, and
 800    iterations) to use when selecting NSEC3s.  In the absence of any
 801    other metadata, the server does this by using the parameters from the
 802    zone apex NSEC3, recognizable by the presence of the SOA bit in the
 803    type map.  If there is more than one NSEC3 record that meets this
 804    description, then the server may arbitrarily choose one.  Because of
 805    this, if there is a zone apex NSEC3 RR within a zone, it MUST be part
 806    of a complete NSEC3 set.  Conversely, if there exists an incomplete
 807    set of NSEC3 RRs using the same parameters within a zone, there MUST
 808    NOT be an NSEC3 RR using those parameters with the SOA bit set.
 809
 810 8.3.  Iterations
 811
 812    Setting the number of iterations used allows the zone owner to choose
 813    the cost of computing a hash, and so the cost of generating a
 814    dictionary.  Note that this is distinct from the effect of salt,
 815    which prevents the use of a single precomputed dictionary for all
 816    time.
 817
 818    Obviously the number of iterations also affects the zone owner's cost
 819    of signing the zone as well as the verifiers cost of verifying the
 820    zone.  We therefore impose an upper limit on the number of
 821    iterations.  We base this on the number of iterations that
 822    approximately doubles the cost of signing the zone.
 823
 824    A zone owner MUST NOT use a value higher than shown in the table
 825    below for iterations.  A resolver MAY treat a response with a higher
 826    value as bogus.
 827
 828                        +--------------+------------+
 829                        | RSA Key Size | Iterations |
 830                        +--------------+------------+
 831                        | 1024         | 3,000      |
 832                        | 2048         | 20,000     |
 833                        | 4096         | 150,000    |
 834                        +--------------+------------+
 835
 836
 837
 838
 839 Laurie, et al.           Expires August 5, 2006                [Page 15]
 840 \f
 841 Internet-Draft                    nsec3                    February 2006
 842
 843
 844                        +--------------+------------+
 845                        | DSA Key Size | Iterations |
 846                        +--------------+------------+
 847                        | 1024         | 1,500      |
 848                        | 2048         | 5,000      |
 849                        +--------------+------------+
 850
 851    This table is based on 150,000 SHA-1's per second, 50 RSA signs per
 852    second for 1024 bit keys, 7 signs per second for 2048 bit keys, 1
 853    sign per second for 4096 bit keys, 100 DSA signs per second for 1024
 854    bit keys and 30 signs per second for 2048 bit keys.
 855
 856    Note that since RSA verifications are 10-100 times faster than
 857    signatures (depending on key size), in the case of RSA the legal
 858    values of iterations can substantially increase the cost of
 859    verification.
 860
 861 8.4.  Hash Collision
 862
 863    Hash collisions occur when different messages have the same hash
 864    value.  The expected number of domain names needed to give a 1 in 2
 865    chance of a single collision is about 2^(n/2) for a hash of length n
 866    bits (i.e. 2^80 for SHA-1).  Though this probability is extremely
 867    low, the following paragraphs deal with avoiding collisions and
 868    assessing possible damage in the event of an attack using hash
 869    collisions.
 870
 871 8.4.1.  Avoiding Hash Collisions during generation
 872
 873    During generation of NSEC3 RRs, hash values are supposedly unique.
 874    In the (academic) case of a collision occurring, an alternative salt
 875    MUST be chosen and all hash values MUST be regenerated.
 876
 877 8.4.2.  Second Preimage Requirement Analysis
 878
 879    A cryptographic hash function has a second-preimage resistance
 880    property.  The second-preimage resistance property means that it is
 881    computationally infeasible to find another message with the same hash
 882    value as a given message, i.e. given preimage X, to find a second
 883    preimage X' != X such that hash(X) = hash(X').  The work factor for
 884    finding a second preimage is of the order of 2^160 for SHA-1.  To
 885    mount an attack using an existing NSEC3 RR, an adversary needs to
 886    find a second preimage.
 887
 888    Assuming an adversary is capable of mounting such an extreme attack,
 889    the actual damage is that a response message can be generated which
 890    claims that a certain QNAME (i.e. the second pre-image) does exist,
 891    while in reality QNAME does not exist (a false positive), which will
 892
 893
 894
 895 Laurie, et al.           Expires August 5, 2006                [Page 16]
 896 \f
 897 Internet-Draft                    nsec3                    February 2006
 898
 899
 900    either cause a security aware resolver to re-query for the non-
 901    existent name, or to fail the initial query.  Note that the adversary
 902    can't mount this attack on an existing name but only on a name that
 903    the adversary can't choose and does not yet exist.
 904
 905 8.4.3.  Possible Hash Value Truncation Method
 906
 907    The previous sections outlined the low probability and low impact of
 908    a second-preimage attack.  When impact and probability are low, while
 909    space in a DNS message is costly, truncation is tempting.  Truncation
 910    might be considered to allow for shorter ownernames and rdata for
 911    hashed labels.  In general, if a cryptographic hash is truncated to n
 912    bits, then the expected number of domains required to give a 1 in 2
 913    probability of a single collision is approximately 2^(n/2) and the
 914    work factor to produce a second preimage is 2^n.
 915
 916    An extreme hash value truncation would be truncating to the shortest
 917    possible unique label value.  This would be unwise, since the work
 918    factor to produce second preimages would then approximate the size of
 919    the zone (sketch of proof: if the zone has k entries, then the length
 920    of the names when truncated down to uniqueness should be proportional
 921    to log_2(k).  Since the work factor to produce a second pre-image is
 922    2^n for an n-bit hash, then in this case it is 2^(C log_2(k)) (where
 923    C is some constant), i.e.  C'k - a work factor of k).
 924
 925    Though the mentioned truncation can be maximized to a certain
 926    extreme, the probability of collision increases exponentially for
 927    every truncated bit.  Given the low impact of hash value collisions
 928    and limited space in DNS messages, the balance between truncation
 929    profit and collision damage may be determined by local policy.  Of
 930    course, the size of the corresponding RRSIG RR is not reduced, so
 931    truncation is of limited benefit.
 932
 933    Truncation could be signaled simply by reducing the length of the
 934    first label in the ownername.  Note that there would have to be a
 935    corresponding reduction in the length of the Next Hashed Ownername
 936    field.
 937
 938 8.4.4.  Server Response to a Run-time Collision
 939
 940    In the astronomically unlikely event that a server is unable to prove
 941    nonexistence because the hash of the name that does not exist
 942    collides with a name that does exist, the server is obviously broken,
 943    and should, therefore, return a response with an RCODE of 2 (server
 944    failure).
 945
 946
 947
 948
 949
 950
 951 Laurie, et al.           Expires August 5, 2006                [Page 17]
 952 \f
 953 Internet-Draft                    nsec3                    February 2006
 954
 955
 956 8.4.5.  Parameters that Cover the Zone
 957
 958    Secondary servers (and perhaps other entities) need to reliably
 959    determine which NSEC3 parameters (that is, hash, salt and iterations)
 960    are present at every hashed ownername, in order to be able to choose
 961    an appropriate set of NSEC3 records for negative responses.  This is
 962    indicated by the parameters at the apex: any set of parameters that
 963    is used in an NSEC3 record whose original ownername is the apex of
 964    the zone MUST be present throughout the zone.
 965
 966    A method to determine which NSEC3 in a complete chain corresponds to
 967    the apex is to look for a NSEC3 RRset which has the SOA bit set in
 968    the RDATA bit type maps field.
 969
 970
 971 9.  Performance Considerations
 972
 973    Iterated hashes impose a performance penalty on both authoritative
 974    servers and resolvers.  Therefore, the number of iterations should be
 975    carefully chosen.  In particular it should be noted that a high value
 976    for iterations gives an attacker a very good denial of service
 977    attack, since the attacker need not bother to verify the results of
 978    their queries, and hence has no performance penalty of his own.
 979
 980    On the other hand, nameservers with low query rates and limited
 981    bandwidth are already subject to a bandwidth based denial of service
 982    attack, since responses are typically an order of magnitude larger
 983    than queries, and hence these servers may choose a high value of
 984    iterations in order to increase the difficulty of offline attempts to
 985    enumerate their namespace without significantly increasing their
 986    vulnerability to denial of service attacks.
 987
 988
 989 10.  IANA Considerations
 990
 991    IANA needs to allocate a RR type code for NSEC3 from the standard RR
 992    type space (type XXX requested).  IANA needs to open a new registry
 993    for the NSEC3 Hash Functions.  The range for this registry is 0-127.
 994    Defined types are:
 995
 996       0 is reserved.
 997       1 is SHA-1 ([13]).
 998       127 is experimental.
 999
1000
1001 11.  Security Considerations
1002
1003    The NSEC3 records are still susceptible to dictionary attacks (i.e.
1004
1005
1006
1007 Laurie, et al.           Expires August 5, 2006                [Page 18]
1008 \f
1009 Internet-Draft                    nsec3                    February 2006
1010
1011
1012    the attacker retrieves all the NSEC3 records, then calculates the
1013    hashes of all likely domain names, comparing against the hashes found
1014    in the NSEC3 records, and thus enumerating the zone).  These are
1015    substantially more expensive than enumerating the original NSEC
1016    records would have been, and in any case, such an attack could also
1017    be used directly against the name server itself by performing queries
1018    for all likely names, though this would obviously be more detectable.
1019    The expense of this off-line attack can be chosen by setting the
1020    number of iterations in the NSEC3 RR.
1021
1022    Domains are also susceptible to a precalculated dictionary attack -
1023    that is, a list of hashes for all likely names is computed once, then
1024    NSEC3 is scanned periodically and compared against the precomputed
1025    hashes.  This attack is prevented by changing the salt on a regular
1026    basis.
1027
1028    Walking the NSEC3 RRs will reveal the total number of records in the
1029    zone, and also what types they are.  This could be mitigated by
1030    adding dummy entries, but certainly an upper limit can always be
1031    found.
1032
1033    Hash collisions may occur.  If they do, it will be impossible to
1034    prove the non-existence of the colliding domain - however, this is
1035    fantastically unlikely, and, in any case, DNSSEC already relies on
1036    SHA-1 to not collide.
1037
1038    Responses to queries where QNAME equals an NSEC3 ownername that has
1039    no other types may be undetectably changed from a NOERROR/NODATA
1040    response to a NAME ERROR response.
1041
1042    The Opt-In Flag (O) allows for unsigned names, in the form of
1043    delegations to unsigned subzones, to exist within an otherwise signed
1044    zone.  All unsigned names are, by definition, insecure, and their
1045    validity or existence cannot by cryptographically proven.
1046
1047    In general:
1048       Records with unsigned names (whether existing or not) suffer from
1049       the same vulnerabilities as records in an unsigned zone.  These
1050       vulnerabilities are described in more detail in [16] (note in
1051       particular sections 2.3, "Name Games" and 2.6, "Authenticated
1052       Denial").
1053       Records with signed names have the same security whether or not
1054       Opt-In is used.
1055
1056    Note that with or without Opt-In, an insecure delegation may be
1057    undetectably altered by an attacker.  Because of this, the primary
1058    difference in security when using Opt-In is the loss of the ability
1059    to prove the existence or nonexistence of an insecure delegation
1060
1061
1062
1063 Laurie, et al.           Expires August 5, 2006                [Page 19]
1064 \f
1065 Internet-Draft                    nsec3                    February 2006
1066
1067
1068    within the span of an Opt-In NSEC3 record.
1069
1070    In particular, this means that a malicious entity may be able to
1071    insert or delete records with unsigned names.  These records are
1072    normally NS records, but this also includes signed wildcard
1073    expansions (while the wildcard record itself is signed, its expanded
1074    name is an unsigned name).
1075
1076    For example, if a resolver received the following response from the
1077    example zone above:
1078
1079    Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
1080
1081            RCODE=NOERROR
1082
1083            Answer Section:
1084
1085            Authority Section:
1086            DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
1087            EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
1088                                           RRSIG DNSKEY
1089            abcd...                 RRSIG  NSEC3 ...
1090
1091            Additional Section:
1092
1093    The resolver would have no choice but to accept that the referral to
1094    NS.FORGED. is valid.  If a wildcard existed that would have been
1095    expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
1096    have undetectably removed it and replaced it with the forged
1097    delegation.
1098
1099    Note that being able to add a delegation is functionally equivalent
1100    to being able to add any record type: an attacker merely has to forge
1101    a delegation to nameserver under his/her control and place whatever
1102    records needed at the subzone apex.
1103
1104    While in particular cases, this issue may not present a significant
1105    security problem, in general it should not be lightly dismissed.
1106    Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
1107    In particular, zone signing tools SHOULD NOT default to using Opt-In,
1108    and MAY choose to not support Opt-In at all.
1109
1110
1111 12.  References
1112
1113
1114
1115
1116
1117
1118
1119 Laurie, et al.           Expires August 5, 2006                [Page 20]
1120 \f
1121 Internet-Draft                    nsec3                    February 2006
1122
1123
1124 12.1.  Normative References
1125
1126    [1]   Mockapetris, P., "Domain names - concepts and facilities",
1127          STD 13, RFC 1034, November 1987.
1128
1129    [2]   Mockapetris, P., "Domain names - implementation and
1130          specification", STD 13, RFC 1035, November 1987.
1131
1132    [3]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
1133          "DNS Security Introduction and Requirements", RFC 4033,
1134          March 2005.
1135
1136    [4]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
1137          "Resource Records for the DNS Security Extensions", RFC 4034,
1138          March 2005.
1139
1140    [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
1141          "Protocol Modifications for the DNS Security Extensions",
1142          RFC 4035, March 2005.
1143
1144    [6]   Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
1145          Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
1146          April 1997.
1147
1148    [7]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
1149          RFC 2181, July 1997.
1150
1151    [8]   Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
1152          RFC 2308, March 1998.
1153
1154    [9]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
1155          Levels", BCP 14, RFC 2119, March 1997.
1156
1157    [10]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
1158          RFC 3658, December 2003.
1159
1160    [11]  Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain
1161          Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
1162          September 2000.
1163
1164    [12]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
1165          Types", RFC 3597, September 2003.
1166
1167    [13]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
1168          RFC 3174, September 2001.
1169
1170
1171
1172
1173
1174
1175 Laurie, et al.           Expires August 5, 2006                [Page 21]
1176 \f
1177 Internet-Draft                    nsec3                    February 2006
1178
1179
1180 12.2.  Informative References
1181
1182    [14]  Vixie, P., "Extending DNSSEC-BIS (DNSSEC-TER)",
1183          draft-vixie-dnssec-ter-01 (work in progress), June 2004.
1184
1185    [15]  Josefsson, Ed., S,., "The Base16, Base32, and Base64 Data
1186          Encodings.", draft-josefsson-rfc3548bis-00 (work in progress),
1187          October 2005.
1188
1189    [16]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
1190          System (DNS)", RFC 3833, August 2004.
1191
1192 Editorial Comments
1193
1194    [Comment.1]  Although, strictly speaking, the names *did* exist.
1195
1196    [Comment.2]  Note that this method makes it impossible to detect
1197                 (extremely unlikely) hash collisions.
1198
1199
1200 Appendix A.  Example Zone
1201
1202    This is a zone showing its NSEC3 records.  They can also be used as
1203    test vectors for the hash algorithm.
1204
1205    The data in the example zone is currently broken, as it uses a
1206    different base32 alphabet.  This shall be fixed in the next release.
1207
1208
1209    example.       3600 IN SOA ns1.example. bugs.x.w.example. (
1210                               1
1211                               3600
1212                               300
1213                               3600000
1214                               3600 )
1215                   3600 RRSIG  SOA 5 1 3600 20050712112304 (
1216                               20050612112304 62699 example.
1217                               RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
1218                               mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
1219                               qYIt90txzE/4+g== )
1220                   3600 NS     ns1.example.
1221                   3600 NS     ns2.example.
1222                   3600 RRSIG  NS 5 1 3600 20050712112304 (
1223                               20050612112304 62699 example.
1224                               hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
1225                               m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
1226                               1SH5r/wfjuCg+g== )
1227                   3600 MX     1 xx.example.
1228
1229
1230
1231 Laurie, et al.           Expires August 5, 2006                [Page 22]
1232 \f
1233 Internet-Draft                    nsec3                    February 2006
1234
1235
1236                   3600 RRSIG  MX 5 1 3600 20050712112304 (
1237                               20050612112304 62699 example.
1238                               L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l
1239                               NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU
1240                               S/o/g5C8VM6ftQ== )
1241                   3600 DNSKEY 257 3 5 (
1242                               AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX
1243                               cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1
1244                               zsYKWJ7BvR2894hX
1245                               ) ; Key ID = 21960
1246                   3600 DNSKEY 256 3 5 (
1247                               AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU
1248                               5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL
1249                               ExXT48OGGdbfIme5
1250                               ) ; Key ID = 62699
1251                   3600 RRSIG  DNSKEY 5 1 3600 20050712112304 (
1252                               20050612112304 62699 example.
1253                               e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z
1254                               xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx
1255                               mTkunTYzqWJrmQ== )
1256                   3600 RRSIG  DNSKEY 5 1 3600 20050712112304 (
1257                               20050612112304 21960 example.
1258                               SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk
1259                               ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik
1260                               3w7ZY2UWyYIvpw== )
1261    5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3  0 1 1 (
1262                               deadbeaf
1263                               7nomf47k3vlidh4vxahhpp47l3tgv7a2
1264                               NSEC3 RRSIG )
1265                   3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
1266                               20050612112304 62699 example.
1267                               PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5
1268                               Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ
1269                               sb7KfbaUo/vzAg== )
1270    7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3  0 1 1 (
1271                               deadbeaf
1272                               dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
1273                               MX NSEC3 RRSIG )
1274                   3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
1275                               20050612112304 62699 example.
1276                               YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
1277                               ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
1278                               MEFQmc/gEuxojA== )
1279    a.example.     3600 IN NS  ns1.a.example.
1280                   3600 IN NS  ns2.a.example.
1281                   3600 DS     58470 5 1 3079F1593EBAD6DC121E202A8B
1282                               766A6A4837206C )
1283                   3600 RRSIG  DS 5 2 3600 20050712112304 (
1284
1285
1286
1287 Laurie, et al.           Expires August 5, 2006                [Page 23]
1288 \f
1289 Internet-Draft                    nsec3                    February 2006
1290
1291
1292                               20050612112304 62699 example.
1293                               QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
1294                               cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
1295                               0kx7rGKTc3RQDA== )
1296    ns1.a.example. 3600 IN A   192.0.2.5
1297    ns2.a.example. 3600 IN A   192.0.2.6
1298    ai.example.    3600 IN A   192.0.2.9
1299                   3600 RRSIG  A 5 2 3600 20050712112304 (
1300                               20050612112304 62699 example.
1301                               plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
1302                               6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
1303                               ZXW5S+1VjMZYzQ== )
1304                   3600 HINFO  "KLH-10" "ITS"
1305                   3600 RRSIG  HINFO 5 2 3600 20050712112304 (
1306                               20050612112304 62699 example.
1307                               AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk
1308                               tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg
1309                               VGNmbgPnqDVPiA== )
1310                   3600 AAAA   2001:db8:0:0:0:0:f00:baa9
1311                   3600 RRSIG  AAAA 5 2 3600 20050712112304 (
1312                               20050612112304 62699 example.
1313                               PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
1314                               ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
1315                               l5/UqLCJJ9BDMg== )
1316    b.example.     3600 IN NS  ns1.b.example.
1317                   3600 IN NS  ns2.b.example.
1318    ns1.b.example. 3600 IN A   192.0.2.7
1319    ns2.b.example. 3600 IN A   192.0.2.8
1320    dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3  0 1 1 (
1321                               deadbeaf
1322                               gmnfcccja7wkax3iv26bs75myptje3qk
1323                               MX DNSKEY NS SOA NSEC3 RRSIG )
1324                   3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
1325                               20050612112304 62699 example.
1326                               VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
1327                               C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
1328                               MOiKMSHozVebqw== )
1329    gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3  0 1 1 (
1330                               deadbeaf
1331                               jt4bbfokgbmr57qx4nqucvvn7fmo6ab6
1332                               DS NS NSEC3 RRSIG )
1333                   3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
1334                               20050612112304 62699 example.
1335                               ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/
1336                               ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW
1337                               OwQBGbOegrW/Zw== )
1338    jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3  0 1 1 (
1339                               deadbeaf
1340
1341
1342
1343 Laurie, et al.           Expires August 5, 2006                [Page 24]
1344 \f
1345 Internet-Draft                    nsec3                    February 2006
1346
1347
1348                               kcll7fqfnisuhfekckeeqnmbbd4maanu
1349                               NSEC3 RRSIG )
1350                   3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
1351                               20050612112304 62699 example.
1352                               FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
1353                               IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
1354                               94Zbq3k8lgdpZA== )
1355    kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3  1 1 1 (
1356                               deadbeaf
1357                               n42hbhnjj333xdxeybycax5ufvntux5d
1358                               MX NSEC3 RRSIG )
1359                   3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
1360                               20050612112304 62699 example.
1361                               d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
1362                               IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
1363                               TOLtc5jPrkL4zQ== )
1364    n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3  0 1 1 (
1365                               deadbeaf
1366                               nimwfwcnbeoodmsc6npv3vuaagaevxxu
1367                               A NSEC3 RRSIG )
1368                   3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
1369                               20050612112304 62699 example.
1370                               MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy
1371                               91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj
1372                               xFPFGRIW3wKnrA== )
1373    nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3  0 1 1 (
1374                               deadbeaf
1375                               vhgwr2qgykdkf4m6iv6vkagbxozphazr
1376                               HINFO A AAAA NSEC3 RRSIG )
1377                   3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
1378                               20050612112304 62699 example.
1379                               c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
1380                               z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
1381                               jL33Wm1p07TBdw== )
1382    ns1.example.   3600 A      192.0.2.1
1383                   3600 RRSIG  A 5 2 3600 20050712112304 (
1384                               20050612112304 62699 example.
1385                               QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
1386                               BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
1387                               nWWLepz1PjjShQ== )
1388    ns2.example.   3600 A      192.0.2.2
1389                   3600 RRSIG  A 5 2 3600 20050712112304 (
1390                               20050612112304 62699 example.
1391                               UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
1392                               P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
1393                               AkeTJu3J3auUiA== )
1394    vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3  0 1 1 (
1395                               deadbeaf
1396
1397
1398
1399 Laurie, et al.           Expires August 5, 2006                [Page 25]
1400 \f
1401 Internet-Draft                    nsec3                    February 2006
1402
1403
1404                               wbyijvpnyj33pcpi3i44ecnibnaj7eiw
1405                               HINFO A AAAA NSEC3 RRSIG )
1406                   3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
1407                               20050612112304 62699 example.
1408                               leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W
1409                               kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M
1410                               5SNSHIyfpfsi6A== )
1411    *.w.example.   3600 MX     1 ai.example.
1412                   3600 RRSIG  MX 5 3 3600 20050712112304 (
1413                               20050612112304 62699 example.
1414                               sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
1415                               xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
1416                               gQlgxEwhvQDEaQ== )
1417    x.w.example.   3600 MX     1 xx.example.
1418                   3600 RRSIG  MX 5 3 3600 20050712112304 (
1419                               20050612112304 62699 example.
1420                               s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
1421                               lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
1422                               U9VazOa1KEIq1w== )
1423    x.y.w.example. 3600 MX     1 xx.example.
1424                   3600 RRSIG  MX 5 4 3600 20050712112304 (
1425                               20050612112304 62699 example.
1426                               aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7
1427                               uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF
1428                               9VrQvJjwbllAfA== )
1429    wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3  0 1 1 (
1430                               deadbeaf
1431                               zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
1432                               A NSEC3 RRSIG )
1433                   3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
1434                               20050612112304 62699 example.
1435                               ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
1436                               ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
1437                               oorBv4xkb0flXw== )
1438    xx.example.    3600 A      192.0.2.10
1439                   3600 RRSIG  A 5 2 3600 20050712112304 (
1440                               20050612112304 62699 example.
1441                               XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
1442                               tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
1443                               cxwCXWj82GVGdw== )
1444                   3600 HINFO  "KLH-10" "TOPS-20"
1445                   3600 RRSIG  HINFO 5 2 3600 20050712112304 (
1446                               20050612112304 62699 example.
1447                               ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q
1448                               OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk
1449                               KMf4DgNBDj+dIQ== )
1450                   3600 AAAA   2001:db8:0:0:0:0:f00:baaa
1451                   3600 RRSIG  AAAA 5 2 3600 20050712112304 (
1452
1453
1454
1455 Laurie, et al.           Expires August 5, 2006                [Page 26]
1456 \f
1457 Internet-Draft                    nsec3                    February 2006
1458
1459
1460                               20050612112304 62699 example.
1461                               rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
1462                               w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
1463                               rzKKwb8J04/ILw== )
1464    zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3  0 1 1 (
1465                               deadbeaf
1466                               5pe7ctl7pfs2cilroy5dcofx4rcnlypd
1467                               MX NSEC3 RRSIG )
1468                   3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
1469                               20050612112304 62699 example.
1470                               eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
1471                               7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
1472                               OcFlrPGPMm48/A== )
1473
1474
1475 Appendix B.  Example Responses
1476
1477    The examples in this section show response messages using the signed
1478    zone example in Appendix A.
1479
1480 B.1.  answer
1481
1482    A successful query to an authoritative server.
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 Laurie, et al.           Expires August 5, 2006                [Page 27]
1512 \f
1513 Internet-Draft                    nsec3                    February 2006
1514
1515
1516    ;; Header: QR AA DO RCODE=0
1517    ;;
1518    ;; Question
1519    x.w.example.        IN MX
1520
1521    ;; Answer
1522    x.w.example.   3600 IN MX  1 xx.example.
1523    x.w.example.   3600 IN RRSIG  MX 5 3 3600 20050712112304 (
1524                               20050612112304 62699 example.
1525                               s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
1526                               lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
1527                               U9VazOa1KEIq1w== )
1528
1529    ;; Authority
1530    example.       3600 IN NS  ns1.example.
1531    example.       3600 IN NS  ns2.example.
1532    example.       3600 IN RRSIG  NS 5 1 3600 20050712112304 (
1533                               20050612112304 62699 example.
1534                               hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
1535                               m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
1536                               1SH5r/wfjuCg+g== )
1537
1538    ;; Additional
1539    xx.example.    3600 IN A   192.0.2.10
1540    xx.example.    3600 IN RRSIG  A 5 2 3600 20050712112304 (
1541                               20050612112304 62699 example.
1542                               XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
1543                               tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
1544                               cxwCXWj82GVGdw== )
1545    xx.example.    3600 IN AAAA   2001:db8::f00:baaa
1546    xx.example.    3600 IN RRSIG  AAAA 5 2 3600 20050712112304 (
1547                               20050612112304 62699 example.
1548                               rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
1549                               w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
1550                               rzKKwb8J04/ILw== )
1551    ns1.example.   3600 IN A   192.0.2.1
1552    ns1.example.   3600 IN RRSIG  A 5 2 3600 20050712112304 (
1553                               20050612112304 62699 example.
1554                               QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
1555                               BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
1556                               nWWLepz1PjjShQ== )
1557    ns2.example.   3600 IN A   192.0.2.2
1558    ns2.example.   3600 IN RRSIG  A 5 2 3600 20050712112304 (
1559                               20050612112304 62699 example.
1560                               UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
1561                               P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
1562                               AkeTJu3J3auUiA== )
1563
1564
1565
1566
1567 Laurie, et al.           Expires August 5, 2006                [Page 28]
1568 \f
1569 Internet-Draft                    nsec3                    February 2006
1570
1571
1572    The query returned an MX RRset for "x.w.example".  The corresponding
1573    RRSIG RR indicates that the MX RRset was signed by an "example"
1574    DNSKEY with algorithm 5 and key tag 62699.  The resolver needs the
1575    corresponding DNSKEY RR in order to authenticate this answer.  The
1576    discussion below describes how a resolver might obtain this DNSKEY
1577    RR.
1578
1579    The RRSIG RR indicates the original TTL of the MX RRset was 3600,
1580    and, for the purpose of authentication, the current TTL is replaced
1581    by 3600.  The RRSIG RR's labels field value of 3 indicates that the
1582    answer was not the result of wildcard expansion.  The "x.w.example"
1583    MX RRset is placed in canonical form, and, assuming the current time
1584    falls between the signature inception and expiration dates, the
1585    signature is authenticated.
1586
1587 B.1.1.  Authenticating the Example DNSKEY RRset
1588
1589    This example shows the logical authentication process that starts
1590    from a configured root DNSKEY RRset (or DS RRset) and moves down the
1591    tree to authenticate the desired "example" DNSKEY RRset.  Note that
1592    the logical order is presented for clarity.  An implementation may
1593    choose to construct the authentication as referrals are received or
1594    to construct the authentication chain only after all RRsets have been
1595    obtained, or in any other combination it sees fit.  The example here
1596    demonstrates only the logical process and does not dictate any
1597    implementation rules.
1598
1599    We assume the resolver starts with a configured DNSKEY RRset for the
1600    root zone (or a configured DS RRset for the root zone).  The resolver
1601    checks whether this configured DNSKEY RRset is present in the root
1602    DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY
1603    RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the
1604    root DNSKEY RRset, and whether the signature lifetime is valid.  If
1605    all these conditions are met, all keys in the DNSKEY RRset are
1606    considered authenticated.  The resolver then uses one (or more) of
1607    the root DNSKEY RRs to authenticate the "example" DS RRset.  Note
1608    that the resolver may have to query the root zone to obtain the root
1609    DNSKEY RRset or "example" DS RRset.
1610
1611    Once the DS RRset has been authenticated using the root DNSKEY, the
1612    resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
1613    RR that matches one of the authenticated "example" DS RRs.  If such a
1614    matching "example" DNSKEY is found, the resolver checks whether this
1615    DNSKEY RR has signed the "example" DNSKEY RRset and the signature
1616    lifetime is valid.  If these conditions are met, all keys in the
1617    "example" DNSKEY RRset are considered authenticated.
1618
1619    Finally, the resolver checks that some DNSKEY RR in the "example"
1620
1621
1622
1623 Laurie, et al.           Expires August 5, 2006                [Page 29]
1624 \f
1625 Internet-Draft                    nsec3                    February 2006
1626
1627
1628    DNSKEY RRset uses algorithm 5 and has a key tag of 62699.  This
1629    DNSKEY is used to authenticate the RRSIG included in the response.
1630    If multiple "example" DNSKEY RRs match this algorithm and key tag,
1631    then each DNSKEY RR is tried, and the answer is authenticated if any
1632    of the matching DNSKEY RRs validate the signature as described above.
1633
1634 B.2.  Name Error
1635
1636    An authoritative name error.  The NSEC3 RRs prove that the name does
1637    not exist and that no covering wildcard exists.
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679 Laurie, et al.           Expires August 5, 2006                [Page 30]
1680 \f
1681 Internet-Draft                    nsec3                    February 2006
1682
1683
1684    ;; Header: QR AA DO RCODE=3
1685    ;;
1686    ;; Question
1687    a.c.x.w.example.         IN A
1688
1689    ;; Answer
1690    ;; (empty)
1691
1692    ;; Authority
1693    example.       3600 IN SOA ns1.example. bugs.x.w.example. (
1694                               1
1695                               3600
1696                               300
1697                               3600000
1698                               3600
1699                               )
1700    example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
1701                               20050612112304 62699 example.
1702                               RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
1703                               mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
1704                               qYIt90txzE/4+g== )
1705    7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3  0 1 1 (
1706                               deadbeaf
1707                               dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
1708                               MX NSEC3 RRSIG )
1709    7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG  NSEC3 (
1710                               5 2 3600 20050712112304
1711                               20050612112304 62699 example.
1712                               YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
1713                               ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
1714                               MEFQmc/gEuxojA== )
1715    nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3  0 1 1 (
1716                               deadbeaf
1717                               vhgwr2qgykdkf4m6iv6vkagbxozphazr
1718                               HINFO A AAAA NSEC3 RRSIG )
1719    nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG  NSEC3 (
1720                               5 2 3600 20050712112304
1721                               20050612112304 62699 example.
1722                               c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
1723                               z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
1724                               jL33Wm1p07TBdw== )
1725    ;; Additional
1726    ;; (empty)
1727
1728    The query returned two NSEC3 RRs that prove that the requested data
1729    does not exist and no wildcard applies.  The negative reply is
1730    authenticated by verifying both NSEC3 RRs.  The NSEC3 RRs are
1731    authenticated in a manner identical to that of the MX RRset discussed
1732
1733
1734
1735 Laurie, et al.           Expires August 5, 2006                [Page 31]
1736 \f
1737 Internet-Draft                    nsec3                    February 2006
1738
1739
1740    above.  At least one of the owner names of the NSEC3 RRs will match
1741    the closest encloser.  At least one of the NSEC3 RRs prove that there
1742    exists no longer name.  At least one of the NSEC3 RRs prove that
1743    there exists no wildcard RRsets that should have been expanded.  The
1744    closest encloser can be found by hashing the apex ownername (The SOA
1745    RR's ownername, or the ownername of the DNSKEY RRset referred by an
1746    RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and
1747    if that fails, continue by adding labels.  In other words, the
1748    resolver first hashes example, checks for a matching NSEC3 ownername,
1749    then hashes w.example, checks, and finally hashes w.x.example and
1750    checks.
1751
1752    In the above example, the name 'x.w.example' hashes to
1753    '7nomf47k3vlidh4vxahhpp47l3tgv7a2'.  This indicates that this might
1754    be the closest encloser.  To prove that 'c.x.w.example' and
1755    '*.x.w.example' do not exists, these names are hashed to respectively
1756    'qsgoxsf2lanysajhtmaylde4tqwnqppl' and
1757    'cvljzyf6nsckjowghch4tt3nohocpdka'.  The two NSEC3 records prove that
1758    these hashed ownernames do not exists, since the names are within the
1759    given intervals.
1760
1761 B.3.  No Data Error
1762
1763    A "no data" response.  The NSEC3 RR proves that the name exists and
1764    that the requested RR type does not.
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791 Laurie, et al.           Expires August 5, 2006                [Page 32]
1792 \f
1793 Internet-Draft                    nsec3                    February 2006
1794
1795
1796    ;; Header: QR AA DO RCODE=0
1797    ;;
1798    ;; Question
1799    ns1.example.        IN MX
1800
1801    ;; Answer
1802    ;; (empty)
1803
1804    ;; Authority
1805    example.       3600 IN SOA ns1.example. bugs.x.w.example. (
1806                               1
1807                               3600
1808                               300
1809                               3600000
1810                               3600
1811                               )
1812    example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
1813                               20050612112304 62699 example.
1814                               RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
1815                               mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
1816                               qYIt90txzE/4+g== )
1817    wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3  0 1 1 (
1818                               deadbeaf
1819                               zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
1820                               A NSEC3 RRSIG )
1821    wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG  NSEC3 (
1822                               5 2 3600 20050712112304
1823                               20050612112304 62699 example.
1824                               ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
1825                               ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
1826                               oorBv4xkb0flXw== )
1827    ;; Additional
1828    ;; (empty)
1829
1830    The query returned an NSEC3 RR that proves that the requested name
1831    exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"),
1832    but the requested RR type does not exist (type MX is absent in the
1833    type code list of the NSEC RR).  The negative reply is authenticated
1834    by verifying the NSEC3 RR.  The NSEC3 RR is authenticated in a manner
1835    identical to that of the MX RRset discussed above.
1836
1837 B.3.1.  No Data Error, Empty Non-Terminal
1838
1839    A "no data" response because of an empty non-terminal.  The NSEC3 RR
1840    proves that the name exists and that the requested RR type does not.
1841
1842
1843
1844
1845
1846
1847 Laurie, et al.           Expires August 5, 2006                [Page 33]
1848 \f
1849 Internet-Draft                    nsec3                    February 2006
1850
1851
1852    ;; Header: QR AA DO RCODE=0
1853    ;;
1854    ;; Question
1855    y.w.example.        IN A
1856
1857    ;; Answer
1858    ;; (empty)
1859
1860    ;; Authority
1861    example.       3600 IN SOA ns1.example. bugs.x.w.example. (
1862                               1
1863                               3600
1864                               300
1865                               3600000
1866                               3600
1867                               )
1868    example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
1869                               20050612112304 62699 example.
1870                               RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
1871                               mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
1872                               qYIt90txzE/4+g== )
1873    jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3  0 1 1 (
1874                               deadbeaf
1875                               kcll7fqfnisuhfekckeeqnmbbd4maanu
1876                               NSEC3 RRSIG )
1877    jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG  NSEC3 (
1878                               5 2 3600 20050712112304
1879                               20050612112304 62699 example.
1880                               FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
1881                               IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
1882                               94Zbq3k8lgdpZA== )
1883
1884    The query returned an NSEC3 RR that proves that the requested name
1885    exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"),
1886    but the requested RR type does not exist (Type A is absent in the
1887    type-bit-maps of the NSEC3 RR).  The negative reply is authenticated
1888    by verifying the NSEC3 RR.  The NSEC3 RR is authenticated in a manner
1889    identical to that of the MX RRset discussed above.  Note that, unlike
1890    generic empty non terminal proof using NSECs, this is identical to
1891    proving a No Data Error.  This example is solely mentioned to be
1892    complete.
1893
1894 B.4.  Referral to Signed Zone
1895
1896    Referral to a signed zone.  The DS RR contains the data which the
1897    resolver will need to validate the corresponding DNSKEY RR in the
1898    child zone's apex.
1899
1900
1901
1902
1903 Laurie, et al.           Expires August 5, 2006                [Page 34]
1904 \f
1905 Internet-Draft                    nsec3                    February 2006
1906
1907
1908    ;; Header: QR DO RCODE=0
1909    ;;
1910
1911    ;; Question
1912    mc.a.example.       IN MX
1913
1914    ;; Answer
1915    ;; (empty)
1916
1917    ;; Authority
1918    a.example.     3600 IN NS  ns1.a.example.
1919    a.example.     3600 IN NS  ns2.a.example.
1920    a.example.     3600 IN DS  58470 5 1 (
1921                               3079F1593EBAD6DC121E202A8B766A6A4837
1922                               206C )
1923    a.example.     3600 IN RRSIG  DS 5 2 3600 20050712112304 (
1924                               20050612112304 62699 example.
1925                               QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
1926                               cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
1927                               0kx7rGKTc3RQDA== )
1928
1929    ;; Additional
1930    ns1.a.example. 3600 IN A   192.0.2.5
1931    ns2.a.example. 3600 IN A   192.0.2.6
1932
1933    The query returned a referral to the signed "a.example." zone.  The
1934    DS RR is authenticated in a manner identical to that of the MX RRset
1935    discussed above.  This DS RR is used to authenticate the "a.example"
1936    DNSKEY RRset.
1937
1938    Once the "a.example" DS RRset has been authenticated using the
1939    "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
1940    for some "a.example" DNSKEY RR that matches the DS RR.  If such a
1941    matching "a.example" DNSKEY is found, the resolver checks whether
1942    this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
1943    the signature lifetime is valid.  If all these conditions are met,
1944    all keys in the "a.example" DNSKEY RRset are considered
1945    authenticated.
1946
1947 B.5.  Referral to Unsigned Zone using the Opt-In Flag
1948
1949    The NSEC3 RR proves that nothing for this delegation was signed in
1950    the parent zone.  There is no proof that the delegation exists
1951
1952
1953
1954
1955
1956
1957
1958
1959 Laurie, et al.           Expires August 5, 2006                [Page 35]
1960 \f
1961 Internet-Draft                    nsec3                    February 2006
1962
1963
1964    ;; Header: QR DO RCODE=0
1965    ;;
1966    ;; Question
1967    mc.b.example.       IN MX
1968
1969    ;; Answer
1970    ;; (empty)
1971
1972    ;; Authority
1973    b.example.     3600 IN NS  ns1.b.example.
1974    b.example.     3600 IN NS  ns2.b.example.
1975    kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3  1 1 1 (
1976                               deadbeaf
1977                               n42hbhnjj333xdxeybycax5ufvntux5d
1978                               MX NSEC3 RRSIG )
1979    kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG  NSEC3 (
1980                               5 2 3600 20050712112304
1981                               20050612112304 62699 example.
1982                               d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
1983                               IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
1984                               TOLtc5jPrkL4zQ== )
1985
1986    ;; Additional
1987    ns1.b.example. 3600 IN A   192.0.2.7
1988    ns2.b.example. 3600 IN A   192.0.2.8
1989
1990    The query returned a referral to the unsigned "b.example." zone.  The
1991    NSEC3 proves that no authentication leads from "example" to
1992    "b.example", since the hash of "b.example"
1993    ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and
1994    the NSEC3 opt-in bit is set.  The NSEC3 RR is authenticated in a
1995    manner identical to that of the MX RRset discussed above.
1996
1997 B.6.  Wildcard Expansion
1998
1999    A successful query that was answered via wildcard expansion.  The
2000    label count in the answer's RRSIG RR indicates that a wildcard RRset
2001    was expanded to produce this response, and the NSEC3 RR proves that
2002    no closer match exists in the zone.
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015 Laurie, et al.           Expires August 5, 2006                [Page 36]
2016 \f
2017 Internet-Draft                    nsec3                    February 2006
2018
2019
2020    ;; Header: QR AA DO RCODE=0
2021    ;;
2022    ;; Question
2023    a.z.w.example.      IN MX
2024
2025    ;; Answer
2026    a.z.w.example. 3600 IN MX  1 ai.example.
2027    a.z.w.example. 3600 IN RRSIG  MX 5 3 3600 20050712112304 (
2028                               20050612112304 62699 example.
2029                               sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
2030                               xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
2031                               gQlgxEwhvQDEaQ== )
2032    ;; Authority
2033    example.       3600 NS     ns1.example.
2034    example.       3600 NS     ns2.example.
2035    example.       3600 IN RRSIG  NS 5 1 3600 20050712112304 (
2036                               20050612112304 62699 example.
2037                               hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
2038                               m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
2039                               1SH5r/wfjuCg+g== )
2040    zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3  0 1 1 (
2041                               deadbeaf
2042                               5pe7ctl7pfs2cilroy5dcofx4rcnlypd
2043                               MX NSEC3 RRSIG )
2044    zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG  NSEC3 (
2045                               5 2 3600 20050712112304
2046                               20050612112304 62699 example.
2047                               eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
2048                               7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
2049                               OcFlrPGPMm48/A== )
2050    ;; Additional
2051    ai.example.    3600 IN A   192.0.2.9
2052    ai.example.    3600 IN RRSIG  A 5 2 3600 20050712112304 (
2053                               20050612112304 62699 example.
2054                               plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
2055                               6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
2056                               ZXW5S+1VjMZYzQ== )
2057    ai.example.    3600 AAAA   2001:db8::f00:baa9
2058    ai.example.    3600 IN RRSIG  AAAA 5 2 3600 20050712112304 (
2059                               20050612112304 62699 example.
2060                               PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
2061                               ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
2062                               l5/UqLCJJ9BDMg== )
2063
2064    The query returned an answer that was produced as a result of
2065    wildcard expansion.  The answer section contains a wildcard RRset
2066    expanded as it would be in a traditional DNS response, and the
2067    corresponding RRSIG indicates that the expanded wildcard MX RRset was
2068
2069
2070
2071 Laurie, et al.           Expires August 5, 2006                [Page 37]
2072 \f
2073 Internet-Draft                    nsec3                    February 2006
2074
2075
2076    signed by an "example" DNSKEY with algorithm 5 and key tag 62699.
2077    The RRSIG indicates that the original TTL of the MX RRset was 3600,
2078    and, for the purpose of authentication, the current TTL is replaced
2079    by 3600.  The RRSIG labels field value of 2 indicates that the answer
2080    is the result of wildcard expansion, as the "a.z.w.example" name
2081    contains 4 labels.  The name "a.z.w.example" is replaced by
2082    "*.w.example", the MX RRset is placed in canonical form, and,
2083    assuming that the current time falls between the signature inception
2084    and expiration dates, the signature is authenticated.
2085
2086    The NSEC3 proves that no closer match (exact or closer wildcard)
2087    could have been used to answer this query, and the NSEC3 RR must also
2088    be authenticated before the answer is considered valid.
2089
2090 B.7.  Wildcard No Data Error
2091
2092    A "no data" response for a name covered by a wildcard.  The NSEC3 RRs
2093    prove that the matching wildcard name does not have any RRs of the
2094    requested type and that no closer match exists in the zone.
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127 Laurie, et al.           Expires August 5, 2006                [Page 38]
2128 \f
2129 Internet-Draft                    nsec3                    February 2006
2130
2131
2132    ;; Header: QR AA DO RCODE=0
2133    ;;
2134    ;; Question
2135    a.z.w.example.      IN AAAA
2136
2137    ;; Answer
2138    ;; (empty)
2139
2140    ;; Authority
2141    example.       3600 IN SOA ns1.example. bugs.x.w.example. (
2142                               1
2143                               3600
2144                               300
2145                               3600000
2146                               3600
2147                               )
2148    example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
2149                               20050612112304 62699 example.
2150                               RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
2151                               mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
2152                               qYIt90txzE/4+g== )
2153    zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3  0 1 1 (
2154                               deadbeaf
2155                               5pe7ctl7pfs2cilroy5dcofx4rcnlypd
2156                               MX NSEC3 RRSIG )
2157    zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG  NSEC3 (
2158                               5 2 3600 20050712112304
2159                               20050612112304 62699 example.
2160                               eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
2161                               7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
2162                               OcFlrPGPMm48/A== )
2163    ;; Additional
2164    ;; (empty)
2165
2166    The query returned NSEC3 RRs that prove that the requested data does
2167    not exist and no wildcard applies.  The negative reply is
2168    authenticated by verifying both NSEC3 RRs.
2169
2170 B.8.  DS Child Zone No Data Error
2171
2172    A "no data" response for a QTYPE=DS query that was mistakenly sent to
2173    a name server for the child zone.
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183 Laurie, et al.           Expires August 5, 2006                [Page 39]
2184 \f
2185 Internet-Draft                    nsec3                    February 2006
2186
2187
2188    ;; Header: QR AA DO RCODE=0
2189    ;;
2190    ;; Question
2191    example.            IN DS
2192
2193    ;; Answer
2194    ;; (empty)
2195
2196    ;; Authority
2197    example.       3600 IN SOA ns1.example. bugs.x.w.example. (
2198                               1
2199                               3600
2200                               300
2201                               3600000
2202                               3600
2203                               )
2204    example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
2205                               20050612112304 62699 example.
2206                               RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
2207                               mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
2208                               qYIt90txzE/4+g== )
2209    dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3  0 1 1 (
2210                               deadbeaf
2211                               gmnfcccja7wkax3iv26bs75myptje3qk
2212                               MX DNSKEY NS SOA NSEC3 RRSIG )
2213    dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG  NSEC3 (
2214                               5 2 3600 20050712112304
2215                               20050612112304 62699 example.
2216                               VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
2217                               C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
2218                               MOiKMSHozVebqw== )
2219
2220    ;; Additional
2221    ;; (empty)
2222
2223    The query returned NSEC RRs that shows the requested was answered by
2224    a child server ("example" server).  The NSEC RR indicates the
2225    presence of an SOA RR, showing that the answer is from the child .
2226    Queries for the "example" DS RRset should be sent to the parent
2227    servers ("root" servers).
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239 Laurie, et al.           Expires August 5, 2006                [Page 40]
2240 \f
2241 Internet-Draft                    nsec3                    February 2006
2242
2243
2244 Authors' Addresses
2245
2246    Ben Laurie
2247    Nominet
2248    17 Perryn Road
2249    London  W3 7LR
2250    England
2251
2252    Phone: +44 (20) 8735 0686
2253    Email: ben@algroup.co.uk
2254
2255
2256    Geoffrey Sisson
2257    Nominet
2258
2259
2260    Roy Arends
2261    Nominet
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295 Laurie, et al.           Expires August 5, 2006                [Page 41]
2296 \f
2297 Internet-Draft                    nsec3                    February 2006
2298
2299
2300 Intellectual Property Statement
2301
2302    The IETF takes no position regarding the validity or scope of any
2303    Intellectual Property Rights or other rights that might be claimed to
2304    pertain to the implementation or use of the technology described in
2305    this document or the extent to which any license under such rights
2306    might or might not be available; nor does it represent that it has
2307    made any independent effort to identify any such rights.  Information
2308    on the procedures with respect to rights in RFC documents can be
2309    found in BCP 78 and BCP 79.
2310
2311    Copies of IPR disclosures made to the IETF Secretariat and any
2312    assurances of licenses to be made available, or the result of an
2313    attempt made to obtain a general license or permission for the use of
2314    such proprietary rights by implementers or users of this
2315    specification can be obtained from the IETF on-line IPR repository at
2316    http://www.ietf.org/ipr.
2317
2318    The IETF invites any interested party to bring to its attention any
2319    copyrights, patents or patent applications, or other proprietary
2320    rights that may cover technology that may be required to implement
2321    this standard.  Please address the information to the IETF at
2322    ietf-ipr@ietf.org.
2323
2324
2325 Disclaimer of Validity
2326
2327    This document and the information contained herein are provided on an
2328    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2329    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2330    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2331    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2332    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2333    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2334
2335
2336 Copyright Statement
2337
2338    Copyright (C) The Internet Society (2006).  This document is subject
2339    to the rights, licenses and restrictions contained in BCP 78, and
2340    except as set forth therein, the authors retain all their rights.
2341
2342
2343 Acknowledgment
2344
2345    Funding for the RFC Editor function is currently provided by the
2346    Internet Society.
2347
2348
2349
2350
2351 Laurie, et al.           Expires August 5, 2006                [Page 42]
2352 \f