external/bsd/bind/dist/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-01.txt

   1
   2
   3
   4 DNSEXT                                                         R. Bellis
   5 Internet-Draft                                                Nominet UK
   6 Updates: 1035, 1123                                     October 26, 2009
   7 (if approved)
   8 Intended status: Standards Track
   9 Expires: April 29, 2010
  10
  11
  12                          DNS Transport over TCP
  13                draft-ietf-dnsext-dns-tcp-requirements-01
  14
  15 Status of this Memo
  16
  17    This Internet-Draft is submitted to IETF in full conformance with the
  18    provisions of BCP 78 and BCP 79.
  19
  20    Internet-Drafts are working documents of the Internet Engineering
  21    Task Force (IETF), its areas, and its working groups.  Note that
  22    other groups may also distribute working documents as Internet-
  23    Drafts.
  24
  25    Internet-Drafts are draft documents valid for a maximum of six months
  26    and may be updated, replaced, or obsoleted by other documents at any
  27    time.  It is inappropriate to use Internet-Drafts as reference
  28    material or to cite them other than as "work in progress."
  29
  30    The list of current Internet-Drafts can be accessed at
  31    http://www.ietf.org/ietf/1id-abstracts.txt.
  32
  33    The list of Internet-Draft Shadow Directories can be accessed at
  34    http://www.ietf.org/shadow.html.
  35
  36    This Internet-Draft will expire on April 29, 2010.
  37
  38 Copyright Notice
  39
  40    Copyright (c) 2009 IETF Trust and the persons identified as the
  41    document authors.  All rights reserved.
  42
  43    This document is subject to BCP 78 and the IETF Trust's Legal
  44    Provisions Relating to IETF Documents in effect on the date of
  45    publication of this document (http://trustee.ietf.org/license-info).
  46    Please review these documents carefully, as they describe your rights
  47    and restrictions with respect to this document.
  48
  49 Abstract
  50
  51    This document updates the requirements for the support of the TCP
  52
  53
  54
  55 Bellis                   Expires April 29, 2010                 [Page 1]
  56 \f
  57 Internet-Draft           DNS Transport over TCP             October 2009
  58
  59
  60    protocol for the transport of DNS traffic.
  61
  62
  63 Table of Contents
  64
  65    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  66
  67    2.  Terminology used in this document . . . . . . . . . . . . . . . 3
  68
  69    3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
  70
  71    4.  Transport Protocol Selection  . . . . . . . . . . . . . . . . . 4
  72
  73    5.  Dormant Connection Handling . . . . . . . . . . . . . . . . . . 5
  74
  75    6.  Response re-ordering  . . . . . . . . . . . . . . . . . . . . . 6
  76
  77    7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
  78
  79    8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
  80
  81    9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  82      9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
  83      9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
  84
  85    Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . . . 7
  86
  87    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Bellis                   Expires April 29, 2010                 [Page 2]
 112 \f
 113 Internet-Draft           DNS Transport over TCP             October 2009
 114
 115
 116 1.  Introduction
 117
 118    Most DNS [RFC1035] transactions take place over the UDP [RFC0792]
 119    protocol.  The TCP [RFC0793] protocol is used for zone transfers and
 120    is supported by many implementations for the transfer of other
 121    packets which exceed the protocol's original 512 byte packet-size
 122    limit.
 123
 124    Section 6.1.3.2 of [RFC1123] states:
 125
 126       DNS resolvers and recursive servers MUST support UDP, and SHOULD
 127       support TCP, for sending (non-zone-transfer) queries.
 128
 129    However, some implementors have taken the text quoted above to mean
 130    that TCP support is truly optional for typical DNS operation.
 131
 132    This document normatively updates the core DNS protocol
 133    specifications such that (except in very limited circumstances)
 134    support for the TCP protocol is henceforth REQUIRED.
 135
 136
 137 2.  Terminology used in this document
 138
 139    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 140    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 141    document are to be interpreted as described in [RFC2119].
 142
 143
 144 3.  Discussion
 145
 146    In the absence of EDNS0 (see below) the normal behaviour of any DNS
 147    server needing to send a UDP response that exceeds that 512 byte
 148    limit is for the server to truncate the response at the 512 byte
 149    limit and set the TC flag in the response header.  When the client
 150    receives such a response it takes the TC flag as notice that it
 151    should retry over TCP instead.
 152
 153    RFC 1123 also says:
 154
 155       ... it is also clear that some new DNS record types defined in the
 156       future will contain information exceeding the 512 byte limit that
 157       applies to UDP, and hence will require TCP.  Thus, resolvers and
 158       name servers should implement TCP services as a backup to UDP
 159       today, with the knowledge that they will require the TCP service
 160       in the future.
 161
 162    Existing deployments of DNSSEC [RFC4033] have shown that truncation
 163    at the 512 byte boundary is now commonplace.  For example an NXDOMAIN
 164
 165
 166
 167 Bellis                   Expires April 29, 2010                 [Page 3]
 168 \f
 169 Internet-Draft           DNS Transport over TCP             October 2009
 170
 171
 172    (RCODE == 3) response from a DNSSEC signed zone using NSEC3 [RFC5155]
 173    is almost invariably longer than 512 bytes.
 174
 175    Since the original core specifications for DNS were written, the
 176    Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced.
 177    These extensions can be used to indicate that the client is prepared
 178    to receive UDP responses longer than 512 bytes.  An EDNS0 compatible
 179    server receiving a request from an EDNS0 compatible client may send
 180    UDP packets up to that client's announced buffer size without
 181    truncation.
 182
 183    However, transport of UDP packets which exceed the size of the path
 184    MTU has been found to be unreliable in some circumstances because of
 185    IP packet fragmentation.  Many firewalls routinely block fragmented
 186    IP packets, and some implementations lack the software logic
 187    necessary to reassemble a fragmented datagram.  Worse still, some
 188    devices deliberately refuse to handle DNS packets containing EDNS0
 189    options.  Other issues relating to UDP transport and packet size are
 190    discussed in [RFC5625].
 191
 192    The MTU most commonly found in the core of the Internet is around
 193    1500 bytes, and even that limit is routinely exceeded by DNSSEC
 194    signed responses.
 195
 196    The future that was anticipated in RFC 1123 has arrived, and the only
 197    standardised mechanism which may have resolved the packet size issue
 198    has been found inadequate.
 199
 200
 201 4.  Transport Protocol Selection
 202
 203    All DNS implementations MUST support both UDP and TCP transport
 204    protocols, except as set out below.
 205
 206    On a case by case basis, authoritative DNS server operators MAY elect
 207    to disable DNS transport over TCP if all of the following conditions
 208    are satisfied:
 209
 210    o  the server is authoritative only
 211    o  the server does not support AXFR
 212    o  all requests and responses are guaranteed to be <= 512 bytes
 213
 214    A general purpose stub resolver implementation (e.g. an operating
 215    system's DNS resolution library) MUST support TCP since to do
 216    otherwise would limit its interoperability with its own clients and
 217    with upstream servers.
 218
 219    A proprietary stub resolver implementation MAY omit support for TCP
 220
 221
 222
 223 Bellis                   Expires April 29, 2010                 [Page 4]
 224 \f
 225 Internet-Draft           DNS Transport over TCP             October 2009
 226
 227
 228    if it is operating in an environment where truncation can never
 229    occur, or if it is prepared to accept a DNS lookup failure should
 230    truncation occur.
 231
 232    A recursive resolver or forwarder MUST support TCP so that it does
 233    not prevent long responses from a TCP-capable server from reaching
 234    its TCP-capable clients.
 235
 236    Regarding the choice of when to use UDP or TCP, RFC 1123 says:
 237
 238       ... a DNS resolver or server that is sending a non-zone-transfer
 239       query MUST send a UDP query first.
 240
 241    That requirement is hereby relaxed.  A resolver SHOULD send a UDP
 242    query first, but MAY elect to send a TCP query instead if it has good
 243    reason to expect the response would be truncated if it were sent over
 244    UDP (with or without EDNS0) or for other operational reasons.
 245
 246
 247 5.  Dormant Connection Handling
 248
 249    Section 4.2.2 of [RFC1035] says:
 250
 251       If the server needs to close a dormant connection to reclaim
 252       resources, it should wait until the connection has been idle for a
 253       period on the order of two minutes.
 254
 255    Other more modern protocols (e.g.  HTTP [RFC2616]) have support for
 256    persistent TCP connections and operational experience has shown that
 257    long timeouts can easily cause resource exhaustion and poor response
 258    under heavy load.  Intentionally opening many connections and leaving
 259    them dormant can trivially create a "denial of service" attack.
 260
 261    This document therefore RECOMMENDS that the idle period should be of
 262    the order of TBD seconds.
 263
 264    Servers MAY allow dormant connections to remain open for longer
 265    periods, but for the avoidance of doubt persistent DNS connections
 266    should generally be considered to be as much for the server's benefit
 267    as for the client's.  Therefore if the server needs to unilaterally
 268    close a dormant TCP connection it MUST be free to do so whenever
 269    required.
 270
 271    Further recommendations for the tuning of TCP parameters to allow
 272    higher throughput or improved resiliency against denial of service
 273    attacks are (currently) outside the scope of this document.
 274
 275
 276
 277
 278
 279 Bellis                   Expires April 29, 2010                 [Page 5]
 280 \f
 281 Internet-Draft           DNS Transport over TCP             October 2009
 282
 283
 284 6.  Response re-ordering
 285
 286    RFC 1035 is ambiguous on the question of whether TCP queries may be
 287    re-ordered - the only relevant text is in Section 4.2.1 which relates
 288    to UDP:
 289
 290       Queries or their responses may be reordered by the network, or by
 291       processing in name servers, so resolvers should not depend on them
 292       being returned in order.
 293
 294    For the avoidance of future doubt, this requirement is clarified.
 295    Client resolvers MUST be able to process responses which arrive in a
 296    different order to that in which the requests were sent, regardless
 297    of the transport protocol in use.
 298
 299
 300 7.  Security Considerations
 301
 302    Some DNS server operators have expressed concern that wider use of
 303    DNS over TCP will expose them to a higher risk of "denial of service"
 304    attacks.
 305
 306    Many large authoritative DNS operators including all but one of the
 307    root servers and the vast majority of TLDs already support TCP and
 308    attacks against them are infrequent and very rarely successful.
 309
 310    Operators of recursive servers should ensure that they only accept
 311    connections from expected clients, and do not accept them from
 312    unknown sources.  In the case of UDP traffic this will protect
 313    against reflector attacks [RFC5358] and in the case of TCP traffic it
 314    will prevent an unknown client from exhausting the server's limits on
 315    the number of concurrent connections.
 316
 317
 318 8.  IANA Considerations
 319
 320    This document requests no IANA actions.
 321
 322
 323 9.  References
 324
 325 9.1.  Normative References
 326
 327    [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
 328               RFC 792, September 1981.
 329
 330    [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
 331               RFC 793, September 1981.
 332
 333
 334
 335 Bellis                   Expires April 29, 2010                 [Page 6]
 336 \f
 337 Internet-Draft           DNS Transport over TCP             October 2009
 338
 339
 340    [RFC1035]  Mockapetris, P., "Domain names - implementation and
 341               specification", STD 13, RFC 1035, November 1987.
 342
 343    [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
 344               and Support", STD 3, RFC 1123, October 1989.
 345
 346    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 347               Requirement Levels", BCP 14, RFC 2119, March 1997.
 348
 349    [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
 350               RFC 2671, August 1999.
 351
 352 9.2.  Informative References
 353
 354    [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
 355               Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
 356               Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
 357
 358    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
 359               Rose, "DNS Security Introduction and Requirements",
 360               RFC 4033, March 2005.
 361
 362    [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
 363               Security (DNSSEC) Hashed Authenticated Denial of
 364               Existence", RFC 5155, March 2008.
 365
 366    [RFC5358]  Damas, J. and F. Neves, "Preventing Use of Recursive
 367               Nameservers in Reflector Attacks", BCP 140, RFC 5358,
 368               October 2008.
 369
 370    [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
 371               BCP 152, RFC 5625, August 2009.
 372
 373
 374 Appendix A.  Change Log
 375
 376    NB: to be removed by the RFC Editor before publication.
 377
 378    draft-ietf-dnsext-dns-tcp-requirements-01
 379       Addition of response ordering section
 380       Various minor editorial changes from WG reviewers
 381
 382    draft-ietf-dnsext-dns-tcp-requirements-00
 383       Initial draft
 384
 385
 386
 387
 388
 389
 390
 391 Bellis                   Expires April 29, 2010                 [Page 7]
 392 \f
 393 Internet-Draft           DNS Transport over TCP             October 2009
 394
 395
 396 Author's Address
 397
 398    Ray Bellis
 399    Nominet UK
 400    Edmund Halley Road
 401    Oxford  OX4 4DQ
 402    United Kingdom
 403
 404    Phone: +44 1865 332211
 405    Email: ray.bellis@nominet.org.uk
 406    URI:   http://www.nominet.org.uk/
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447 Bellis                   Expires April 29, 2010                 [Page 8]
 448 \f