contrib/bind9/doc/rfc/rfc4470.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          S. Weiler
   8 Request for Comments: 4470                                  SPARTA, Inc.
   9 Updates: 4035, 4034                                             J. Ihren
  10 Category: Standards Track                                  Autonomica AB
  11                                                               April 2006
  12
  13
  14        Minimally Covering NSEC Records and DNSSEC On-line Signing
  15
  16
  17 Status of This Memo
  18
  19    This document specifies an Internet standards track protocol for the
  20    Internet community, and requests discussion and suggestions for
  21    improvements.  Please refer to the current edition of the "Internet
  22    Official Protocol Standards" (STD 1) for the standardization state
  23    and status of this protocol.  Distribution of this memo is unlimited.
  24
  25 Copyright Notice
  26
  27    Copyright (C) The Internet Society (2006).
  28
  29 Abstract
  30
  31    This document describes how to construct DNSSEC NSEC resource records
  32    that cover a smaller range of names than called for by RFC 4034.  By
  33    generating and signing these records on demand, authoritative name
  34    servers can effectively stop the disclosure of zone contents
  35    otherwise made possible by walking the chain of NSEC records in a
  36    signed zone.
  37
  38 Table of Contents
  39
  40    1. Introduction ....................................................1
  41    2. Applicability of This Technique .................................2
  42    3. Minimally Covering NSEC Records .................................2
  43    4. Better Epsilon Functions ........................................4
  44    5. Security Considerations .........................................5
  45    6. Acknowledgements ................................................6
  46    7. Normative References ............................................6
  47
  48 1.  Introduction
  49
  50    With DNSSEC [1], an NSEC record lists the next instantiated name in
  51    its zone, proving that no names exist in the "span" between the
  52    NSEC's owner name and the name in the "next name" field.  In this
  53    document, an NSEC record is said to "cover" the names between its
  54    owner name and next name.
  55
  56
  57
  58 Weiler & Ihren              Standards Track                     [Page 1]
  59 \f
  60 RFC 4470                      NSEC Epsilon                    April 2006
  61
  62
  63    Through repeated queries that return NSEC records, it is possible to
  64    retrieve all of the names in the zone, a process commonly called
  65    "walking" the zone.  Some zone owners have policies forbidding zone
  66    transfers by arbitrary clients; this side effect of the NSEC
  67    architecture subverts those policies.
  68
  69    This document presents a way to prevent zone walking by constructing
  70    NSEC records that cover fewer names.  These records can make zone
  71    walking take approximately as many queries as simply asking for all
  72    possible names in a zone, making zone walking impractical.  Some of
  73    these records must be created and signed on demand, which requires
  74    on-line private keys.  Anyone contemplating use of this technique is
  75    strongly encouraged to review the discussion of the risks of on-line
  76    signing in Section 5.
  77
  78 1.2.  Keywords
  79
  80    The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  81    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  82    document are to be interpreted as described in RFC 2119 [4].
  83
  84 2.  Applicability of This Technique
  85
  86    The technique presented here may be useful to a zone owner that wants
  87    to use DNSSEC, is concerned about exposure of its zone contents via
  88    zone walking, and is willing to bear the costs of on-line signing.
  89
  90    As discussed in Section 5, on-line signing has several security
  91    risks, including an increased likelihood of private keys being
  92    disclosed and an increased risk of denial of service attack.  Anyone
  93    contemplating use of this technique is strongly encouraged to review
  94    the discussion of the risks of on-line signing in Section 5.
  95
  96    Furthermore, at the time this document was published, the DNSEXT
  97    working group was actively working on a mechanism to prevent zone
  98    walking that does not require on-line signing (tentatively called
  99    NSEC3).  The new mechanism is likely to expose slightly more
 100    information about the zone than this technique (e.g., the number of
 101    instantiated names), but it may be preferable to this technique.
 102
 103 3.  Minimally Covering NSEC Records
 104
 105    This mechanism involves changes to NSEC records for instantiated
 106    names, which can still be generated and signed in advance, as well as
 107    the on-demand generation and signing of new NSEC records whenever a
 108    name must be proven not to exist.
 109
 110
 111
 112
 113
 114 Weiler & Ihren              Standards Track                     [Page 2]
 115 \f
 116 RFC 4470                      NSEC Epsilon                    April 2006
 117
 118
 119    In the "next name" field of instantiated names' NSEC records, rather
 120    than list the next instantiated name in the zone, list any name that
 121    falls lexically after the NSEC's owner name and before the next
 122    instantiated name in the zone, according to the ordering function in
 123    RFC 4034 [2] Section 6.1.  This relaxes the requirement in Section
 124    4.1.1 of RFC 4034 that the "next name" field contains the next owner
 125    name in the zone.  This change is expected to be fully compatible
 126    with all existing DNSSEC validators.  These NSEC records are returned
 127    whenever proving something specifically about the owner name (e.g.,
 128    that no resource records of a given type appear at that name).
 129
 130    Whenever an NSEC record is needed to prove the non-existence of a
 131    name, a new NSEC record is dynamically produced and signed.  The new
 132    NSEC record has an owner name lexically before the QNAME but
 133    lexically following any existing name and a "next name" lexically
 134    following the QNAME but before any existing name.
 135
 136    The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
 137    bits set and SHOULD NOT have any other bits set.  This relaxes the
 138    requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
 139    names that did not exist before the zone was signed.
 140
 141    The functions to generate the lexically following and proceeding
 142    names need not be perfect or consistent, but the generated NSEC
 143    records must not cover any existing names.  Furthermore, this
 144    technique works best when the generated NSEC records cover as few
 145    names as possible.  In this document, the functions that generate the
 146    nearby names are called "epsilon" functions, a reference to the
 147    mathematical convention of using the greek letter epsilon to
 148    represent small deviations.
 149
 150    An NSEC record denying the existence of a wildcard may be generated
 151    in the same way.  Since the NSEC record covering a non-existent
 152    wildcard is likely to be used in response to many queries,
 153    authoritative name servers using the techniques described here may
 154    want to pregenerate or cache that record and its corresponding RRSIG.
 155
 156    For example, a query for an A record at the non-instantiated name
 157    example.com might produce the following two NSEC records, the first
 158    denying the existence of the name example.com and the second denying
 159    the existence of a wildcard:
 160
 161           exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
 162
 163           \).com 3600 IN NSEC +.com ( RRSIG NSEC )
 164
 165
 166
 167
 168
 169
 170 Weiler & Ihren              Standards Track                     [Page 3]
 171 \f
 172 RFC 4470                      NSEC Epsilon                    April 2006
 173
 174
 175    Before answering a query with these records, an authoritative server
 176    must test for the existence of names between these endpoints.  If the
 177    generated NSEC would cover existing names (e.g., exampldd.com or
 178    *bizarre.example.com), a better epsilon function may be used or the
 179    covered name closest to the QNAME could be used as the NSEC owner
 180    name or next name, as appropriate.  If an existing name is used as
 181    the NSEC owner name, that name's real NSEC record MUST be returned.
 182    Using the same example, assuming an exampldd.com delegation exists,
 183    this record might be returned from the parent:
 184
 185           exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
 186
 187    Like every authoritative record in the zone, each generated NSEC
 188    record MUST have corresponding RRSIGs generated using each algorithm
 189    (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
 190    described in RFC 4035 [3] Section 2.2.  To minimize the number of
 191    signatures that must be generated, a zone may wish to limit the
 192    number of algorithms in its DNSKEY RRset.
 193
 194 4.  Better Epsilon Functions
 195
 196    Section 6.1 of RFC 4034 defines a strict ordering of DNS names.
 197    Working backward from that definition, it should be possible to
 198    define epsilon functions that generate the immediately following and
 199    preceding names, respectively.  This document does not define such
 200    functions.  Instead, this section presents functions that come
 201    reasonably close to the perfect ones.  As described above, an
 202    authoritative server should still ensure than no generated NSEC
 203    covers any existing name.
 204
 205    To increment a name, add a leading label with a single null (zero-
 206    value) octet.
 207
 208    To decrement a name, decrement the last character of the leftmost
 209    label, then fill that label to a length of 63 octets with octets of
 210    value 255.  To decrement a null (zero-value) octet, remove the octet
 211    -- if an empty label is left, remove the label.  Defining this
 212    function numerically: fill the leftmost label to its maximum length
 213    with zeros (numeric, not ASCII zeros) and subtract one.
 214
 215    In response to a query for the non-existent name foo.example.com,
 216    these functions produce NSEC records of the following:
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Weiler & Ihren              Standards Track                     [Page 4]
 227 \f
 228 RFC 4470                      NSEC Epsilon                    April 2006
 229
 230
 231      fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
 232      \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
 233      \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
 234      \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
 235      \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
 236
 237      \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
 238      \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
 239      \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
 240      \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
 241      \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
 242
 243    The first of these NSEC RRs proves that no exact match for
 244    foo.example.com exists, and the second proves that there is no
 245    wildcard in example.com.
 246
 247    Both of these functions are imperfect: they do not take into account
 248    constraints on number of labels in a name nor total length of a name.
 249    As noted in the previous section, though, this technique does not
 250    depend on the use of perfect epsilon functions: it is sufficient to
 251    test whether any instantiated names fall into the span covered by the
 252    generated NSEC and, if so, substitute those instantiated owner names
 253    for the NSEC owner name or next name, as appropriate.
 254
 255 5.  Security Considerations
 256
 257    This approach requires on-demand generation of RRSIG records.  This
 258    creates several new vulnerabilities.
 259
 260    First, on-demand signing requires that a zone's authoritative servers
 261    have access to its private keys.  Storing private keys on well-known
 262    Internet-accessible servers may make them more vulnerable to
 263    unintended disclosure.
 264
 265    Second, since generation of digital signatures tends to be
 266    computationally demanding, the requirement for on-demand signing
 267    makes authoritative servers vulnerable to a denial of service attack.
 268
 269    Last, if the epsilon functions are predictable, on-demand signing may
 270    enable a chosen-plaintext attack on a zone's private keys.  Zones
 271    using this approach should attempt to use cryptographic algorithms
 272    that are resistant to chosen-plaintext attacks.  It is worth noting
 273    that although DNSSEC has a "mandatory to implement" algorithm, that
 274    is a requirement on resolvers and validators -- there is no
 275    requirement that a zone be signed with any given algorithm.
 276
 277    The success of using minimally covering NSEC records to prevent zone
 278    walking depends greatly on the quality of the epsilon functions
 279
 280
 281
 282 Weiler & Ihren              Standards Track                     [Page 5]
 283 \f
 284 RFC 4470                      NSEC Epsilon                    April 2006
 285
 286
 287    chosen.  An increment function that chooses a name obviously derived
 288    from the next instantiated name may be easily reverse engineered,
 289    destroying the value of this technique.  An increment function that
 290    always returns a name close to the next instantiated name is likewise
 291    a poor choice.  Good choices of epsilon functions are the ones that
 292    produce the immediately following and preceding names, respectively,
 293    though zone administrators may wish to use less perfect functions
 294    that return more human-friendly names than the functions described in
 295    Section 4 above.
 296
 297    Another obvious but misguided concern is the danger from synthesized
 298    NSEC records being replayed.  It is possible for an attacker to
 299    replay an old but still validly signed NSEC record after a new name
 300    has been added in the span covered by that NSEC, incorrectly proving
 301    that there is no record at that name.  This danger exists with DNSSEC
 302    as defined in [3].  The techniques described here actually decrease
 303    the danger, since the span covered by any NSEC record is smaller than
 304    before.  Choosing better epsilon functions will further reduce this
 305    danger.
 306
 307 6.  Acknowledgements
 308
 309    Many individuals contributed to this design.  They include, in
 310    addition to the authors of this document, Olaf Kolkman, Ed Lewis,
 311    Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
 312    Jakob Schlyter, Bill Manning, and Joao Damas.
 313
 314    In addition, the editors would like to thank Ed Lewis, Scott Rose,
 315    and David Blacka for their careful review of the document.
 316
 317 7.  Normative References
 318
 319    [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
 320         "DNS Security Introduction and Requirements", RFC 4033, March
 321         2005.
 322
 323    [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
 324         "Resource Records for the DNS Security Extensions", RFC 4034,
 325         March 2005.
 326
 327    [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
 328         "Protocol Modifications for the DNS Security Extensions", RFC
 329         4035, March 2005.
 330
 331    [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 332         Levels", BCP 14, RFC 2119, March 1997.
 333
 334
 335
 336
 337
 338 Weiler & Ihren              Standards Track                     [Page 6]
 339 \f
 340 RFC 4470                      NSEC Epsilon                    April 2006
 341
 342
 343 Authors' Addresses
 344
 345    Samuel Weiler
 346    SPARTA, Inc.
 347    7075 Samuel Morse Drive
 348    Columbia, Maryland  21046
 349    US
 350
 351    EMail: weiler@tislabs.com
 352
 353
 354    Johan Ihren
 355    Autonomica AB
 356    Bellmansgatan 30
 357    Stockholm  SE-118 47
 358    Sweden
 359
 360    EMail: johani@autonomica.se
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Weiler & Ihren              Standards Track                     [Page 7]
 395 \f
 396 RFC 4470                      NSEC Epsilon                    April 2006
 397
 398
 399 Full Copyright Statement
 400
 401    Copyright (C) The Internet Society (2006).
 402
 403    This document is subject to the rights, licenses and restrictions
 404    contained in BCP 78, and except as set forth therein, the authors
 405    retain all their rights.
 406
 407    This document and the information contained herein are provided on an
 408    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 409    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 410    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 411    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 412    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 413    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 414
 415 Intellectual Property
 416
 417    The IETF takes no position regarding the validity or scope of any
 418    Intellectual Property Rights or other rights that might be claimed to
 419    pertain to the implementation or use of the technology described in
 420    this document or the extent to which any license under such rights
 421    might or might not be available; nor does it represent that it has
 422    made any independent effort to identify any such rights.  Information
 423    on the procedures with respect to rights in RFC documents can be
 424    found in BCP 78 and BCP 79.
 425
 426    Copies of IPR disclosures made to the IETF Secretariat and any
 427    assurances of licenses to be made available, or the result of an
 428    attempt made to obtain a general license or permission for the use of
 429    such proprietary rights by implementers or users of this
 430    specification can be obtained from the IETF on-line IPR repository at
 431    http://www.ietf.org/ipr.
 432
 433    The IETF invites any interested party to bring to its attention any
 434    copyrights, patents or patent applications, or other proprietary
 435    rights that may cover technology that may be required to implement
 436    this standard.  Please address the information to the IETF at
 437    ietf-ipr@ietf.org.
 438
 439 Acknowledgement
 440
 441    Funding for the RFC Editor function is provided by the IETF
 442    Administrative Support Activity (IASA).
 443
 444
 445
 446
 447
 448
 449
 450 Weiler & Ihren              Standards Track                     [Page 8]
 451 \f