contrib/bind9/doc/rfc/rfc5155.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          B. Laurie
   8 Request for Comments: 5155                                     G. Sisson
   9 Category: Standards Track                                      R. Arends
  10                                                                  Nominet
  11                                                                D. Blacka
  12                                                           VeriSign, Inc.
  13                                                               March 2008
  14
  15
  16      DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
  17
  18 Status of This Memo
  19
  20    This document specifies an Internet standards track protocol for the
  21    Internet community, and requests discussion and suggestions for
  22    improvements.  Please refer to the current edition of the "Internet
  23    Official Protocol Standards" (STD 1) for the standardization state
  24    and status of this protocol.  Distribution of this memo is unlimited.
  25
  26 Abstract
  27
  28    The Domain Name System Security (DNSSEC) Extensions introduced the
  29    NSEC resource record (RR) for authenticated denial of existence.
  30    This document introduces an alternative resource record, NSEC3, which
  31    similarly provides authenticated denial of existence.  However, it
  32    also provides measures against zone enumeration and permits gradual
  33    expansion of delegation-centric zones.
  34
  35 Table of Contents
  36
  37    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
  38      1.1.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . .  4
  39      1.2.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
  40      1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
  41    2.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . .  6
  42    3.  The NSEC3 Resource Record  . . . . . . . . . . . . . . . . . .  7
  43      3.1.  RDATA Fields . . . . . . . . . . . . . . . . . . . . . . .  8
  44        3.1.1.  Hash Algorithm . . . . . . . . . . . . . . . . . . . .  8
  45        3.1.2.  Flags  . . . . . . . . . . . . . . . . . . . . . . . .  8
  46        3.1.3.  Iterations . . . . . . . . . . . . . . . . . . . . . .  8
  47        3.1.4.  Salt Length  . . . . . . . . . . . . . . . . . . . . .  8
  48        3.1.5.  Salt . . . . . . . . . . . . . . . . . . . . . . . . .  8
  49        3.1.6.  Hash Length  . . . . . . . . . . . . . . . . . . . . .  9
  50        3.1.7.  Next Hashed Owner Name . . . . . . . . . . . . . . . .  9
  51        3.1.8.  Type Bit Maps  . . . . . . . . . . . . . . . . . . . .  9
  52      3.2.  NSEC3 RDATA Wire Format  . . . . . . . . . . . . . . . . .  9
  53        3.2.1.  Type Bit Maps Encoding . . . . . . . . . . . . . . . . 10
  54      3.3.  Presentation Format  . . . . . . . . . . . . . . . . . . . 11
  55
  56
  57
  58 Laurie, et al.              Standards Track                     [Page 1]
  59 \f
  60 RFC 5155                         NSEC3                        March 2008
  61
  62
  63    4.  The NSEC3PARAM Resource Record . . . . . . . . . . . . . . . . 12
  64      4.1.  RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 12
  65        4.1.1.  Hash Algorithm . . . . . . . . . . . . . . . . . . . . 12
  66        4.1.2.  Flag Fields  . . . . . . . . . . . . . . . . . . . . . 12
  67        4.1.3.  Iterations . . . . . . . . . . . . . . . . . . . . . . 13
  68        4.1.4.  Salt Length  . . . . . . . . . . . . . . . . . . . . . 13
  69        4.1.5.  Salt . . . . . . . . . . . . . . . . . . . . . . . . . 13
  70      4.2.  NSEC3PARAM RDATA Wire Format . . . . . . . . . . . . . . . 13
  71      4.3.  Presentation Format  . . . . . . . . . . . . . . . . . . . 14
  72    5.  Calculation of the Hash  . . . . . . . . . . . . . . . . . . . 14
  73    6.  Opt-Out  . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
  74    7.  Authoritative Server Considerations  . . . . . . . . . . . . . 16
  75      7.1.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 16
  76      7.2.  Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 17
  77        7.2.1.  Closest Encloser Proof . . . . . . . . . . . . . . . . 18
  78        7.2.2.  Name Error Responses . . . . . . . . . . . . . . . . . 19
  79        7.2.3.  No Data Responses, QTYPE is not DS . . . . . . . . . . 19
  80        7.2.4.  No Data Responses, QTYPE is DS . . . . . . . . . . . . 19
  81        7.2.5.  Wildcard No Data Responses . . . . . . . . . . . . . . 19
  82        7.2.6.  Wildcard Answer Responses  . . . . . . . . . . . . . . 20
  83        7.2.7.  Referrals to Unsigned Subzones . . . . . . . . . . . . 20
  84        7.2.8.  Responding to Queries for NSEC3 Owner Names  . . . . . 20
  85        7.2.9.  Server Response to a Run-Time Collision  . . . . . . . 21
  86      7.3.  Secondary Servers  . . . . . . . . . . . . . . . . . . . . 21
  87      7.4.  Zones Using Unknown Hash Algorithms  . . . . . . . . . . . 21
  88      7.5.  Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 21
  89    8.  Validator Considerations . . . . . . . . . . . . . . . . . . . 23
  90      8.1.  Responses with Unknown Hash Types  . . . . . . . . . . . . 23
  91      8.2.  Verifying NSEC3 RRs  . . . . . . . . . . . . . . . . . . . 23
  92      8.3.  Closest Encloser Proof . . . . . . . . . . . . . . . . . . 23
  93      8.4.  Validating Name Error Responses  . . . . . . . . . . . . . 24
  94      8.5.  Validating No Data Responses, QTYPE is not DS  . . . . . . 24
  95      8.6.  Validating No Data Responses, QTYPE is DS  . . . . . . . . 24
  96      8.7.  Validating Wildcard No Data Responses  . . . . . . . . . . 25
  97      8.8.  Validating Wildcard Answer Responses . . . . . . . . . . . 25
  98      8.9.  Validating Referrals to Unsigned Subzones  . . . . . . . . 25
  99    9.  Resolver Considerations  . . . . . . . . . . . . . . . . . . . 26
 100      9.1.  NSEC3 Resource Record Caching  . . . . . . . . . . . . . . 26
 101      9.2.  Use of the AD Bit  . . . . . . . . . . . . . . . . . . . . 26
 102    10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26
 103      10.1. Domain Name Length Restrictions  . . . . . . . . . . . . . 26
 104      10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 27
 105      10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 27
 106      10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 28
 107      10.5. Transitioning a Signed Zone from NSEC3 to NSEC . . . . . . 28
 108    11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
 109    12. Security Considerations  . . . . . . . . . . . . . . . . . . . 30
 110      12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 30
 111
 112
 113
 114 Laurie, et al.              Standards Track                     [Page 2]
 115 \f
 116 RFC 5155                         NSEC3                        March 2008
 117
 118
 119        12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 30
 120        12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 31
 121        12.1.3. Transitioning to a New Hash Algorithm  . . . . . . . . 31
 122        12.1.4. Using High Iteration Values  . . . . . . . . . . . . . 31
 123      12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 32
 124      12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 33
 125    13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
 126      13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
 127      13.2. Informative References . . . . . . . . . . . . . . . . . . 34
 128    Appendix A.  Example Zone  . . . . . . . . . . . . . . . . . . . . 35
 129    Appendix B.  Example Responses . . . . . . . . . . . . . . . . . . 40
 130      B.1.  Name Error . . . . . . . . . . . . . . . . . . . . . . . . 40
 131      B.2.  No Data Error  . . . . . . . . . . . . . . . . . . . . . . 42
 132        B.2.1.  No Data Error, Empty Non-Terminal  . . . . . . . . . . 43
 133      B.3.  Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 44
 134      B.4.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 45
 135      B.5.  Wildcard No Data Error . . . . . . . . . . . . . . . . . . 46
 136      B.6.  DS Child Zone No Data Error  . . . . . . . . . . . . . . . 48
 137    Appendix C.  Special Considerations  . . . . . . . . . . . . . . . 48
 138      C.1.  Salting  . . . . . . . . . . . . . . . . . . . . . . . . . 49
 139      C.2.  Hash Collision . . . . . . . . . . . . . . . . . . . . . . 49
 140        C.2.1.  Avoiding Hash Collisions During Generation . . . . . . 50
 141        C.2.2.  Second Preimage Requirement Analysis . . . . . . . . . 50
 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
 168
 169
 170 Laurie, et al.              Standards Track                     [Page 3]
 171 \f
 172 RFC 5155                         NSEC3                        March 2008
 173
 174
 175 1.  Introduction
 176
 177 1.1.  Rationale
 178
 179    The DNS Security Extensions included the NSEC RR to provide
 180    authenticated denial of existence.  Though the NSEC RR meets the
 181    requirements for authenticated denial of existence, it introduces a
 182    side-effect in that the contents of a zone can be enumerated.  This
 183    property introduces undesired policy issues.
 184
 185    The enumeration is enabled by the set of NSEC records that exists
 186    inside a signed zone.  An NSEC record lists two names that are
 187    ordered canonically, in order to show that nothing exists between the
 188    two names.  The complete set of NSEC records lists all the names in a
 189    zone.  It is trivial to enumerate the content of a zone by querying
 190    for names that do not exist.
 191
 192    An enumerated zone can be used, for example, as a source of probable
 193    e-mail addresses for spam, or as a key for multiple WHOIS queries to
 194    reveal registrant data that many registries may have legal
 195    obligations to protect.  Many registries therefore prohibit the
 196    copying of their zone data; however, the use of NSEC RRs renders
 197    these policies unenforceable.
 198
 199    A second problem is that the cost to cryptographically secure
 200    delegations to unsigned zones is high, relative to the perceived
 201    security benefit, in two cases: large, delegation-centric zones, and
 202    zones where insecure delegations will be updated rapidly.  In these
 203    cases, the costs of maintaining the NSEC RR chain may be extremely
 204    high and use of the "Opt-Out" convention may be more appropriate (for
 205    these unsecured zones).
 206
 207    This document presents the NSEC3 Resource Record which can be used as
 208    an alternative to NSEC to mitigate these issues.
 209
 210    Earlier work to address these issues include [DNSEXT-NO], [RFC4956],
 211    and [DNSEXT-NSEC2v2].
 212
 213 1.2.  Requirements
 214
 215    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 216    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 217    document are to be interpreted as described in [RFC2119].
 218
 219
 220
 221
 222
 223
 224
 225
 226 Laurie, et al.              Standards Track                     [Page 4]
 227 \f
 228 RFC 5155                         NSEC3                        March 2008
 229
 230
 231 1.3.  Terminology
 232
 233    The reader is assumed to be familiar with the basic DNS and DNSSEC
 234    concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034],
 235    [RFC4035], and subsequent RFCs that update them: [RFC2136],
 236    [RFC2181], and [RFC2308].
 237
 238    The following terminology is used throughout this document:
 239
 240    Zone enumeration:  the practice of discovering the full content of a
 241       zone via successive queries.  Zone enumeration was non-trivial
 242       prior to the introduction of DNSSEC.
 243
 244    Original owner name:  the owner name corresponding to a hashed owner
 245       name.
 246
 247    Hashed owner name:  the owner name created after applying the hash
 248       function to an owner name.
 249
 250    Hash order:  the order in which hashed owner names are arranged
 251       according to their numerical value, treating the leftmost (lowest
 252       numbered) octet as the most significant octet.  Note that this
 253       order is the same as the canonical DNS name order specified in
 254       [RFC4034], when the hashed owner names are in base32, encoded with
 255       an Extended Hex Alphabet [RFC4648].
 256
 257    Empty non-terminal:  a domain name that owns no resource records, but
 258       has one or more subdomains that do.
 259
 260    Delegation:  an NS RRSet with a name different from the current zone
 261       apex (non-zone-apex), signifying a delegation to a child zone.
 262
 263    Secure delegation:  a name containing a delegation (NS RRSet) and a
 264       signed DS RRSet, signifying a delegation to a signed child zone.
 265
 266    Insecure delegation:  a name containing a delegation (NS RRSet), but
 267       lacking a DS RRSet, signifying a delegation to an unsigned child
 268       zone.
 269
 270    Opt-Out NSEC3 resource record:  an NSEC3 resource record that has the
 271       Opt-Out flag set to 1.
 272
 273    Opt-Out zone:  a zone with at least one Opt-Out NSEC3 RR.
 274
 275    Closest encloser:  the longest existing ancestor of a name.  See also
 276       Section 3.3.1 of [RFC4592].
 277
 278
 279
 280
 281
 282 Laurie, et al.              Standards Track                     [Page 5]
 283 \f
 284 RFC 5155                         NSEC3                        March 2008
 285
 286
 287    Closest provable encloser:  the longest ancestor of a name that can
 288       be proven to exist.  Note that this is only different from the
 289       closest encloser in an Opt-Out zone.
 290
 291    Next closer name:  the name one label longer than the closest
 292       provable encloser of a name.
 293
 294    Base32:  the "Base 32 Encoding with Extended Hex Alphabet" as
 295       specified in [RFC4648].  Note that trailing padding characters
 296       ("=") are not used in the NSEC3 specification.
 297
 298    To cover:  An NSEC3 RR is said to "cover" a name if the hash of the
 299       name or "next closer" name falls between the owner name and the
 300       next hashed owner name of the NSEC3.  In other words, if it proves
 301       the nonexistence of the name, either directly or by proving the
 302       nonexistence of an ancestor of the name.
 303
 304    To match:  An NSEC3 RR is said to "match" a name if the owner name of
 305       the NSEC3 RR is the same as the hashed owner name of that name.
 306
 307 2.  Backwards Compatibility
 308
 309    This specification describes a protocol change that is not generally
 310    backwards compatible with [RFC4033], [RFC4034], and [RFC4035].  In
 311    particular, security-aware resolvers that are unaware of this
 312    specification (NSEC3-unaware resolvers) may fail to validate the
 313    responses introduced by this document.
 314
 315    In order to aid deployment, this specification uses a signaling
 316    technique to prevent NSEC3-unaware resolvers from attempting to
 317    validate responses from NSEC3-signed zones.
 318
 319    This specification allocates two new DNSKEY algorithm identifiers for
 320    this purpose.  Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm
 321    3, DSA.  Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5,
 322    RSASHA1.  These are not new algorithms, they are additional
 323    identifiers for the existing algorithms.
 324
 325    Zones signed according to this specification MUST only use these
 326    algorithm identifiers for their DNSKEY RRs.  Because these new
 327    identifiers will be unknown algorithms to existing, NSEC3-unaware
 328    resolvers, those resolvers will then treat responses from the NSEC3
 329    signed zone as insecure, as detailed in Section 5.2 of [RFC4035].
 330
 331    These algorithm identifiers are used with the NSEC3 hash algorithm
 332    SHA1.  Using other NSEC3 hash algorithms requires allocation of a new
 333    alias (see Section 12.1.3).
 334
 335
 336
 337
 338 Laurie, et al.              Standards Track                     [Page 6]
 339 \f
 340 RFC 5155                         NSEC3                        March 2008
 341
 342
 343    Security aware resolvers that are aware of this specification MUST
 344    recognize the new algorithm identifiers and treat them as equivalent
 345    to the algorithms that they alias.
 346
 347    A methodology for transitioning from a DNSSEC signed zone to a zone
 348    signed using NSEC3 is discussed in Section 10.4.
 349
 350 3.  The NSEC3 Resource Record
 351
 352    The NSEC3 Resource Record (RR) provides authenticated denial of
 353    existence for DNS Resource Record Sets.
 354
 355    The NSEC3 RR lists RR types present at the original owner name of the
 356    NSEC3 RR.  It includes the next hashed owner name in the hash order
 357    of the zone.  The complete set of NSEC3 RRs in a zone indicates which
 358    RRSets exist for the original owner name of the RR and form a chain
 359    of hashed owner names in the zone.  This information is used to
 360    provide authenticated denial of existence for DNS data.  To provide
 361    protection against zone enumeration, the owner names used in the
 362    NSEC3 RR are cryptographic hashes of the original owner name
 363    prepended as a single label to the name of the zone.  The NSEC3 RR
 364    indicates which hash function is used to construct the hash, which
 365    salt is used, and how many iterations of the hash function are
 366    performed over the original owner name.  The hashing technique is
 367    described fully in Section 5.
 368
 369    Hashed owner names of unsigned delegations may be excluded from the
 370    chain.  An NSEC3 RR whose span covers the hash of an owner name or
 371    "next closer" name of an unsigned delegation is referred to as an
 372    Opt-Out NSEC3 RR and is indicated by the presence of a flag.
 373
 374    The owner name for the NSEC3 RR is the base32 encoding of the hashed
 375    owner name prepended as a single label to the name of the zone.
 376
 377    The type value for the NSEC3 RR is 50.
 378
 379    The NSEC3 RR RDATA format is class independent and is described
 380    below.
 381
 382    The class MUST be the same as the class of the original owner name.
 383
 384    The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
 385    field.  This is in the spirit of negative caching [RFC2308].
 386
 387
 388
 389
 390
 391
 392
 393
 394 Laurie, et al.              Standards Track                     [Page 7]
 395 \f
 396 RFC 5155                         NSEC3                        March 2008
 397
 398
 399 3.1.  RDATA Fields
 400
 401 3.1.1.  Hash Algorithm
 402
 403    The Hash Algorithm field identifies the cryptographic hash algorithm
 404    used to construct the hash-value.
 405
 406    The values for this field are defined in the NSEC3 hash algorithm
 407    registry defined in Section 11.
 408
 409 3.1.2.  Flags
 410
 411    The Flags field contains 8 one-bit flags that can be used to indicate
 412    different processing.  All undefined flags must be zero.  The only
 413    flag defined by this specification is the Opt-Out flag.
 414
 415 3.1.2.1.  Opt-Out Flag
 416
 417    If the Opt-Out flag is set, the NSEC3 record covers zero or more
 418    unsigned delegations.
 419
 420    If the Opt-Out flag is clear, the NSEC3 record covers zero unsigned
 421    delegations.
 422
 423    The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned
 424    delegations.  It is the least significant bit in the Flags field.
 425    See Section 6 for details about the use of this flag.
 426
 427 3.1.3.  Iterations
 428
 429    The Iterations field defines the number of additional times the hash
 430    function has been performed.  More iterations result in greater
 431    resiliency of the hash value against dictionary attacks, but at a
 432    higher computational cost for both the server and resolver.  See
 433    Section 5 for details of the use of this field, and Section 10.3 for
 434    limitations on the value.
 435
 436 3.1.4.  Salt Length
 437
 438    The Salt Length field defines the length of the Salt field in octets,
 439    ranging in value from 0 to 255.
 440
 441 3.1.5.  Salt
 442
 443    The Salt field is appended to the original owner name before hashing
 444    in order to defend against pre-calculated dictionary attacks.  See
 445    Section 5 for details on how the salt is used.
 446
 447
 448
 449
 450 Laurie, et al.              Standards Track                     [Page 8]
 451 \f
 452 RFC 5155                         NSEC3                        March 2008
 453
 454
 455 3.1.6.  Hash Length
 456
 457    The Hash Length field defines the length of the Next Hashed Owner
 458    Name field, ranging in value from 1 to 255 octets.
 459
 460 3.1.7.  Next Hashed Owner Name
 461
 462    The Next Hashed Owner Name field contains the next hashed owner name
 463    in hash order.  This value is in binary format.  Given the ordered
 464    set of all hashed owner names, the Next Hashed Owner Name field
 465    contains the hash of an owner name that immediately follows the owner
 466    name of the given NSEC3 RR.  The value of the Next Hashed Owner Name
 467    field in the last NSEC3 RR in the zone is the same as the hashed
 468    owner name of the first NSEC3 RR in the zone in hash order.  Note
 469    that, unlike the owner name of the NSEC3 RR, the value of this field
 470    does not contain the appended zone name.
 471
 472 3.1.8.  Type Bit Maps
 473
 474    The Type Bit Maps field identifies the RRSet types that exist at the
 475    original owner name of the NSEC3 RR.
 476
 477 3.2.  NSEC3 RDATA Wire Format
 478
 479    The RDATA of the NSEC3 RR is as shown below:
 480
 481                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 482     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
 483    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 484    |   Hash Alg.   |     Flags     |          Iterations           |
 485    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 486    |  Salt Length  |                     Salt                      /
 487    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 488    |  Hash Length  |             Next Hashed Owner Name            /
 489    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 490    /                         Type Bit Maps                         /
 491    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 492
 493    Hash Algorithm is a single octet.
 494
 495    Flags field is a single octet, the Opt-Out flag is the least
 496    significant bit, as shown below:
 497
 498     0 1 2 3 4 5 6 7
 499    +-+-+-+-+-+-+-+-+
 500    |             |O|
 501    +-+-+-+-+-+-+-+-+
 502
 503
 504
 505
 506 Laurie, et al.              Standards Track                     [Page 9]
 507 \f
 508 RFC 5155                         NSEC3                        March 2008
 509
 510
 511    Iterations is represented as a 16-bit unsigned integer, with the most
 512    significant bit first.
 513
 514    Salt Length is represented as an unsigned octet.  Salt Length
 515    represents the length of the Salt field in octets.  If the value is
 516    zero, the following Salt field is omitted.
 517
 518    Salt, if present, is encoded as a sequence of binary octets.  The
 519    length of this field is determined by the preceding Salt Length
 520    field.
 521
 522    Hash Length is represented as an unsigned octet.  Hash Length
 523    represents the length of the Next Hashed Owner Name field in octets.
 524
 525    The next hashed owner name is not base32 encoded, unlike the owner
 526    name of the NSEC3 RR.  It is the unmodified binary hash value.  It
 527    does not include the name of the containing zone.  The length of this
 528    field is determined by the preceding Hash Length field.
 529
 530 3.2.1.  Type Bit Maps Encoding
 531
 532    The encoding of the Type Bit Maps field is the same as that used by
 533    the NSEC RR, described in [RFC4034].  It is explained and clarified
 534    here for clarity.
 535
 536    The RR type space is split into 256 window blocks, each representing
 537    the low-order 8 bits of the 16-bit RR type space.  Each block that
 538    has at least one active RR type is encoded using a single octet
 539    window number (from 0 to 255), a single octet bitmap length (from 1
 540    to 32) indicating the number of octets used for the bitmap of the
 541    window block, and up to 32 octets (256 bits) of bitmap.
 542
 543    Blocks are present in the NSEC3 RR RDATA in increasing numerical
 544    order.
 545
 546       Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
 547
 548       where "|" denotes concatenation.
 549
 550    Each bitmap encodes the low-order 8 bits of RR types within the
 551    window block, in network bit order.  The first bit is bit 0.  For
 552    window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
 553    to RR type 2 (NS), and so forth.  For window block 1, bit 1
 554    corresponds to RR type 257, bit 2 to RR type 258.  If a bit is set to
 555    1, it indicates that an RRSet of that type is present for the
 556    original owner name of the NSEC3 RR.  If a bit is set to 0, it
 557    indicates that no RRSet of that type is present for the original
 558    owner name of the NSEC3 RR.
 559
 560
 561
 562 Laurie, et al.              Standards Track                    [Page 10]
 563 \f
 564 RFC 5155                         NSEC3                        March 2008
 565
 566
 567    Since bit 0 in window block 0 refers to the non-existing RR type 0,
 568    it MUST be set to 0.  After verification, the validator MUST ignore
 569    the value of bit 0 in window block 0.
 570
 571    Bits representing Meta-TYPEs or QTYPEs as specified in Section 3.1 of
 572    [RFC2929] or within the range reserved for assignment only to QTYPEs
 573    and Meta-TYPEs MUST be set to 0, since they do not appear in zone
 574    data.  If encountered, they must be ignored upon reading.
 575
 576    Blocks with no types present MUST NOT be included.  Trailing zero
 577    octets in the bitmap MUST be omitted.  The length of the bitmap of
 578    each block is determined by the type code with the largest numerical
 579    value, within that block, among the set of RR types present at the
 580    original owner name of the NSEC3 RR.  Trailing octets not specified
 581    MUST be interpreted as zero octets.
 582
 583 3.3.  Presentation Format
 584
 585    The presentation format of the RDATA portion is as follows:
 586
 587    o  The Hash Algorithm field is represented as an unsigned decimal
 588       integer.  The value has a maximum of 255.
 589
 590    o  The Flags field is represented as an unsigned decimal integer.
 591       The value has a maximum of 255.
 592
 593    o  The Iterations field is represented as an unsigned decimal
 594       integer.  The value is between 0 and 65535, inclusive.
 595
 596    o  The Salt Length field is not represented.
 597
 598    o  The Salt field is represented as a sequence of case-insensitive
 599       hexadecimal digits.  Whitespace is not allowed within the
 600       sequence.  The Salt field is represented as "-" (without the
 601       quotes) when the Salt Length field has a value of 0.
 602
 603    o  The Hash Length field is not represented.
 604
 605    o  The Next Hashed Owner Name field is represented as an unpadded
 606       sequence of case-insensitive base32 digits, without whitespace.
 607
 608    o  The Type Bit Maps field is represented as a sequence of RR type
 609       mnemonics.  When the mnemonic is not known, the TYPE
 610       representation as described in Section 5 of [RFC3597] MUST be
 611       used.
 612
 613
 614
 615
 616
 617
 618 Laurie, et al.              Standards Track                    [Page 11]
 619 \f
 620 RFC 5155                         NSEC3                        March 2008
 621
 622
 623 4.  The NSEC3PARAM Resource Record
 624
 625    The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm,
 626    flags, iterations, and salt) needed by authoritative servers to
 627    calculate hashed owner names.  The presence of an NSEC3PARAM RR at a
 628    zone apex indicates that the specified parameters may be used by
 629    authoritative servers to choose an appropriate set of NSEC3 RRs for
 630    negative responses.  The NSEC3PARAM RR is not used by validators or
 631    resolvers.
 632
 633    If an NSEC3PARAM RR is present at the apex of a zone with a Flags
 634    field value of zero, then there MUST be an NSEC3 RR using the same
 635    hash algorithm, iterations, and salt parameters present at every
 636    hashed owner name in the zone.  That is, the zone MUST contain a
 637    complete set of NSEC3 RRs with the same hash algorithm, iterations,
 638    and salt parameters.
 639
 640    The owner name for the NSEC3PARAM RR is the name of the zone apex.
 641
 642    The type value for the NSEC3PARAM RR is 51.
 643
 644    The NSEC3PARAM RR RDATA format is class independent and is described
 645    below.
 646
 647    The class MUST be the same as the NSEC3 RRs to which this RR refers.
 648
 649 4.1.  RDATA Fields
 650
 651    The RDATA for this RR mirrors the first four fields in the NSEC3 RR.
 652
 653 4.1.1.  Hash Algorithm
 654
 655    The Hash Algorithm field identifies the cryptographic hash algorithm
 656    used to construct the hash-value.
 657
 658    The acceptable values are the same as the corresponding field in the
 659    NSEC3 RR.
 660
 661 4.1.2.  Flag Fields
 662
 663    The Opt-Out flag is not used and is set to zero.
 664
 665    All other flags are reserved for future use, and must be zero.
 666
 667    NSEC3PARAM RRs with a Flags field value other than zero MUST be
 668    ignored.
 669
 670
 671
 672
 673
 674 Laurie, et al.              Standards Track                    [Page 12]
 675 \f
 676 RFC 5155                         NSEC3                        March 2008
 677
 678
 679 4.1.3.  Iterations
 680
 681    The Iterations field defines the number of additional times the hash
 682    is performed.
 683
 684    Its acceptable values are the same as the corresponding field in the
 685    NSEC3 RR.
 686
 687 4.1.4.  Salt Length
 688
 689    The Salt Length field defines the length of the salt in octets,
 690    ranging in value from 0 to 255.
 691
 692 4.1.5.  Salt
 693
 694    The Salt field is appended to the original owner name before hashing.
 695
 696 4.2.  NSEC3PARAM RDATA Wire Format
 697
 698    The RDATA of the NSEC3PARAM RR is as shown below:
 699
 700                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 701     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
 702    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 703    |   Hash Alg.   |     Flags     |          Iterations           |
 704    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 705    |  Salt Length  |                     Salt                      /
 706    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 707
 708    Hash Algorithm is a single octet.
 709
 710    Flags field is a single octet.
 711
 712    Iterations is represented as a 16-bit unsigned integer, with the most
 713    significant bit first.
 714
 715    Salt Length is represented as an unsigned octet.  Salt Length
 716    represents the length of the following Salt field in octets.  If the
 717    value is zero, the Salt field is omitted.
 718
 719    Salt, if present, is encoded as a sequence of binary octets.  The
 720    length of this field is determined by the preceding Salt Length
 721    field.
 722
 723
 724
 725
 726
 727
 728
 729
 730 Laurie, et al.              Standards Track                    [Page 13]
 731 \f
 732 RFC 5155                         NSEC3                        March 2008
 733
 734
 735 4.3.  Presentation Format
 736
 737    The presentation format of the RDATA portion is as follows:
 738
 739    o  The Hash Algorithm field is represented as an unsigned decimal
 740       integer.  The value has a maximum of 255.
 741
 742    o  The Flags field is represented as an unsigned decimal integer.
 743       The value has a maximum value of 255.
 744
 745    o  The Iterations field is represented as an unsigned decimal
 746       integer.  The value is between 0 and 65535, inclusive.
 747
 748    o  The Salt Length field is not represented.
 749
 750    o  The Salt field is represented as a sequence of case-insensitive
 751       hexadecimal digits.  Whitespace is not allowed within the
 752       sequence.  This field is represented as "-" (without the quotes)
 753       when the Salt Length field is zero.
 754
 755 5.  Calculation of the Hash
 756
 757    The hash calculation uses three of the NSEC3 RDATA fields: Hash
 758    Algorithm, Salt, and Iterations.
 759
 760    Define H(x) to be the hash of x using the Hash Algorithm selected by
 761    the NSEC3 RR, k to be the number of Iterations, and || to indicate
 762    concatenation.  Then define:
 763
 764       IH(salt, x, 0) = H(x || salt), and
 765
 766       IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0
 767
 768    Then the calculated hash of an owner name is
 769
 770       IH(salt, owner name, iterations),
 771
 772    where the owner name is in the canonical form, defined as:
 773
 774    The wire format of the owner name where:
 775
 776    1.  The owner name is fully expanded (no DNS name compression) and
 777        fully qualified;
 778
 779    2.  All uppercase US-ASCII letters are replaced by the corresponding
 780        lowercase US-ASCII letters;
 781
 782
 783
 784
 785
 786 Laurie, et al.              Standards Track                    [Page 14]
 787 \f
 788 RFC 5155                         NSEC3                        March 2008
 789
 790
 791    3.  If the owner name is a wildcard name, the owner name is in its
 792        original unexpanded form, including the "*" label (no wildcard
 793        substitution);
 794
 795    This form is as defined in Section 6.2 of [RFC4034].
 796
 797    The method to calculate the Hash is based on [RFC2898].
 798
 799 6.  Opt-Out
 800
 801    In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS
 802    RRSets at delegation points are not signed and may be accompanied by
 803    a DS RRSet.  With the Opt-Out bit clear, the security status of the
 804    child zone is determined by the presence or absence of this DS RRSet,
 805    cryptographically proven by the signed NSEC3 RR at the hashed owner
 806    name of the delegation.  Setting the Opt-Out flag modifies this by
 807    allowing insecure delegations to exist within the signed zone without
 808    a corresponding NSEC3 RR at the hashed owner name of the delegation.
 809
 810    An Opt-Out NSEC3 RR is said to cover a delegation if the hash of the
 811    owner name or "next closer" name of the delegation is between the
 812    owner name of the NSEC3 RR and the next hashed owner name.
 813
 814    An Opt-Out NSEC3 RR does not assert the existence or non-existence of
 815    the insecure delegations that it may cover.  This allows for the
 816    addition or removal of these delegations without recalculating or re-
 817    signing RRs in the NSEC3 RR chain.  However, Opt-Out NSEC3 RRs do
 818    assert the (non)existence of other, authoritative RRSets.
 819
 820    An Opt-Out NSEC3 RR MAY have the same original owner name as an
 821    insecure delegation.  In this case, the delegation is proven insecure
 822    by the lack of a DS bit in the type map and the signed NSEC3 RR does
 823    assert the existence of the delegation.
 824
 825    Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and
 826    non-Opt-Out NSEC3 RRs.  If an NSEC3 RR is not Opt-Out, there MUST NOT
 827    be any hashed owner names of insecure delegations (nor any other RRs)
 828    between it and the name indicated by the next hashed owner name in
 829    the NSEC3 RDATA.  If it is Opt-Out, it MUST only cover hashed owner
 830    names or hashed "next closer" names of insecure delegations.
 831
 832    The effects of the Opt-Out flag on signing, serving, and validating
 833    responses are covered in following sections.
 834
 835
 836
 837
 838
 839
 840
 841
 842 Laurie, et al.              Standards Track                    [Page 15]
 843 \f
 844 RFC 5155                         NSEC3                        March 2008
 845
 846
 847 7.  Authoritative Server Considerations
 848
 849 7.1.  Zone Signing
 850
 851    Zones using NSEC3 must satisfy the following properties:
 852
 853    o  Each owner name within the zone that owns authoritative RRSets
 854       MUST have a corresponding NSEC3 RR.  Owner names that correspond
 855       to unsigned delegations MAY have a corresponding NSEC3 RR.
 856       However, if there is not a corresponding NSEC3 RR, there MUST be
 857       an Opt-Out NSEC3 RR that covers the "next closer" name to the
 858       delegation.  Other non-authoritative RRs are not represented by
 859       NSEC3 RRs.
 860
 861    o  Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
 862       the empty non-terminal is only derived from an insecure delegation
 863       covered by an Opt-Out NSEC3 RR.
 864
 865    o  The TTL value for any NSEC3 RR SHOULD be the same as the minimum
 866       TTL value field in the zone SOA RR.
 867
 868    o  The Type Bit Maps field of every NSEC3 RR in a signed zone MUST
 869       indicate the presence of all types present at the original owner
 870       name, except for the types solely contributed by an NSEC3 RR
 871       itself.  Note that this means that the NSEC3 type itself will
 872       never be present in the Type Bit Maps.
 873
 874    The following steps describe a method of proper construction of NSEC3
 875    RRs.  This is not the only such possible method.
 876
 877    1.  Select the hash algorithm and the values for salt and iterations.
 878
 879    2.  For each unique original owner name in the zone add an NSEC3 RR.
 880
 881        *  If Opt-Out is being used, owner names of unsigned delegations
 882           MAY be excluded.
 883
 884        *  The owner name of the NSEC3 RR is the hash of the original
 885           owner name, prepended as a single label to the zone name.
 886
 887        *  The Next Hashed Owner Name field is left blank for the moment.
 888
 889        *  If Opt-Out is being used, set the Opt-Out bit to one.
 890
 891        *  For collision detection purposes, optionally keep track of the
 892           original owner name with the NSEC3 RR.
 893
 894
 895
 896
 897
 898 Laurie, et al.              Standards Track                    [Page 16]
 899 \f
 900 RFC 5155                         NSEC3                        March 2008
 901
 902
 903        *  Additionally, for collision detection purposes, optionally
 904           create an additional NSEC3 RR corresponding to the original
 905           owner name with the asterisk label prepended (i.e., as if a
 906           wildcard existed as a child of this owner name) and keep track
 907           of this original owner name.  Mark this NSEC3 RR as temporary.
 908
 909    3.  For each RRSet at the original owner name, set the corresponding
 910        bit in the Type Bit Maps field.
 911
 912    4.  If the difference in number of labels between the apex and the
 913        original owner name is greater than 1, additional NSEC3 RRs need
 914        to be added for every empty non-terminal between the apex and the
 915        original owner name.  This process may generate NSEC3 RRs with
 916        duplicate hashed owner names.  Optionally, for collision
 917        detection, track the original owner names of these NSEC3 RRs and
 918        create temporary NSEC3 RRs for wildcard collisions in a similar
 919        fashion to step 1.
 920
 921    5.  Sort the set of NSEC3 RRs into hash order.
 922
 923    6.  Combine NSEC3 RRs with identical hashed owner names by replacing
 924        them with a single NSEC3 RR with the Type Bit Maps field
 925        consisting of the union of the types represented by the set of
 926        NSEC3 RRs.  If the original owner name was tracked, then
 927        collisions may be detected when combining, as all of the matching
 928        NSEC3 RRs should have the same original owner name.  Discard any
 929        possible temporary NSEC3 RRs.
 930
 931    7.  In each NSEC3 RR, insert the next hashed owner name by using the
 932        value of the next NSEC3 RR in hash order.  The next hashed owner
 933        name of the last NSEC3 RR in the zone contains the value of the
 934        hashed owner name of the first NSEC3 RR in the hash order.
 935
 936    8.  Finally, add an NSEC3PARAM RR with the same Hash Algorithm,
 937        Iterations, and Salt fields to the zone apex.
 938
 939    If a hash collision is detected, then a new salt has to be chosen,
 940    and the signing process restarted.
 941
 942 7.2.  Zone Serving
 943
 944    This specification modifies DNSSEC-enabled DNS responses generated by
 945    authoritative servers.  In particular, it replaces the use of NSEC
 946    RRs in such responses with NSEC3 RRs.
 947
 948
 949
 950
 951
 952
 953
 954 Laurie, et al.              Standards Track                    [Page 17]
 955 \f
 956 RFC 5155                         NSEC3                        March 2008
 957
 958
 959    In the following response cases, the NSEC RRs dictated by DNSSEC
 960    [RFC4035] are replaced with NSEC3 RRs that prove the same facts.
 961    Responses that would not contain NSEC RRs are unchanged by this
 962    specification.
 963
 964    When returning responses containing multiple NSEC3 RRs, all of the
 965    NSEC3 RRs MUST use the same hash algorithm, iteration, and salt
 966    values.  The Flags field value MUST be either zero or one.
 967
 968 7.2.1.  Closest Encloser Proof
 969
 970    For many NSEC3 responses a proof of the closest encloser is required.
 971    This is a proof that some ancestor of the QNAME is the closest
 972    encloser of QNAME.
 973
 974    This proof consists of (up to) two different NSEC3 RRs:
 975
 976    o  An NSEC3 RR that matches the closest (provable) encloser.
 977
 978    o  An NSEC3 RR that covers the "next closer" name to the closest
 979       encloser.
 980
 981    The first NSEC3 RR essentially proposes a possible closest encloser,
 982    and proves that the particular encloser does, in fact, exist.  The
 983    second NSEC3 RR proves that the possible closest encloser is the
 984    closest, and proves that the QNAME (and any ancestors between QNAME
 985    and the closest encloser) does not exist.
 986
 987    These NSEC3 RRs are collectively referred to as the "closest encloser
 988    proof" in the subsequent descriptions.
 989
 990    For example, the closest encloser proof for the nonexistent
 991    "alpha.beta.gamma.example." owner name might prove that
 992    "gamma.example." is the closest encloser.  This response would
 993    contain the NSEC3 RR that matches "gamma.example.", and would also
 994    contain the NSEC3 RR that covers "beta.gamma.example." (which is the
 995    "next closer" name).
 996
 997    It is possible, when using Opt-Out (Section 6), to not be able to
 998    prove the actual closest encloser because it is, or is part of an
 999    insecure delegation covered by an Opt-Out span.  In this case,
