contrib/bind9/doc/rfc/rfc3225.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          D. Conrad
   8 Request for Comments: 3225                                 Nominum, Inc.
   9 Category: Standards Track                                  December 2001
  10
  11
  12                  Indicating Resolver Support of DNSSEC
  13
  14 Status of this Memo
  15
  16    This document specifies an Internet standards track protocol for the
  17    Internet community, and requests discussion and suggestions for
  18    improvements.  Please refer to the current edition of the "Internet
  19    Official Protocol Standards" (STD 1) for the standardization state
  20    and status of this protocol.  Distribution of this memo is unlimited.
  21
  22 Copyright Notice
  23
  24    Copyright (C) The Internet Society (2001).  All Rights Reserved.
  25
  26 Abstract
  27
  28    In order to deploy DNSSEC (Domain Name System Security Extensions)
  29    operationally, DNSSEC aware servers should only perform automatic
  30    inclusion of DNSSEC RRs when there is an explicit indication that the
  31    resolver can understand those RRs.  This document proposes the use of
  32    a bit in the EDNS0 header to provide that explicit indication and
  33    describes the necessary protocol changes to implement that
  34    notification.
  35
  36 1. Introduction
  37
  38    DNSSEC [RFC2535] has been specified to provide data integrity and
  39    authentication to security aware resolvers and applications through
  40    the use of cryptographic digital signatures.  However, as DNSSEC is
  41    deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware
  42    servers.  In such situations, the DNSSEC-aware server (responding to
  43    a request for data in a signed zone) will respond with SIG, KEY,
  44    and/or NXT records.  For reasons described in the subsequent section,
  45    such responses can have significant negative operational impacts for
  46    the DNS infrastructure.
  47
  48    This document discusses a method to avoid these negative impacts,
  49    namely DNSSEC-aware servers should only respond with SIG, KEY, and/or
  50    NXT RRs when there is an explicit indication from the resolver that
  51    it can understand those RRs.
  52
  53    For the purposes of this document, "DNSSEC security RRs" are
  54    considered RRs of type SIG, KEY, or NXT.
  55
  56
  57
  58 Conrad                      Standards Track                     [Page 1]
  59 \f
  60 RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
  61
  62
  63    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  64    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  65    document are to be interpreted as described in [RFC2119].
  66
  67 2. Rationale
  68
  69    Initially, as DNSSEC is deployed, the vast majority of queries will
  70    be from resolvers that are not DNSSEC aware and thus do not
  71    understand or support the DNSSEC security RRs.  When a query from
  72    such a resolver is received for a DNSSEC signed zone, the DNSSEC
  73    specification indicates the nameserver must respond with the
  74    appropriate DNSSEC security RRs.  As DNS UDP datagrams are limited to
  75    512 bytes [RFC1035], responses including DNSSEC security RRs have a
  76    high probability of resulting in a truncated response being returned
  77    and the resolver retrying the query using TCP.
  78
  79    TCP DNS queries result in significant overhead due to connection
  80    setup and teardown.  Operationally, the impact of these TCP queries
  81    will likely be quite detrimental in terms of increased network
  82    traffic (typically five packets for a single query/response instead
  83    of two), increased latency resulting from the additional round trip
  84    times, increased incidences of queries failing due to timeouts, and
  85    significantly increased load on nameservers.
  86
  87    In addition, in preliminary and experimental deployment of DNSSEC,
  88    there have been reports of non-DNSSEC aware resolvers being unable to
  89    handle responses which contain DNSSEC security RRs, resulting in the
  90    resolver failing (in the worst case) or entire responses being
  91    ignored (in the better case).
  92
  93    Given these operational implications, explicitly notifying the
  94    nameserver that the client is prepared to receive (if not understand)
  95    DNSSEC security RRs would be prudent.
  96
  97    Client-side support of DNSSEC is assumed to be binary -- either the
  98    client is willing to receive all DNSSEC security RRs or it is not
  99    willing to accept any.  As such, a single bit is sufficient to
 100    indicate client-side DNSSEC support.  As effective use of DNSSEC
 101    implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS
 102    enhanced DNS header) are scarce, and there may be situations in which
 103    non-compliant caching or forwarding servers inappropriately copy data
 104    from classic headers as queries are passed on to authoritative
 105    servers, the use of a bit from the EDNS0 header is proposed.
 106
 107    An alternative approach would be to use the existence of an EDNS0
 108    header as an implicit indication of client-side support of DNSSEC.
 109    This approach was not chosen as there may be applications in which
 110    EDNS0 is supported but in which the use of DNSSEC is inappropriate.
 111
 112
 113
 114 Conrad                      Standards Track                     [Page 2]
 115 \f
 116 RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
 117
 118
 119 3. Protocol Changes
 120
 121    The mechanism chosen for the explicit notification of the ability of
 122    the client to accept (if not understand) DNSSEC security RRs is using
 123    the most significant bit of the Z field on the EDNS0 OPT header in
 124    the query.  This bit is referred to as the "DNSSEC OK" (DO) bit.  In
 125    the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of
 126    the third and fourth bytes of the "extended RCODE and flags" portion
 127    of the EDNS0 OPT meta-RR, structured as follows:
 128
 129                 +0 (MSB)                +1 (LSB)
 130          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 131       0: |   EXTENDED-RCODE      |       VERSION         |
 132          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 133       2: |DO|                    Z                       |
 134          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 135
 136    Setting the DO bit to one in a query indicates to the server that the
 137    resolver is able to accept DNSSEC security RRs.  The DO bit cleared
 138    (set to zero) indicates the resolver is unprepared to handle DNSSEC
 139    security RRs and those RRs MUST NOT be returned in the response
 140    (unless DNSSEC security RRs are explicitly queried for).  The DO bit
 141    of the query MUST be copied in the response.
 142
 143    More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
 144    or NXT RRs to authenticate a response as specified in [RFC2535]
 145    unless the DO bit was set on the request.  Security records that
 146    match an explicit SIG, KEY, NXT, or ANY query, or are part of the
 147    zone data for an AXFR or IXFR query, are included whether or not the
 148    DO bit was set.
 149
 150    A recursive DNSSEC-aware server MUST set the DO bit on recursive
 151    requests, regardless of the status of the DO bit on the initiating
 152    resolver request.  If the initiating resolver request does not have
 153    the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC
 154    security RRs before returning the data to the client, however cached
 155    data MUST NOT be modified.
 156
 157    In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
 158    to a query that has the DO bit set, the resolver SHOULD NOT expect
 159    DNSSEC security RRs and SHOULD retry the query without EDNS0 in
 160    accordance with section 5.3 of [RFC2671].
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170 Conrad                      Standards Track                     [Page 3]
 171 \f
 172 RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
 173
 174
 175 Security Considerations
 176
 177    The absence of DNSSEC data in response to a query with the DO bit set
 178    MUST NOT be taken to mean no security information is available for
 179    that zone as the response may be forged or a non-forged response of
 180    an altered (DO bit cleared) query.
 181
 182 IANA Considerations
 183
 184    EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record,
 185    these bits are encoded into the TTL field of the OPT record (RFC2671
 186    section 4.6).
 187
 188    This document reserves one of these bits as the OK bit.  It is
 189    requested that the left most bit be allocated.  Thus the USE of the
 190    OPT record TTL field would look like
 191
 192                 +0 (MSB)                +1 (LSB)
 193          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 194       0: |   EXTENDED-RCODE      |       VERSION         |
 195          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 196       2: |DO|                    Z                       |
 197          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 198
 199 Acknowledgements
 200
 201    This document is based on a rough draft by Bob Halley with input from
 202    Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush,
 203    Rob Austein, Steve Bellovin, and Erik Nordmark.
 204
 205 References
 206
 207    [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
 208              STD 13, RFC 1034, November 1987.
 209
 210    [RFC1035] Mockapetris, P., "Domain Names - Implementation and
 211              Specifications", STD 13, RFC 1035, November 1987.
 212
 213    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 214              Requirement Levels", BCP 14, RFC 2119, March 1997.
 215
 216    [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
 217              2535, March 1999.
 218
 219    [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
 220              2671, August 1999.
 221
 222
 223
 224
 225
 226 Conrad                      Standards Track                     [Page 4]
 227 \f
 228 RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
 229
 230
 231 Author's Address
 232
 233    David Conrad
 234    Nominum Inc.
 235    950 Charter Street
 236    Redwood City, CA 94063
 237    USA
 238
 239    Phone: +1 650 381 6003
 240    EMail: david.conrad@nominum.com
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Conrad                      Standards Track                     [Page 5]
 283 \f
 284 RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
 285
 286
 287 Full Copyright Statement
 288
 289    Copyright (C) The Internet Society (2001).  All Rights Reserved.
 290
 291    This document and translations of it may be copied and furnished to
 292    others, and derivative works that comment on or otherwise explain it
 293    or assist in its implementation may be prepared, copied, published
 294    and distributed, in whole or in part, without restriction of any
 295    kind, provided that the above copyright notice and this paragraph are
 296    included on all such copies and derivative works.  However, this
 297    document itself may not be modified in any way, such as by removing
 298    the copyright notice or references to the Internet Society or other
 299    Internet organizations, except as needed for the purpose of
 300    developing Internet standards in which case the procedures for
 301    copyrights defined in the Internet Standards process must be
 302    followed, or as required to translate it into languages other than
 303    English.
 304
 305    The limited permissions granted above are perpetual and will not be
 306    revoked by the Internet Society or its successors or assigns.
 307
 308    This document and the information contained herein is provided on an
 309    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 310    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 311    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 312    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 313    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 314
 315 Acknowledgement
 316
 317    Funding for the RFC Editor function is currently provided by the
 318    Internet Society.
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Conrad                      Standards Track                     [Page 6]
 339 \f