1000    instead of proving the actual closest encloser, the closest provable
1001    encloser is used.  That is, the closest enclosing authoritative name
1002    is used instead.  In this case, the set of NSEC3 RRs used for this
1003    proof is referred to as the "closest provable encloser proof".
1004
1005
1006
1007
1008
1009
1010 Laurie, et al.              Standards Track                    [Page 18]
1011 \f
1012 RFC 5155                         NSEC3                        March 2008
1013
1014
1015 7.2.2.  Name Error Responses
1016
1017    To prove the nonexistence of QNAME, a closest encloser proof and an
1018    NSEC3 RR covering the (nonexistent) wildcard RR at the closest
1019    encloser MUST be included in the response.  This collection of (up
1020    to) three NSEC3 RRs proves both that QNAME does not exist and that a
1021    wildcard that could have matched QNAME also does not exist.
1022
1023    For example, if "gamma.example." is the closest provable encloser to
1024    QNAME, then an NSEC3 RR covering "*.gamma.example." is included in
1025    the authority section of the response.
1026
1027 7.2.3.  No Data Responses, QTYPE is not DS
1028
1029    The server MUST include the NSEC3 RR that matches QNAME.  This NSEC3
1030    RR MUST NOT have the bits corresponding to either the QTYPE or CNAME
1031    set in its Type Bit Maps field.
1032
1033 7.2.4.  No Data Responses, QTYPE is DS
1034
1035    If there is an NSEC3 RR that matches QNAME, the server MUST return it
1036    in the response.  The bits corresponding with DS and CNAME MUST NOT
1037    be set in the Type Bit Maps field of this NSEC3 RR.
1038
1039    If no NSEC3 RR matches QNAME, the server MUST return a closest
1040    provable encloser proof for QNAME.  The NSEC3 RR that covers the
1041    "next closer" name MUST have the Opt-Out bit set (note that this is
1042    true by definition -- if the Opt-Out bit is not set, something has
1043    gone wrong).
1044
1045    If a server is authoritative for both sides of a zone cut at QNAME,
1046    the server MUST return the proof from the parent side of the zone
1047    cut.
1048
1049 7.2.5.  Wildcard No Data Responses
1050
1051    If there is a wildcard match for QNAME, but QTYPE is not present at
1052    that name, the response MUST include a closest encloser proof for
1053    QNAME and MUST include the NSEC3 RR that matches the wildcard.  This
1054    combination proves both that QNAME itself does not exist and that a
1055    wildcard that matches QNAME does exist.  Note that the closest
1056    encloser to QNAME MUST be the immediate ancestor of the wildcard RR
1057    (if this is not the case, then something has gone wrong).
1058
1059
1060
1061
1062
1063
1064
1065
1066 Laurie, et al.              Standards Track                    [Page 19]
1067 \f
1068 RFC 5155                         NSEC3                        March 2008
1069
1070
1071 7.2.6.  Wildcard Answer Responses
1072
1073    If there is a wildcard match for QNAME and QTYPE, then, in addition
1074    to the expanded wildcard RRSet returned in the answer section of the
1075    response, proof that the wildcard match was valid must be returned.
1076
1077    This proof is accomplished by proving that both QNAME does not exist
1078    and that the closest encloser of the QNAME and the immediate ancestor
1079    of the wildcard are the same (i.e., the correct wildcard matched).
1080
1081    To this end, the NSEC3 RR that covers the "next closer" name of the
1082    immediate ancestor of the wildcard MUST be returned.  It is not
1083    necessary to return an NSEC3 RR that matches the closest encloser, as
1084    the existence of this closest encloser is proven by the presence of
1085    the expanded wildcard in the response.
1086
1087 7.2.7.  Referrals to Unsigned Subzones
1088
1089    If there is an NSEC3 RR that matches the delegation name, then that
1090    NSEC3 RR MUST be included in the response.  The DS bit in the type
1091    bit maps of the NSEC3 RR MUST NOT be set.
1092
1093    If the zone is Opt-Out, then there may not be an NSEC3 RR
1094    corresponding to the delegation.  In this case, the closest provable
1095    encloser proof MUST be included in the response.  The included NSEC3
1096    RR that covers the "next closer" name for the delegation MUST have
1097    the Opt-Out flag set to one.  (Note that this will be the case unless
1098    something has gone wrong).
1099
1100 7.2.8.  Responding to Queries for NSEC3 Owner Names
1101
1102    The owner names of NSEC3 RRs are not represented in the NSEC3 RR
1103    chain like other owner names.  As a result, each NSEC3 owner name is
1104    covered by another NSEC3 RR, effectively negating the existence of
1105    the NSEC3 RR.  This is a paradox, since the existence of an NSEC3 RR
1106    can be proven by its RRSIG RRSet.
1107
1108    If the following conditions are all true:
1109
1110    o  the QNAME equals the owner name of an existing NSEC3 RR, and
1111
1112    o  no RR types exist at the QNAME, nor at any descendant of QNAME,
1113
1114    then the response MUST be constructed as a Name Error response
1115    (Section 7.2.2).  Or, in other words, the authoritative name server
1116    will act as if the owner name of the NSEC3 RR did not exist.
1117
1118
1119
1120
1121
1122 Laurie, et al.              Standards Track                    [Page 20]
1123 \f
1124 RFC 5155                         NSEC3                        March 2008
1125
1126
1127    Note that NSEC3 RRs are returned as a result of an AXFR or IXFR
1128    query.
1129
1130 7.2.9.  Server Response to a Run-Time Collision
1131
1132    If the hash of a non-existing QNAME collides with the owner name of
1133    an existing NSEC3 RR, then the server will be unable to return a
1134    response that proves that QNAME does not exist.  In this case, the
1135    server MUST return a response with an RCODE of 2 (server failure).
1136
1137    Note that with the hash algorithm specified in this document, SHA-1,
1138    such collisions are highly unlikely.
1139
1140 7.3.  Secondary Servers
1141
1142    Secondary servers (and perhaps other entities) need to reliably
1143    determine which NSEC3 parameters (i.e., hash, salt, and iterations)
1144    are present at every hashed owner name, in order to be able to choose
1145    an appropriate set of NSEC3 RRs for negative responses.  This is
1146    indicated by an NSEC3PARAM RR present at the zone apex.
1147
1148    If there are multiple NSEC3PARAM RRs present, there are multiple
1149    valid NSEC3 chains present.  The server must choose one of them, but
1150    may use any criteria to do so.
1151
1152 7.4.  Zones Using Unknown Hash Algorithms
1153
1154    Zones that are signed according to this specification, but are using
1155    an unrecognized NSEC3 hash algorithm value, cannot be effectively
1156    served.  Such zones SHOULD be rejected when loading.  Servers SHOULD
1157    respond with RCODE=2 (server failure) responses when handling queries
1158    that would fall under such zones.
1159
1160 7.5.  Dynamic Update
1161
1162    A zone signed using NSEC3 may accept dynamic updates [RFC2136].
1163    However, NSEC3 introduces some special considerations for dynamic
1164    updates.
1165
1166    Adding and removing names in a zone MUST account for the creation or
1167    removal of empty non-terminals.
1168
1169    o  When removing a name with a corresponding NSEC3 RR, any NSEC3 RRs
1170       corresponding to empty non-terminals created by that name MUST be
1171       removed.  Note that more than one name may be asserting the
1172       existence of a particular empty non-terminal.
1173
1174
1175
1176
1177
1178 Laurie, et al.              Standards Track                    [Page 21]
1179 \f
1180 RFC 5155                         NSEC3                        March 2008
1181
1182
1183    o  When adding a name that requires adding an NSEC3 RR, NSEC3 RRs
1184       MUST also be added for any empty non-terminals that are created.
1185       That is, if there is not an existing NSEC3 RR matching an empty
1186       non-terminal, it must be created and added.
1187
1188    The presence of Opt-Out in a zone means that some additions or
1189    delegations of names will not require changes to the NSEC3 RRs in a
1190    zone.
1191
1192    o  When removing a delegation RRSet, if that delegation does not have
1193       a matching NSEC3 RR, then it was opted out.  In this case, nothing
1194       further needs to be done.
1195
1196    o  When adding a delegation RRSet, if the "next closer" name of the
1197       delegation is covered by an existing Opt-Out NSEC3 RR, then the
1198       delegation MAY be added without modifying the NSEC3 RRs in the
1199       zone.
1200
1201    The presence of Opt-Out in a zone means that when adding or removing
1202    NSEC3 RRs, the value of the Opt-Out flag that should be set in new or
1203    modified NSEC3 RRs is ambiguous.  Servers SHOULD follow this set of
1204    basic rules to resolve the ambiguity.
1205
1206    The central concept to these rules is that the state of the Opt-Out
1207    flag of the covering NSEC3 RR is preserved.
1208
1209    o  When removing an NSEC3 RR, the value of the Opt-Out flag for the
1210       previous NSEC3 RR (the one whose next hashed owner name is
1211       modified) should not be changed.
1212
1213    o  When adding an NSEC3 RR, the value of the Opt-Out flag is set to
1214       the value of the Opt-Out flag of the NSEC3 RR that previously
1215       covered the owner name of the NSEC3 RR.  That is, the now previous
1216       NSEC3 RR.
1217
1218    If the zone in question is consistent with its use of the Opt-Out
1219    flag (that is, all NSEC3 RRs in the zone have the same value for the
1220    flag) then these rules will retain that consistency.  If the zone is
1221    not consistent in the use of the flag (i.e., a partially Opt-Out
1222    zone), then these rules will not retain the same pattern of use of
1223    the Opt-Out flag.
1224
1225    For zones that partially use the Opt-Out flag, if there is a logical
1226    pattern for that use, the pattern could be maintained by using a
1227    local policy on the server.
1228
1229
1230
1231
1232
1233
1234 Laurie, et al.              Standards Track                    [Page 22]
1235 \f
1236 RFC 5155                         NSEC3                        March 2008
1237
1238
1239 8.  Validator Considerations
1240
1241 8.1.  Responses with Unknown Hash Types
1242
1243    A validator MUST ignore NSEC3 RRs with unknown hash types.  The
1244    practical result of this is that responses containing only such NSEC3
1245    RRs will generally be considered bogus.
1246
1247 8.2.  Verifying NSEC3 RRs
1248
1249    A validator MUST ignore NSEC3 RRs with a Flag fields value other than
1250    zero or one.
1251
1252    A validator MAY treat a response as bogus if the response contains
1253    NSEC3 RRs that contain different values for hash algorithm,
1254    iterations, or salt from each other for that zone.
1255
1256 8.3.  Closest Encloser Proof
1257
1258    In order to verify a closest encloser proof, the validator MUST find
1259    the longest name, X, such that
1260
1261    o  X is an ancestor of QNAME that is matched by an NSEC3 RR present
1262       in the response.  This is a candidate for the closest encloser,
1263       and
1264
1265    o  The name one label longer than X (but still an ancestor of -- or
1266       equal to -- QNAME) is covered by an NSEC3 RR present in the
1267       response.
1268
1269    One possible algorithm for verifying this proof is as follows:
1270
1271    1.  Set SNAME=QNAME.  Clear the flag.
1272
1273    2.  Check whether SNAME exists:
1274
1275        *  If there is no NSEC3 RR in the response that matches SNAME
1276           (i.e., an NSEC3 RR whose owner name is the same as the hash of
1277           SNAME, prepended as a single label to the zone name), clear
1278           the flag.
1279
1280        *  If there is an NSEC3 RR in the response that covers SNAME, set
1281           the flag.
1282
1283        *  If there is a matching NSEC3 RR in the response and the flag
1284           was set, then the proof is complete, and SNAME is the closest
1285           encloser.
1286
1287
1288
1289
1290 Laurie, et al.              Standards Track                    [Page 23]
1291 \f
1292 RFC 5155                         NSEC3                        March 2008
1293
1294
1295        *  If there is a matching NSEC3 RR in the response, but the flag
1296           is not set, then the response is bogus.
1297
1298    3.  Truncate SNAME by one label from the left, go to step 2.
1299
1300    Once the closest encloser has been discovered, the validator MUST
1301    check that the NSEC3 RR that has the closest encloser as the original
1302    owner name is from the proper zone.  The DNAME type bit must not be
1303    set and the NS type bit may only be set if the SOA type bit is set.
1304    If this is not the case, it would be an indication that an attacker
1305    is using them to falsely deny the existence of RRs for which the
1306    server is not authoritative.
1307
1308    In the following descriptions, the phrase "a closest (provable)
1309    encloser proof for X" means that the algorithm above (or an
1310    equivalent algorithm) proves that X does not exist by proving that an
1311    ancestor of X is its closest encloser.
1312
1313 8.4.  Validating Name Error Responses
1314
1315    A validator MUST verify that there is a closest encloser proof for
1316    QNAME present in the response and that there is an NSEC3 RR that
1317    covers the wildcard at the closest encloser (i.e., the name formed by
1318    prepending the asterisk label to the closest encloser).
1319
1320 8.5.  Validating No Data Responses, QTYPE is not DS
1321
1322    The validator MUST verify that an NSEC3 RR that matches QNAME is
1323    present and that both the QTYPE and the CNAME type are not set in its
1324    Type Bit Maps field.
1325
1326    Note that this test also covers the case where the NSEC3 RR exists
1327    because it corresponds to an empty non-terminal, in which case the
1328    NSEC3 RR will have an empty Type Bit Maps field.
1329
1330 8.6.  Validating No Data Responses, QTYPE is DS
1331
1332    If there is an NSEC3 RR that matches QNAME present in the response,
1333    then that NSEC3 RR MUST NOT have the bits corresponding to DS and
1334    CNAME set in its Type Bit Maps field.
1335
1336    If there is no such NSEC3 RR, then the validator MUST verify that a
1337    closest provable encloser proof for QNAME is present in the response,
1338    and that the NSEC3 RR that covers the "next closer" name has the Opt-
1339    Out bit set.
1340
1341
1342
1343
1344
1345
1346 Laurie, et al.              Standards Track                    [Page 24]
1347 \f
1348 RFC 5155                         NSEC3                        March 2008
1349
1350
1351 8.7.  Validating Wildcard No Data Responses
1352
1353    The validator MUST verify a closest encloser proof for QNAME and MUST
1354    find an NSEC3 RR present in the response that matches the wildcard
1355    name generated by prepending the asterisk label to the closest
1356    encloser.  Furthermore, the bits corresponding to both QTYPE and
1357    CNAME MUST NOT be set in the wildcard matching NSEC3 RR.
1358
1359 8.8.  Validating Wildcard Answer Responses
1360
1361    The verified wildcard answer RRSet in the response provides the
1362    validator with a (candidate) closest encloser for QNAME.  This
1363    closest encloser is the immediate ancestor to the generating
1364    wildcard.
1365
1366    Validators MUST verify that there is an NSEC3 RR that covers the
1367    "next closer" name to QNAME present in the response.  This proves
1368    that QNAME itself did not exist and that the correct wildcard was
1369    used to generate the response.
1370
1371 8.9.  Validating Referrals to Unsigned Subzones
1372
1373    The delegation name in a referral is the owner name of the NS RRSet
1374    present in the authority section of the referral response.
1375
1376    If there is an NSEC3 RR present in the response that matches the
1377    delegation name, then the validator MUST ensure that the NS bit is
1378    set and that the DS bit is not set in the Type Bit Maps field of the
1379    NSEC3 RR.  The validator MUST also ensure that the NSEC3 RR is from
1380    the correct (i.e., parent) zone.  This is done by ensuring that the
1381    SOA bit is not set in the Type Bit Maps field of this NSEC3 RR.
1382
1383    Note that the presence of an NS bit implies the absence of a DNAME
1384    bit, so there is no need to check for the DNAME bit in the Type Bit
1385    Maps field of the NSEC3 RR.
1386
1387    If there is no NSEC3 RR present that matches the delegation name,
1388    then the validator MUST verify a closest provable encloser proof for
1389    the delegation name.  The validator MUST verify that the Opt-Out bit
1390    is set in the NSEC3 RR that covers the "next closer" name to the
1391    delegation name.
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402 Laurie, et al.              Standards Track                    [Page 25]
1403 \f
1404 RFC 5155                         NSEC3                        March 2008
1405
1406
1407 9.  Resolver Considerations
1408
1409 9.1.  NSEC3 Resource Record Caching
1410
1411    Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs
1412    when returning responses that contain them.  In DNSSEC [RFC4035], in
1413    many cases it is possible to find the correct NSEC RR to return in a
1414    response by name (e.g., when returning a referral, the NSEC RR will
1415    always have the same owner name as the delegation).  With this
1416    specification, that will not be true, nor will a cache be able to
1417    calculate the name(s) of the appropriate NSEC3 RR(s).
1418    Implementations may need to use new methods for caching and
1419    retrieving NSEC3 RRs.
1420
1421 9.2.  Use of the AD Bit
1422
1423    The AD bit, as defined by [RFC4035], MUST NOT be set when returning a
1424    response containing a closest (provable) encloser proof in which the
1425    NSEC3 RR that covers the "next closer" name has the Opt-Out bit set.
1426
1427    This rule is based on what this closest encloser proof actually
1428    proves: names that would be covered by the Opt-Out NSEC3 RR may or
1429    may not exist as insecure delegations.  As such, not all the data in
1430    responses containing such closest encloser proofs will have been
1431    cryptographically verified, so the AD bit cannot be set.
1432
1433 10.  Special Considerations
1434
1435 10.1.  Domain Name Length Restrictions
1436
1437    Zones signed using this specification have additional domain name
1438    length restrictions imposed upon them.  In particular, zones with
1439    names that, when converted into hashed owner names exceed the 255
1440    octet length limit imposed by [RFC1035], cannot use this
1441    specification.
1442
1443    The actual maximum length of a domain name in a particular zone
1444    depends on both the length of the zone name (versus the whole domain
1445    name) and the particular hash function used.
1446
1447    As an example, SHA-1 produces a hash of 160 bits.  The base-32
1448    encoding of 160 bits results in 32 characters.  The 32 characters are
1449    prepended to the name of the zone as a single label, which includes a
1450    length field of a single octet.  The maximum length of the zone name,
1451    when using SHA-1, is 222 octets (255 - 33).
1452
1453
1454
1455
1456
1457
1458 Laurie, et al.              Standards Track                    [Page 26]
1459 \f
1460 RFC 5155                         NSEC3                        March 2008
1461
1462
1463 10.2.  DNAME at the Zone Apex
1464
1465    The DNAME specification in Section 3 of [RFC2672] has a 'no-
1466    descendants' limitation.  If a DNAME RR is present at node N, there
1467    MUST be no data at any descendant of N.
1468
1469    If N is the apex of the zone, there will be NSEC3 and RRSIG types
1470    present at descendants of N.  This specification updates the DNAME
1471    specification to allow NSEC3 and RRSIG types at descendants of the
1472    apex regardless of the existence of DNAME at the apex.
1473
1474 10.3.  Iterations
1475
1476    Setting the number of iterations used allows the zone owner to choose
1477    the cost of computing a hash, and therefore the cost of generating a
1478    dictionary.  Note that this is distinct from the effect of salt,
1479    which prevents the use of a single precomputed dictionary for all
1480    time.
1481
1482    Obviously the number of iterations also affects the zone owner's cost
1483    of signing and serving the zone as well as the validator's cost of
1484    verifying responses from the zone.  We therefore impose an upper
1485    limit on the number of iterations.  We base this on the number of
1486    iterations that approximates the cost of verifying an RRSet.
1487
1488    The limits, therefore, are based on the size of the smallest zone
1489    signing key, rounded up to the nearest table value (or rounded down
1490    if the key is larger than the largest table value).
1491
1492    A zone owner MUST NOT use a value higher than shown in the table
1493    below for iterations for the given key size.  A resolver MAY treat a
1494    response with a higher value as insecure, after the validator has
1495    verified that the signature over the NSEC3 RR is correct.
1496
1497                          +----------+------------+
1498                          | Key Size | Iterations |
1499                          +----------+------------+
1500                          | 1024     | 150        |
1501                          | 2048     | 500        |
1502                          | 4096     | 2,500      |
1503                          +----------+------------+
1504
1505    This table is based on an approximation of the ratio between the cost
1506    of an SHA-1 calculation and the cost of an RSA verification for keys
1507    of size 1024 bits (150 to 1), 2048 bits (500 to 1), and 4096 bits
1508    (2500 to 1).
1509
1510
1511
1512
1513
1514 Laurie, et al.              Standards Track                    [Page 27]
1515 \f
1516 RFC 5155                         NSEC3                        March 2008
1517
1518
1519    The ratio between SHA-1 calculation and DSA verification is higher
1520    (1500 to 1 for keys of size 1024).  A higher iteration count degrades
1521    performance, while DSA verification is already more expensive than
1522    RSA for the same key size.  Therefore the values in the table MUST be
1523    used independent of the key algorithm.
1524
1525 10.4.  Transitioning a Signed Zone from NSEC to NSEC3
1526
1527    When transitioning an already signed and trusted zone to this
1528    specification, care must be taken to prevent client validation
1529    failures during the process.
1530
1531    The basic procedure is as follows:
1532
1533    1.  Transition all DNSKEYs to DNSKEYs using the algorithm aliases
1534        described in Section 2.  The actual method for safely and
1535        securely changing the DNSKEY RRSet of the zone is outside the
1536        scope of this specification.  However, the end result MUST be
1537        that all DS RRs in the parent use the specified algorithm
1538        aliases.
1539
1540        After this transition is complete, all NSEC3-unaware clients will
1541        treat the zone as insecure.  At this point, the authoritative
1542        server still returns negative and wildcard responses that contain
1543        NSEC RRs.
1544
1545    2.  Add signed NSEC3 RRs to the zone, either incrementally or all at
1546        once.  If adding incrementally, then the last RRSet added MUST be
1547        the NSEC3PARAM RRSet.
1548
1549    3.  Upon the addition of the NSEC3PARAM RRSet, the server switches to
1550        serving negative and wildcard responses with NSEC3 RRs according
1551        to this specification.
1552
1553    4.  Remove the NSEC RRs either incrementally or all at once.
1554
1555 10.5.  Transitioning a Signed Zone from NSEC3 to NSEC
1556
1557    To safely transition back to a DNSSEC [RFC4035] signed zone, simply
1558    reverse the procedure above:
1559
1560    1.  Add NSEC RRs incrementally or all at once.
1561
1562    2.  Remove the NSEC3PARAM RRSet.  This will signal the server to use
1563        the NSEC RRs for negative and wildcard responses.
1564
1565    3.  Remove the NSEC3 RRs either incrementally or all at once.
1566
1567
1568
1569
1570 Laurie, et al.              Standards Track                    [Page 28]
1571 \f
1572 RFC 5155                         NSEC3                        March 2008
1573
1574
1575    4.  Transition all of the DNSKEYs to DNSSEC algorithm identifiers.
1576        After this transition is complete, all NSEC3-unaware clients will
1577        treat the zone as secure.
1578
1579 11.  IANA Considerations
1580
1581    Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
1582    parameter, this document does not define a particular mechanism for
1583    safely transitioning from one NSEC3 hash algorithm to another.  When
1584    specifying a new hash algorithm for use with NSEC3, a transition
1585    mechanism MUST also be defined.
1586
1587    This document updates the IANA registry "DOMAIN NAME SYSTEM
1588    PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub-
1589    registry "TYPES", by defining two new types.  Section 3 defines the
1590    NSEC3 RR type 50.  Section 4 defines the NSEC3PARAM RR type 51.
1591
1592    This document updates the IANA registry "DNS SECURITY ALGORITHM
1593    NUMBERS -- per [RFC4035]"
1594    (http://www.iana.org/assignments/dns-sec-alg-numbers).  Section 2
1595    defines the aliases DSA-NSEC3-SHA1 (6) and RSASHA1-NSEC3-SHA1 (7) for
1596    respectively existing registrations DSA and RSASHA1 in combination
1597    with NSEC3 hash algorithm SHA1.
1598
1599    Since these algorithm numbers are aliases for existing DNSKEY
1600    algorithm numbers, the flags that exist for the original algorithm
1601    are valid for the alias algorithm.
1602
1603    This document creates a new IANA registry for NSEC3 flags.  This
1604    registry is named "DNSSEC NSEC3 Flags".  The initial contents of this
1605    registry are:
1606
1607      0   1   2   3   4   5   6   7
1608    +---+---+---+---+---+---+---+---+
1609    |   |   |   |   |   |   |   |Opt|
1610    |   |   |   |   |   |   |   |Out|
1611    +---+---+---+---+---+---+---+---+
1612
1613       bit 7 is the Opt-Out flag.
1614
1615       bits 0 - 6 are available for assignment.
1616
1617    Assignment of additional NSEC3 Flags in this registry requires IETF
1618    Standards Action [RFC2434].
1619
1620    This document creates a new IANA registry for NSEC3PARAM flags.  This
1621    registry is named "DNSSEC NSEC3PARAM Flags".  The initial contents of
1622    this registry are:
1623
1624
1625
1626 Laurie, et al.              Standards Track                    [Page 29]
1627 \f
1628 RFC 5155                         NSEC3                        March 2008
1629
1630
1631      0   1   2   3   4   5   6   7
1632    +---+---+---+---+---+---+---+---+
1633    |   |   |   |   |   |   |   | 0 |
1634    +---+---+---+---+---+---+---+---+
1635
1636       bit 7 is reserved and must be 0.
1637
1638       bits 0 - 6 are available for assignment.
1639
1640    Assignment of additional NSEC3PARAM Flags in this registry requires
1641    IETF Standards Action [RFC2434].
1642
1643    Finally, this document creates a new IANA registry for NSEC3 hash
1644    algorithms.  This registry is named "DNSSEC NSEC3 Hash Algorithms".
1645    The initial contents of this registry are:
1646
1647       0 is Reserved.
1648
1649       1 is SHA-1.
1650
1651       2-255 Available for assignment.
1652
1653    Assignment of additional NSEC3 hash algorithms in this registry
1654    requires IETF Standards Action [RFC2434].
1655
1656 12.  Security Considerations
1657
1658 12.1.  Hashing Considerations
1659
1660 12.1.1.  Dictionary Attacks
1661
1662    The NSEC3 RRs are still susceptible to dictionary attacks (i.e., the
1663    attacker retrieves all the NSEC3 RRs, then calculates the hashes of
1664    all likely domain names, comparing against the hashes found in the
1665    NSEC3 RRs, and thus enumerating the zone).  These are substantially
1666    more expensive than enumerating the original NSEC RRs would have
1667    been, and in any case, such an attack could also be used directly
1668    against the name server itself by performing queries for all likely
1669    names, though this would obviously be more detectable.  The expense
1670    of this off-line attack can be chosen by setting the number of
1671    iterations in the NSEC3 RR.
1672
1673    Zones are also susceptible to a pre-calculated dictionary attack --
1674    that is, a list of hashes for all likely names is computed once, then
1675    NSEC3 RR is scanned periodically and compared against the precomputed
1676    hashes.  This attack is prevented by changing the salt on a regular
1677    basis.
1678
1679
1680
1681
1682 Laurie, et al.              Standards Track                    [Page 30]
1683 \f
1684 RFC 5155                         NSEC3                        March 2008
1685
1686
1687    The salt SHOULD be at least 64 bits long and unpredictable, so that
1688    an attacker cannot anticipate the value of the salt and compute the
1689    next set of dictionaries before the zone is published.
1690
1691 12.1.2.  Collisions
1692
1693    Hash collisions between QNAME and the owner name of an NSEC3 RR may
1694    occur.  When they do, it will be impossible to prove the non-
1695    existence of the colliding QNAME.  However, with SHA-1, this is
1696    highly unlikely (on the order of 1 in 2^160).  Note that DNSSEC
1697    already relies on the presumption that a cryptographic hash function
1698    is second pre-image resistant, since these hash functions are used
1699    for generating and validating signatures and DS RRs.
1700
1701 12.1.3.  Transitioning to a New Hash Algorithm
1702
1703    Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
1704    parameter, this document does not define a particular mechanism for
1705    safely transitioning from one NSEC3 hash algorithm to another.  When
1706    specifying a new hash algorithm for use with NSEC3, a transition
1707    mechanism MUST also be defined.  It is possible that the only
1708    practical and palatable transition mechanisms may require an
1709    intermediate transition to an insecure state, or to a state that uses
1710    NSEC records instead of NSEC3.
1711
1712 12.1.4.  Using High Iteration Values
1713
1714    Since validators should treat responses containing NSEC3 RRs with
1715    high iteration values as insecure, presence of just one signed NSEC3
1716    RR with a high iteration value in a zone provides attackers with a
1717    possible downgrade attack.
1718
1719    The attack is simply to remove any existing NSEC3 RRs from a
1720    response, and replace or add a single (or multiple) NSEC3 RR that
1721    uses a high iterations value to the response.  Validators will then
1722    be forced to treat the response as insecure.  This attack would be
1723    effective only when all of following conditions are met:
1724
1725    o  There is at least one signed NSEC3 RR that uses a high iterations
1726       value present in the zone.
1727
1728    o  The attacker has access to one or more of these NSEC3 RRs.  This
1729       is trivially true when the NSEC3 RRs with high iteration values
1730       are being returned in typical responses, but may also be true if
1731       the attacker can access the zone via AXFR or IXFR queries, or any
1732       other methodology.
1733
1734
1735
1736
1737
1738 Laurie, et al.              Standards Track                    [Page 31]
1739 \f
1740 RFC 5155                         NSEC3                        March 2008
1741
1742
1743    Using a high number of iterations also introduces an additional
1744    denial-of-service opportunity against servers, since servers must
1745    calculate several hashes per negative or wildcard response.
1746
1747 12.2.  Opt-Out Considerations
1748
1749    The Opt-Out Flag (O) allows for unsigned names, in the form of
1750    delegations to unsigned zones, to exist within an otherwise signed
1751    zone.  All unsigned names are, by definition, insecure, and their
1752    validity or existence cannot be cryptographically proven.
1753
1754    In general:
1755
1756    o  Resource records with unsigned names (whether existing or not)
1757       suffer from the same vulnerabilities as RRs in an unsigned zone.
1758       These vulnerabilities are described in more detail in [RFC3833]
1759       (note in particular Section 2.3, "Name Chaining" and Section 2.6,
1760       "Authenticated Denial of Domain Names").
1761
1762    o  Resource records with signed names have the same security whether
1763       or not Opt-Out is used.
1764
1765    Note that with or without Opt-Out, an insecure delegation may be
1766    undetectably altered by an attacker.  Because of this, the primary
1767    difference in security when using Opt-Out is the loss of the ability
1768    to prove the existence or nonexistence of an insecure delegation
1769    within the span of an Opt-Out NSEC3 RR.
1770
1771    In particular, this means that a malicious entity may be able to
1772    insert or delete RRs with unsigned names.  These RRs are normally NS
1773    RRs, but this also includes signed wildcard expansions (while the
1774    wildcard RR itself is signed, its expanded name is an unsigned name).
1775
1776    Note that being able to add a delegation is functionally equivalent
1777    to being able to add any RR type: an attacker merely has to forge a
1778    delegation to name server under his/her control and place whatever
1779    RRs needed at the subzone apex.
1780
1781    While in particular cases, this issue may not present a significant
1782    security problem, in general it should not be lightly dismissed.
1783    Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly.
1784    In particular, zone signing tools SHOULD NOT default to using Opt-
1785    Out, and MAY choose to not support Opt-Out at all.
1786
1787
1788
1789
1790
1791
1792
1793
1794 Laurie, et al.              Standards Track                    [Page 32]
1795 \f
1796 RFC 5155                         NSEC3                        March 2008
1797
1798
1799 12.3.  Other Considerations
1800
1801    Walking the NSEC3 RRs will reveal the total number of RRs in the zone
1802    (plus empty non-terminals), and also what types there are.  This
1803    could be mitigated by adding dummy entries, but certainly an upper
1804    limit can always be found.
1805
1806 13.  References
1807
1808 13.1.  Normative References
1809
1810    [RFC1034]         Mockapetris, P., "Domain names - concepts and
1811                      facilities", STD 13, RFC 1034, November 1987.
1812
1813    [RFC1035]         Mockapetris, P., "Domain names - implementation and
1814                      specification", STD 13, RFC 1035, November 1987.
1815
1816    [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
1817                      Requirement Levels", BCP 14, RFC 2119, March 1997.
1818
1819    [RFC2136]         Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
1820                      "Dynamic Updates in the Domain Name System (DNS
1821                      UPDATE)", RFC 2136, April 1997.
1822
1823    [RFC2181]         Elz, R. and R. Bush, "Clarifications to the DNS
1824                      Specification", RFC 2181, July 1997.
1825
1826    [RFC2308]         Andrews, M., "Negative Caching of DNS Queries (DNS
1827                      NCACHE)", RFC 2308, March 1998.
1828
1829    [RFC2434]         Narten, T. and H. Alvestrand, "Guidelines for
1830                      Writing an IANA Considerations Section in RFCs",
1831                      BCP 26, RFC 2434, October 1998.
1832
1833    [RFC2929]         Eastlake, D., Brunner-Williams, E., and B. Manning,
1834                      "Domain Name System (DNS) IANA Considerations",
1835                      BCP 42, RFC 2929, September 2000.
1836
1837    [RFC3597]         Gustafsson, A., "Handling of Unknown DNS Resource
1838                      Record (RR) Types", RFC 3597, September 2003.
1839
1840    [RFC4033]         Arends, R., Austein, R., Larson, M., Massey, D.,
1841                      and S. Rose, "DNS Security Introduction and
1842                      Requirements", RFC 4033, March 2005.
1843
1844    [RFC4034]         Arends, R., Austein, R., Larson, M., Massey, D.,
1845                      and S. Rose, "Resource Records for the DNS Security
1846                      Extensions", RFC 4034, March 2005.
1847
1848
1849
1850 Laurie, et al.              Standards Track                    [Page 33]
1851 \f
1852 RFC 5155                         NSEC3                        March 2008
1853
1854
1855    [RFC4035]         Arends, R., Austein, R., Larson, M., Massey, D.,
1856                      and S. Rose, "Protocol Modifications for the DNS
1857                      Security Extensions", RFC 4035, March 2005.
1858
1859    [RFC4648]         Josefsson, S., "The Base16, Base32, and Base64 Data
1860                      Encodings", RFC 4648, October 2006.
1861
1862 13.2.  Informative References
1863
1864    [DNSEXT-NO]       Josefsson, S., "Authenticating Denial of Existence
1865                      in DNS with Minimum Disclosure", Work in Progress,
1866                      July 2000.
1867
1868    [DNSEXT-NSEC2v2]  Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format",
1869                      Work in Progress, December 2004.
1870
1871    [RFC2672]         Crawford, M., "Non-Terminal DNS Name Redirection",
1872                      RFC 2672, August 1999.
1873
1874    [RFC2898]         Kaliski, B., "PKCS #5: Password-Based Cryptography
1875                      Specification Version 2.0", RFC 2898,
1876                      September 2000.
1877
1878    [RFC3833]         Atkins, D. and R. Austein, "Threat Analysis of the
1879                      Domain Name System (DNS)", RFC 3833, August 2004.
1880
1881    [RFC4592]         Lewis, E., "The Role of Wildcards in the Domain
1882                      Name System", RFC 4592, July 2006.
1883
1884    [RFC4956]         Arends, R., Kosters, M., and D. Blacka, "DNS
1885                      Security (DNSSEC) Opt-In", RFC 4956, July 2007.
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906 Laurie, et al.              Standards Track                    [Page 34]
1907 \f
1908 RFC 5155                         NSEC3                        March 2008
1909
1910
1911 Appendix A.  Example Zone
1912
1913    This is a zone showing its NSEC3 RRs.  They can also be used as test
1914    vectors for the hash algorithm.
1915
1916    The overall TTL and class are specified in the SOA RR, and are
1917    subsequently omitted for clarity.
1918
1919    The zone is preceded by a list that contains the hashes of the
1920    original ownernames.
1921
1922    ; H(example)       = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
1923    ; H(a.example)     = 35mthgpgcu1qg68fab165klnsnk3dpvl
1924    ; H(ai.example)    = gjeqe526plbf1g8mklp59enfd789njgi
1925    ; H(ns1.example)   = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
1926    ; H(ns2.example)   = q04jkcevqvmu85r014c7dkba38o0ji5r
1927    ; H(w.example)     = k8udemvp1j2f7eg6jebps17vp3n8i58h
1928    ; H(*.w.example)   = r53bq7cc2uvmubfu5ocmm6pers9tk9en
1929    ; H(x.w.example)   = b4um86eghhds6nea196smvmlo4ors995
1930    ; H(y.w.example)   = ji6neoaepv8b5o6k4ev33abha8ht9fgc
1931    ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s
1932    ; H(xx.example)    = t644ebqk9bibcna874givr6joj62mlhv
1933    ; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example)
1934    ;                  = kohar7mbb8dc2ce8a9qvl8hon4k53uhi
1935    example. 3600  IN SOA  ns1.example. bugs.x.w.example. 1 3600 300 (
1936                           3600000 3600 )
1937                   RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
1938                           40430 example.
1939                           Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
1940                           q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
1941                           VI2LmKusbZsT0Q== )
1942                   NS      ns1.example.
1943                   NS      ns2.example.
1944                   RRSIG   NS 7 1 3600 20150420235959 20051021000000 (
1945                           40430 example.
1946                           PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
1947                           qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
1948                           CnMXjtz6SyObxA== )
1949                   MX      1 xx.example.
1950                   RRSIG   MX 7 1 3600 20150420235959 20051021000000 (
1951                           40430 example.
1952                           GgQ1A9xs47k42VPvpL/a1BWUz/6XsnHkjotw
1953                           9So8MQtZtl2wJBsnOQsaoHrRCrRbyriEl/GZ
1954                           n9Mto/Kx+wBo+w== )
1955                   DNSKEY  256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU (
1956                           sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h
1957                           TY4hHn9npWFRw5BYubE= )
1958
1959
1960
1961
1962 Laurie, et al.              Standards Track                    [Page 35]
1963 \f
1964 RFC 5155                         NSEC3                        March 2008
1965
1966
1967                   DNSKEY  257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ (
1968                           j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9
1969                           AbsUdblMFin8CVF3n4s= )
1970                   RRSIG   DNSKEY 7 1 3600 20150420235959 (
1971                           20051021000000 12708 example.
1972                           AuU4juU9RaxescSmStrQks3Gh9FblGBlVU31
1973                           uzMZ/U/FpsUb8aC6QZS+sTsJXnLnz7flGOsm
1974                           MGQZf3bH+QsCtg== )
1975                   NSEC3PARAM 1 0 12 aabbccdd
1976                   RRSIG   NSEC3PARAM 7 1 3600 20150420235959 (
1977                           20051021000000 40430 example.
1978                           C1Gl8tPZNtnjlrYWDeeUV/sGLCyy/IHie2re
1979                           rN05XSA3Pq0U3+4VvGWYWdUMfflOdxqnXHwJ
1980                           TLQsjlkynhG6Cg== )
1981    0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
1982                           2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
1983                           SOA NSEC3PARAM RRSIG )
1984                   RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
1985                           40430 example.
1986                           OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
1987                           IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
1988                           BOCXJZMnpuwhpA== )
1989    2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127
1990                   RRSIG   A 7 2 3600 20150420235959 20051021000000 (
1991                           40430 example.
1992                           h6c++bzhRuWWt2bykN6mjaTNBcXNq5UuL5Ed
1993                           K+iDP4eY8I0kSiKaCjg3tC1SQkeloMeub2GW
1994                           k8p6xHMPZumXlw== )
1995                   NSEC3   1 1 12 aabbccdd (
1996                           2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
1997                   RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
1998                           40430 example.
1999                           OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
2000                           4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
2001                           NI6mRk/r1dOSUw== )
2002    2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd (
2003                           35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG )
2004                   RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
2005                           40430 example.
2006                           KL1V2oFYghNV0Hm7Tf2vpJjM6l+0g1JCcVYG
2007                           VfI0lKrhPmTsOA96cLEACgo1x8I7kApJX+ob
2008                           TuktZ+sdsZPY1w== )
2009    35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
2010                           b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
2011
2012
2013
2014
2015
2016
2017
2018 Laurie, et al.              Standards Track                    [Page 36]
2019 \f
2020 RFC 5155                         NSEC3                        March 2008
2021
2022
2023                   RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
2024                           40430 example.
2025                           g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
2026                           Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
2027                           XtAIR3chwgW+SA== )
2028    a.example.     NS      ns1.a.example.
2029                   NS      ns2.a.example.
2030                   DS      58470 5 1 (
2031                           3079F1593EBAD6DC121E202A8B766A6A4837206C )
2032                   RRSIG   DS 7 2 3600 20150420235959 20051021000000 (
2033                           40430 example.
2034                           XacFcQVHLVzdoc45EJhN616zQ4mEXtE8FzUh
2035                           M2KWjfy1VfRKD9r1MeVGwwoukOKgJxBPFsWo
2036                           o722vZ4UZ2dIdA== )
2037    ns1.a.example. A       192.0.2.5
2038    ns2.a.example. A       192.0.2.6
2039    ai.example.    A       192.0.2.9
2040                   RRSIG   A 7 2 3600 20150420235959 20051021000000 (
2041                           40430 example.
2042                           hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
2043                           tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
2044                           rznEn8sQ64UdqA== )
2045                   HINFO   "KLH-10" "ITS"
2046                   RRSIG   HINFO 7 2 3600 20150420235959 20051021000000 (
2047                           40430 example.
2048                           Yi42uOq43eyO6qXHNvwwfFnIustWgV5urFcx
2049                           enkLvs6pKRh00VBjODmf3Z4nMO7IOl6nHSQ1
2050                           v0wLHpEZG7Xj2w== )
2051                   AAAA    2001:db8:0:0:0:0:f00:baa9
2052                   RRSIG   AAAA 7 2 3600 20150420235959 20051021000000 (
2053                           40430 example.
2054                           LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
2055                           uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
2056                           cHueLuXkMjBArQ== )
2057    b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
2058                           gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
2059                   RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
2060                           40430 example.
2061                           ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
2062                           5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
2063                           pOv0TSTyiTxIZg== )
2064    c.example.     NS      ns1.c.example.
2065                   NS      ns2.c.example.
2066    ns1.c.example. A       192.0.2.7
2067    ns2.c.example. A       192.0.2.8
2068    gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd (
2069                           ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA
2070                           RRSIG )
2071
2072
2073
2074 Laurie, et al.              Standards Track                    [Page 37]
2075 \f
2076 RFC 5155                         NSEC3                        March 2008
2077
2078
2079                   RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
2080                           40430 example.
2081                           IVnezTJ9iqblFF97vPSmfXZ5Zozngx3KX3by
2082                           LTZC4QBH2dFWhf6scrGFZB980AfCxoD9qbbK
2083                           Dy+rdGIeRSVNyw== )
2084    ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
2085                           k8udemvp1j2f7eg6jebps17vp3n8i58h )
2086                   RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
2087                           40430 example.
2088                           gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
2089                           2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
2090                           MpzVSKfTwx4uYA== )
2091    k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
2092                           kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
2093                   RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
2094                           40430 example.
2095                           FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
2096                           S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
2097                           Otx7w9WfcIg62A== )
2098    kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd (
2099                           q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG )
2100                   RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
2101                           40430 example.
2102                           VrDXs2uVW21N08SyQIz88zml+y4ZCInTwgDr
2103                           6zz43yAg+LFERjOrj3Ojct51ac7Dp4eZbf9F
2104                           QJazmASFKGxGXg== )
2105    ns1.example.   A       192.0.2.1
2106                   RRSIG   A 7 2 3600 20150420235959 20051021000000 (
2107                           40430 example.
2108                           bu6kx73n6XEunoVGuRfAgY7EF/AJqHy7hj0j
2109                           kiqJjB0dOrx3wuz9SaBeGfqWIdn/uta3SavN
2110                           4FRvZR9SCFHF5Q== )
2111    ns2.example.   A       192.0.2.2
2112                   RRSIG   A 7 2 3600 20150420235959 20051021000000 (
2113                           40430 example.
2114                           ktQ3TqE0CfRfki0Rb/Ip5BM0VnxelbuejCC4
2115                           zpLbFKA/7eD7UNAwxMgxJPtbdST+syjYSJaj
2116                           4IHfeX6n8vfoGA== )
2117    q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
2118                           r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
2119                   RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
2120                           40430 example.
2121                           hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
2122                           ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
2123                           NlkxWcLsIlMmUg== )
2124
2125
2126
2127
2128
2129
2130 Laurie, et al.              Standards Track                    [Page 38]
2131 \f
2132 RFC 5155                         NSEC3                        March 2008
2133
2134
2135    r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
2136                           t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
2137                   RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
2138                           40430 example.
2139                           aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
2140                           ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
2141                           HF1FWKW7RIJdtQ== )
2142    t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd (
2143                           0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA
2144                           RRSIG )
2145                   RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
2146                           40430 example.
2147                           RAjGECB8P7O+F4Pa4Dx3tC0M+Z3KmlLKImca
2148                           fb9XWwx+NWUNz7NBEDBQHivIyKPVDkChcePI
2149                           X1xPl1ATNa+8Dw== )
2150    *.w.example.   MX      1 ai.example.
2151                   RRSIG   MX 7 2 3600 20150420235959 20051021000000 (
2152                           40430 example.
2153                           CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
2154                           9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
2155                           ivEBP6+4KS3ldA== )
2156    x.w.example.   MX      1 xx.example.
2157                   RRSIG   MX 7 3 3600 20150420235959 20051021000000 (
2158                           40430 example.
2159                           IrK3tq/tHFIBF0scHiE/1IwMAvckS/55hAVv
2160                           QyxTFbkAdDloP3NbZzu+yoSsr3b3OX6qbBpY
2161                           7WCtwwekLKRAwQ== )
2162    x.y.w.example. MX      1 xx.example.
2163                   RRSIG   MX 7 4 3600 20150420235959 20051021000000 (
2164                           40430 example.
2165                           MqSt5HqJIN8+SLlzTOImrh5h9Xa6gDvAW/Gn
2166                           nbdPc6Z7nXvCpLPJj/5lCwx3VuzVOjkbvXze
2167                           8/8Ccl2Zn2hbug== )
2168    xx.example.    A       192.0.2.10
2169                   RRSIG   A 7 2 3600 20150420235959 20051021000000 (
2170                           40430 example.
2171                           T35hBWEZ017VC5u2c4OriKyVn/pu+fVK4AlX
2172                           YOxJ6iQylfV2HQIKjv6b7DzINB3aF/wjJqgX
2173                           pQvhq+Ac6+ZiFg== )
2174                   HINFO   "KLH-10" "TOPS-20"
2175                   RRSIG   HINFO 7 2 3600 20150420235959 20051021000000 (
2176                           40430 example.
2177                           KimG+rDd+7VA1zRsu0ITNAQUTRlpnsmqWrih
2178                           FRnU+bRa93v2e5oFNFYCs3Rqgv62K93N7AhW
2179                           6Jfqj/8NzWjvKg== )
2180                   AAAA    2001:db8:0:0:0:0:f00:baaa
2181
2182
2183
2184
2185
2186 Laurie, et al.              Standards Track                    [Page 39]
2187 \f
2188 RFC 5155                         NSEC3                        March 2008
2189
2190
2191                   RRSIG   AAAA 7 2 3600 20150420235959 20051021000000 (
2192                           40430 example.
2193                           IXBcXORITNwd8h3gNwyxtYFvAupS/CYWufVe
2194                           uBUX0O25ivBCULjZjpDxFSxfohb/KA7YRdxE
2195                           NzYfMItpILl/Xw== )
2196
2197 Appendix B.  Example Responses
2198
2199    The examples in this section show response messages using the signed
2200    zone example in Appendix A.
2201
2202 B.1.  Name Error
2203
2204    An authoritative name error.  The NSEC3 RRs prove that the name does
2205    not exist and that there is no wildcard RR that should have been
2206    expanded.
2207
2208 ;; Header: QR AA DO RCODE=3
2209 ;;
2210 ;; Question
2211 a.c.x.w.example.         IN A
2212
2213 ;; Answer
2214 ;; (empty)
2215
2216 ;; Authority
2217
2218 example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
2219                        3600000 3600 )
2220 example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
2221                        40430 example.
2222                        Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
2223                        q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
2224                        VI2LmKusbZsT0Q== )
2225
2226 ;; NSEC3 RR that covers the "next closer" name (c.x.w.example)
2227 ;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh
2228
2229 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
2230                        2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
2231                        SOA NSEC3PARAM RRSIG )
2232 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
2233                        20150420235959 20051021000000 40430 example.
2234                        OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
2235                        IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
2236                        BOCXJZMnpuwhpA== )
2237
2238
2239
2240
2241
2242 Laurie, et al.              Standards Track                    [Page 40]
2243 \f
2244 RFC 5155                         NSEC3                        March 2008
2245
2246
2247 ;; NSEC3 RR that matches the closest encloser (x.w.example)
2248 ;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
2249
2250 b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
2251                        gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
2252 b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 7 2 3600 (
2253                        20150420235959 20051021000000 40430 example.
2254                        ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
2255                        5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
2256                        pOv0TSTyiTxIZg== )
2257
2258 ;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example)
2259 ;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m
2260
2261 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
2262                        b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
2263 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
2264                        20150420235959 20051021000000 40430 example.
2265                        g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
2266                        Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
2267                        XtAIR3chwgW+SA== )
2268
2269 ;; Additional
2270 ;; (empty)
2271
2272    The query returned three NSEC3 RRs that prove that the requested data
2273    does not exist and that no wildcard expansion applies.  The negative
2274    response is authenticated by verifying the NSEC3 RRs.  The
2275    corresponding RRSIGs indicate that the NSEC3 RRs are signed by an
2276    "example" DNSKEY of algorithm 7 and with key tag 40430.  The resolver
2277    needs the corresponding DNSKEY RR in order to authenticate this
2278    answer.
2279
2280    One of the owner names of the NSEC3 RRs matches the closest encloser.
2281    One of the NSEC3 RRs prove that there exists no longer name.  One of
2282    the NSEC3 RRs prove that there exists no wildcard RRSets that should
2283    have been expanded.  The closest encloser can be found by applying
2284    the algorithm in Section 8.3.
2285
2286    In the above example, the name 'x.w.example' hashes to
2287    'b4um86eghhds6nea196smvmlo4ors995'.  This indicates that this might
2288    be the closest encloser.  To prove that 'c.x.w.example' and
2289    '*.x.w.example' do not exist, these names are hashed to,
2290    respectively, '0va5bpr2ou0vk0lbqeeljri88laipsfh' and
2291    '92pqneegtaue7pjatc3l3qnk738c6v5m'.  The first and last NSEC3 RRs
2292    prove that these hashed owner names do not exist.
2293
2294
2295
2296
2297
2298 Laurie, et al.              Standards Track                    [Page 41]
2299 \f
2300 RFC 5155                         NSEC3                        March 2008
2301
2302
2303 B.2.  No Data Error
2304
2305    A "no data" response.  The NSEC3 RR proves that the name exists and
2306    that the requested RR type does not.
2307
2308 ;; Header: QR AA DO RCODE=0
2309 ;;
2310 ;; Question
2311 ns1.example.        IN MX
2312
2313 ;; Answer
2314 ;; (empty)
2315
2316 ;; Authority
2317 example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
2318                        3600000 3600 )
2319 example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
2320                        40430 example.
2321                        Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
2322                        q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
2323                        VI2LmKusbZsT0Q== )
2324
2325 ;; NSEC3 RR matches the QNAME and shows that the MX type bit is not set.
2326
2327 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd (
2328                        2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
2329 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 7 2 3600 (
2330                        20150420235959 20051021000000 40430 example.
2331                        OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
2332                        4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
2333                        NI6mRk/r1dOSUw== )
2334 ;; Additional
2335 ;; (empty)
2336
2337    The query returned an NSEC3 RR that proves that the requested name
2338    exists ("ns1.example." hashes to "2t7b4g4vsa5smi47k61mv5bv1a22bojr"),
2339    but the requested RR type does not exist (type MX is absent in the
2340    type code list of the NSEC3 RR), and was not a CNAME (type CNAME is
2341    also absent in the type code list of the NSEC3 RR).
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354 Laurie, et al.              Standards Track                    [Page 42]
2355 \f
2356 RFC 5155                         NSEC3                        March 2008
2357
2358
2359 B.2.1.  No Data Error, Empty Non-Terminal
2360
2361    A "no data" response because of an empty non-terminal.  The NSEC3 RR
2362    proves that the name exists and that the requested RR type does not.
2363
2364  ;; Header: QR AA DO RCODE=0
2365  ;;
2366  ;; Question
2367  y.w.example.        IN A
2368
2369  ;; Answer
2370  ;; (empty)
2371
2372  ;; Authority
2373  example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
2374                         3600000 3600 )
2375  example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
2376                         40430 example.
2377                         Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
2378                         q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
2379                         VI2LmKusbZsT0Q== )
2380
2381  ;; NSEC3 RR matches the QNAME and shows that the A type bit is not set.
2382
2383  ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
2384                         k8udemvp1j2f7eg6jebps17vp3n8i58h )
2385  ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 7 2 3600 (
2386                         20150420235959 20051021000000 40430 example.
2387                         gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
2388                         2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
2389                         MpzVSKfTwx4uYA== )
2390
2391  ;; Additional
2392  ;; (empty)
2393
2394    The query returned an NSEC3 RR that proves that the requested name
2395    exists ("y.w.example." hashes to "ji6neoaepv8b5o6k4ev33abha8ht9fgc"),
2396    but the requested RR type does not exist (Type A is absent in the
2397    Type Bit Maps field of the NSEC3 RR).  Note that, unlike an empty
2398    non-terminal proof using NSECs, this is identical to a No Data Error.
2399    This example is solely mentioned to be complete.
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410 Laurie, et al.              Standards Track                    [Page 43]
2411 \f
2412 RFC 5155                         NSEC3                        March 2008
2413
2414
2415 B.3.  Referral to an Opt-Out Unsigned Zone
2416
2417    The NSEC3 RRs prove that nothing for this delegation was signed.
2418    There is no proof that the unsigned delegation exists.
2419
2420    ;; Header: QR DO RCODE=0
2421    ;;
2422    ;; Question
2423    mc.c.example.       IN MX
2424
2425    ;; Answer
2426    ;; (empty)
2427
2428    ;; Authority
2429    c.example.     NS      ns1.c.example.
2430                   NS      ns2.c.example.
2431
2432    ;; NSEC3 RR that covers the "next closer" name (c.example)
2433    ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck
2434
2435    35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
2436                           b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
2437    35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
2438                           20150420235959 20051021000000 40430 example.
2439                           g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
2440                           Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
2441                           XtAIR3chwgW+SA== )
2442
2443    ;; NSEC3 RR that matches the closest encloser (example)
2444    ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
2445
2446    0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
2447                           2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
2448                           SOA NSEC3PARAM RRSIG )
2449    0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
2450                           20150420235959 20051021000000 40430 example.
2451                           OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
2452                           IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
2453                           BOCXJZMnpuwhpA== )
2454
2455    ;; Additional
2456    ns1.c.example. A       192.0.2.7
2457    ns2.c.example. A       192.0.2.8
2458
2459    The query returned a referral to the unsigned "c.example." zone.  The
2460    response contains the closest provable encloser of "c.example" to be
2461    "example", since the hash of "c.example"
2462
2463
2464
2465
2466 Laurie, et al.              Standards Track                    [Page 44]
2467 \f
2468 RFC 5155                         NSEC3                        March 2008
2469
2470
2471    ("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR
2472    and its Opt-Out bit is set.
2473
2474 B.4.  Wildcard Expansion
2475
2476    A query that was answered with a response containing a wildcard
2477    expansion.  The label count in the RRSIG RRSet in the answer section
2478    indicates that a wildcard RRSet was expanded to produce this
2479    response, and the NSEC3 RR proves that no "next closer" name exists
2480    in the zone.
2481
2482    ;; Header: QR AA DO RCODE=0
2483    ;;
2484    ;; Question
2485    a.z.w.example. IN MX
2486
2487    ;; Answer
2488    a.z.w.example. MX      1 ai.example.
2489    a.z.w.example. RRSIG   MX 7 2 3600 20150420235959 20051021000000 (
2490                           40430 example.
2491                           CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
2492                           9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
2493                           ivEBP6+4KS3ldA== )
2494
2495    ;; Authority
2496    example.       NS      ns1.example.
2497    example.       NS      ns2.example.
2498    example.       RRSIG   NS 7 1 3600 20150420235959 20051021000000 (
2499                           40430 example.
2500                           PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
2501                           qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
2502                           CnMXjtz6SyObxA== )
2503
2504    ;; NSEC3 RR that covers the "next closer" name (z.w.example)
2505    ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
2506
2507    q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
2508                           r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
2509    q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
2510                           20150420235959 20051021000000 40430 example.
2511                           hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
2512                           ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
2513                           NlkxWcLsIlMmUg== )
2514
2515
2516
2517
2518
2519
2520
2521
2522 Laurie, et al.              Standards Track                    [Page 45]
2523 \f
2524 RFC 5155                         NSEC3                        March 2008
2525
2526
2527    ;; Additional
2528    ai.example.    A       192.0.2.9
2529    ai.example.    RRSIG   A 7 2 3600 20150420235959 20051021000000 (
2530                           40430 example.
2531                           hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
2532                           tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
2533                           rznEn8sQ64UdqA== )
2534    ai.example.    AAAA    2001:db8:0:0:0:0:f00:baa9
2535    ai.example.    RRSIG   AAAA 7 2 3600 20150420235959 20051021000000 (
2536                           40430 example.
2537                           LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
2538                           uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
2539                           cHueLuXkMjBArQ== )
2540
2541    The query returned an answer that was produced as a result of a
2542    wildcard expansion.  The answer section contains a wildcard RRSet
2543    expanded as it would be in a traditional DNS response.  The RRSIG
2544    Labels field value of 2 indicates that the answer is the result of a
2545    wildcard expansion, as the "a.z.w.example" name contains 4 labels.
2546    This also shows that "w.example" exists, so there is no need for an
2547    NSEC3 RR that matches the closest encloser.
2548
2549    The NSEC3 RR proves that no closer match could have been used to
2550    answer this query.
2551
2552 B.5.  Wildcard No Data Error
2553
2554    A "no data" response for a name covered by a wildcard.  The NSEC3 RRs
2555    prove that the matching wildcard name does not have any RRs of the
2556    requested type and that no closer match exists in the zone.
2557
2558    ;; Header: QR AA DO RCODE=0
2559    ;;
2560    ;; Question
2561    a.z.w.example.      IN AAAA
2562
2563    ;; Answer
2564    ;; (empty)
2565
2566    ;; Authority
2567    example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
2568                           3600000 3600 )
2569    example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
2570                           40430 example.
2571                           Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
2572                           q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
2573                           VI2LmKusbZsT0Q== )
2574
2575
2576
2577
2578 Laurie, et al.              Standards Track                    [Page 46]
2579 \f
2580 RFC 5155                         NSEC3                        March 2008
2581
2582
2583    ;; NSEC3 RR that matches the closest encloser (w.example)
2584    ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
2585
2586    k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
2587                           kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
2588    k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 7 2 3600 (
2589                           20150420235959 20051021000000 40430 example.
2590                           FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
2591                           S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
2592                           Otx7w9WfcIg62A== )
2593
2594    ;; NSEC3 RR that covers the "next closer" name (z.w.example)
2595    ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
2596
2597    q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
2598                           r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
2599    q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
2600                           20150420235959 20051021000000 40430 example.
2601                           hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
2602                           ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
2603                           NlkxWcLsIlMmUg== )
2604
2605    ;; NSEC3 RR that matches a wildcard at the closest encloser.
2606    ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
2607
2608    r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
2609                           t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
2610    r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 7 2 3600 (
2611                           20150420235959 20051021000000 40430 example.
2612                           aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
2613                           ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
2614                           HF1FWKW7RIJdtQ== )
2615
2616    ;; Additional
2617    ;; (empty)
2618
2619    The query returned the NSEC3 RRs that prove that the requested data
2620    does not exist and no wildcard RR applies.
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634 Laurie, et al.              Standards Track                    [Page 47]
2635 \f
2636 RFC 5155                         NSEC3                        March 2008
2637
2638
2639 B.6.  DS Child Zone No Data Error
2640
2641    A "no data" response for a QTYPE=DS query that was mistakenly sent to
2642    a name server for the child zone.
2643
2644 ;; Header: QR AA DO RCODE=0
2645 ;;
2646 ;; Question
2647 example.            IN DS
2648
2649 ;; Answer
2650 ;; (empty)
2651
2652 ;; Authority
2653 example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
2654                        3600000 3600 )
2655 example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
2656                        40430 example.
2657                        Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
2658                        q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
2659                        VI2LmKusbZsT0Q== )
2660
2661 ;; NSEC3 RR matches the QNAME and shows that the DS type bit is not set.
2662
2663 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
2664                        2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
2665                        SOA NSEC3PARAM RRSIG )
2666 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600
2667                        20150420235959 20051021000000 40430 example.
2668                        OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
2669                        IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
2670                        BOCXJZMnpuwhpA== )
2671
2672 ;; Additional
2673 ;; (empty)
2674
2675    The query returned an NSEC3 RR showing that the requested was
2676    answered by the server authoritative for the zone "example".  The
2677    NSEC3 RR indicates the presence of an SOA RR, showing that this NSEC3
2678    RR is from the apex of the child, not from the zone cut of the
2679    parent.  Queries for the "example" DS RRSet should be sent to the
2680    parent servers (which are in this case the root servers).
2681
2682 Appendix C.  Special Considerations
2683
2684    The following paragraphs clarify specific behavior and explain
2685    special considerations for implementations.
2686
2687
2688
2689
2690 Laurie, et al.              Standards Track                    [Page 48]
2691 \f
2692 RFC 5155                         NSEC3                        March 2008
2693
2694
2695 C.1.  Salting
2696
2697    Augmenting original owner names with salt before hashing increases
2698    the cost of a dictionary of pre-generated hash-values.  For every bit
2699    of salt, the cost of a precomputed dictionary doubles (because there
2700    must be an entry for each word combined with each possible salt
2701    value).  The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
2702    salt, multiplying the cost by 2^2040.  This means that an attacker
2703    must, in practice, recompute the dictionary each time the salt is
2704    changed.
2705
2706    Including a salt, regardless of size, does not affect the cost of
2707    constructing NSEC3 RRs.  It does increase the size of the NSEC3 RR.
2708
2709    There MUST be at least one complete set of NSEC3 RRs for the zone
2710    using the same salt value.
2711
2712    The salt SHOULD be changed periodically to prevent pre-computation
2713    using a single salt.  It is RECOMMENDED that the salt be changed for
2714    every re-signing.
2715
2716    Note that this could cause a resolver to see RRs with different salt
2717    values for the same zone.  This is harmless, since each RR stands
2718    alone (that is, it denies the set of owner names whose hashes, using
2719    the salt in the NSEC3 RR, fall between the two hashes in the NSEC3
2720    RR) -- it is only the server that needs a complete set of NSEC3 RRs
2721    with the same salt in order to be able to answer every possible
2722    query.
2723
2724    There is no prohibition with having NSEC3 RRs with different salts
2725    within the same zone.  However, in order for authoritative servers to
2726    be able to consistently find covering NSEC3 RRs, the authoritative
2727    server MUST choose a single set of parameters (algorithm, salt, and
2728    iterations) to use when selecting NSEC3 RRs.
2729
2730 C.2.  Hash Collision
2731
2732    Hash collisions occur when different messages have the same hash
2733    value.  The expected number of domain names needed to give a 1 in 2
2734    chance of a single collision is about 2^(n/2) for a hash of length n
2735    bits (i.e., 2^80 for SHA-1).  Though this probability is extremely
2736    low, the following paragraphs deal with avoiding collisions and
2737    assessing possible damage in the event of an attack using hash
2738    collisions.
2739
2740
2741
2742
2743
2744
2745
2746 Laurie, et al.              Standards Track                    [Page 49]
2747 \f
2748 RFC 5155                         NSEC3                        March 2008
2749
2750
2751 C.2.1.  Avoiding Hash Collisions During Generation
2752
2753    During generation of NSEC3 RRs, hash values are supposedly unique.
2754    In the (academic) case of a collision occurring, an alternative salt
2755    MUST be chosen and all hash values MUST be regenerated.
2756
2757 C.2.2.  Second Preimage Requirement Analysis
2758
2759    A cryptographic hash function has a second-preimage resistance
2760    property.  The second-preimage resistance property means that it is
2761    computationally infeasible to find another message with the same hash
2762    value as a given message, i.e., given preimage X, to find a second
2763    preimage X' != X such that hash(X) = hash(X').  The work factor for
2764    finding a second preimage is of the order of 2^160 for SHA-1.  To
2765    mount an attack using an existing NSEC3 RR, an adversary needs to
2766    find a second preimage.
2767
2768    Assuming an adversary is capable of mounting such an extreme attack,
2769    the actual damage is that a response message can be generated that
2770    claims that a certain QNAME (i.e., the second pre-image) does exist,
2771    while in reality QNAME does not exist (a false positive), which will
2772    either cause a security-aware resolver to re-query for the non-
2773    existent name, or to fail the initial query.  Note that the adversary
2774    can't mount this attack on an existing name, but only on a name that
2775    the adversary can't choose and that does not yet exist.
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802 Laurie, et al.              Standards Track                    [Page 50]
2803 \f
2804 RFC 5155                         NSEC3                        March 2008
2805
2806
2807 Authors' Addresses
2808
2809    Ben Laurie
2810    Nominet
2811    17 Perryn Road
2812    London  W3 7LR
2813    England
2814
2815    Phone: +44 20 8735 0686
2816    EMail: ben@links.org
2817
2818
2819    Geoffrey Sisson
2820    Nominet
2821    Minerva House
2822    Edmund Halley Road
2823    Oxford Science Park
2824    Oxford  OX4 4DQ
2825    UNITED KINGDOM
2826
2827    Phone: +44 1865 332211
2828    EMail: geoff-s@panix.com
2829
2830
2831    Roy Arends
2832    Nominet
2833    Minerva House
2834    Edmund Halley Road
2835    Oxford Science Park
2836    Oxford  OX4 4DQ
2837    UNITED KINGDOM
2838
2839    Phone: +44 1865 332211
2840    EMail: roy@nominet.org.uk
2841
2842
2843    David Blacka
2844    VeriSign, Inc.
2845    21355 Ridgetop Circle
2846    Dulles, VA  20166
2847    US
2848
2849    Phone: +1 703 948 3200
2850    EMail: davidb@verisign.com
2851
2852
2853
2854
2855
2856
2857
2858 Laurie, et al.              Standards Track                    [Page 51]
2859 \f
2860 RFC 5155                         NSEC3                        March 2008
2861
2862
2863 Full Copyright Statement
2864
2865    Copyright (C) The IETF Trust (2008).
2866
2867    This document is subject to the rights, licenses and restrictions
2868    contained in BCP 78, and except as set forth therein, the authors
2869    retain all their rights.
2870
2871    This document and the information contained herein are provided on an
2872    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2873    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
2874    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
2875    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
2876    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2877    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2878
2879 Intellectual Property
2880
2881    The IETF takes no position regarding the validity or scope of any
2882    Intellectual Property Rights or other rights that might be claimed to
2883    pertain to the implementation or use of the technology described in
2884    this document or the extent to which any license under such rights
2885    might or might not be available; nor does it represent that it has
2886    made any independent effort to identify any such rights.  Information
2887    on the procedures with respect to rights in RFC documents can be
2888    found in BCP 78 and BCP 79.
2889
2890    Copies of IPR disclosures made to the IETF Secretariat and any
2891    assurances of licenses to be made available, or the result of an
2892    attempt made to obtain a general license or permission for the use of
2893    such proprietary rights by implementers or users of this
2894    specification can be obtained from the IETF on-line IPR repository at
2895    http://www.ietf.org/ipr.
2896
2897    The IETF invites any interested party to bring to its attention any
2898    copyrights, patents or patent applications, or other proprietary
2899    rights that may cover technology that may be required to implement
2900    this standard.  Please address the information to the IETF at
2901    ietf-ipr@ietf.org.
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914 Laurie, et al.              Standards Track                    [Page 52]
2915 \f