idnits 2.17.1 draft-ietf-dnsop-edns-tcp-keepalive-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2016) is 2984 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop P. Wouters 3 Internet-Draft Red Hat 4 Intended status: Standards Track J. Abley 5 Expires: August 25, 2016 Dyn, Inc. 6 S. Dickinson 7 Sinodun 8 R. Bellis 9 ISC 10 February 22, 2016 12 The edns-tcp-keepalive EDNS0 Option 13 draft-ietf-dnsop-edns-tcp-keepalive-06 15 Abstract 17 DNS messages between clients and servers may be received over either 18 UDP or TCP. UDP transport involves keeping less state on a busy 19 server, but can cause truncation and retries over TCP. Additionally, 20 UDP can be exploited for reflection attacks. Using TCP would reduce 21 retransmits and amplification. However, clients commonly use TCP 22 only for retries and servers typically use idle timeouts on the order 23 of seconds. 25 This document defines an EDNS0 option ("edns-tcp-keepalive") that 26 allows DNS servers to signal a variable idle timeout. This 27 signalling encourages the use of long-lived TCP connections by 28 allowing the state associated with TCP transport to be managed 29 effectively with minimal impact on the DNS transaction time. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 25, 2016. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 67 3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 5 68 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5 69 3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 5 70 3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5 71 3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 6 72 3.3. Use by DNS Servers . . . . . . . . . . . . . . . . . . . 6 73 3.3.1. Receiving Queries . . . . . . . . . . . . . . . . . . 6 74 3.3.2. Sending Responses . . . . . . . . . . . . . . . . . . 6 75 3.4. TCP Session Management . . . . . . . . . . . . . . . . . 7 76 3.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 8 77 3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 8 78 4. Intermediary Considerations . . . . . . . . . . . . . . . . . 8 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 8.2. Informative References . . . . . . . . . . . . . . . . . 10 85 Appendix A. Editors' Notes . . . . . . . . . . . . . . . . . . . 11 86 A.1. Abridged Change History . . . . . . . . . . . . . . . . . 11 87 A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-06 . . . . . . . 11 88 A.1.2. draft-ietf-dnsop-edns-tcp-keepalive-05 . . . . . . . 11 89 A.1.3. draft-ietf-dnsop-edns-tcp-keepalive-04 . . . . . . . 12 90 A.1.4. draft-ietf-dnsop-edns-tcp-keepalive-03 . . . . . . . 12 91 A.1.5. draft-ietf-dnsop-edns-tcp-keepalive-02 . . . . . . . 12 92 A.1.6. draft-ietf-dnsop-edns-tcp-keepalive-01 . . . . . . . 13 93 A.1.7. draft-ietf-dnsop-edns-tcp-keepalive-00 . . . . . . . 13 94 A.1.8. draft-wouters-edns-tcp-keepalive-01 . . . . . . . . . 13 95 A.1.9. draft-wouters-edns-tcp-keepalive-00 . . . . . . . . . 13 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 99 1. Introduction 101 DNS messages between clients and servers may be received over either 102 UDP or TCP [RFC1035]. Historically, DNS clients used API's that only 103 facilitated sending and receiving a single query over either UDP or 104 TCP. New APIs and deployment of DNSSEC validating resolvers on hosts 105 that in the past were using stub resolving only is increasing the DNS 106 client base that prefer using long lived TCP connections. Long-lived 107 TCP connections can result in lower request latency than the case 108 where UDP transport is used and truncated responses are received. 109 This is because clients that retry over TCP following a truncated UDP 110 response typically only use the TCP session for a single (request, 111 response) pair, continuing with UDP transport for subsequent queries. 113 The use of TCP transport requires state to be retained on DNS 114 servers. If a server is to perform adequately with a significant 115 query load received over TCP, it must manage its available resources 116 to ensure that all established TCP sessions are well-used, and idle 117 connections are closed after an appropriate amount of time. 119 UDP transport is stateless, and hence presents a much lower resource 120 burden on a busy DNS server than TCP. An exchange of DNS messages 121 over UDP can also be completed in a single round trip between 122 communicating hosts, resulting in optimally-short transaction times. 123 UDP transport is not without its risks, however. 125 A single-datagram exchange over UDP between two hosts can be 126 exploited to enable a reflection attack on a third party. Response 127 Rate Limiting [RRL] is designed to help mitigate such attacks against 128 authoritative-only servers. One feature of RRL is to let some amount 129 of responses "slip" through the rate limiter. These are returned 130 with the TC (truncation) bit set, which causes legitimate clients to 131 re-query using TCP transport. 133 [RFC1035] specified a maximum DNS message size over UDP transport of 134 512 bytes. Deployment of DNSSEC [RFC4033] and other protocols 135 subsequently increased the observed frequency at which responses 136 exceed this limit. EDNS0 [RFC6891] allows DNS messages larger than 137 512 bytes to be exchanged over UDP, with a corresponding increased 138 incidence of fragmentation. Fragmentation is known to be problematic 139 in general, and has also been implicated in increasing the risk of 140 cache poisoning attacks [fragmentation-considered-poisonous]. 142 TCP transport is less susceptible to the risks of fragmentation and 143 reflection attacks. However, TCP transport for DNS as currently 144 deployed has expensive setup overhead, compared to using UDP (when no 145 retry is required). 147 The overhead of the three-way TCP handshake for a single DNS 148 transaction is substantial, increasing the transaction time for a 149 single (request, response) pair of DNS messages from 1 x RTT to 2 x 150 RTT. There is no such overhead for a session that is already 151 established therefore the overhead of the initial TCP handshake is 152 minimised when the resulting session is used to exchange multiple DNS 153 message pairs over a single session. The extra RTT time for session 154 setup can be represented as the equation (1 + N)/N, where N 155 represents the number of DNS message pairs that utilize the session 156 and the result approaches unity as N increases. 158 With increased deployment of DNSSEC and new RRtypes containing 159 application specific cryptographic material, there is an increase in 160 the prevalence of truncated responses received over UDP with retries 161 over TCP. The overhead for a DNS transaction over UDP truncated due 162 to RRL is 3x RTT, higher than the overhead imposed on the same 163 transaction initiated over TCP. 165 This document proposes a signalling mechanism between DNS clients and 166 servers that encourages the use of long-lived TCP connections by 167 allowing the state associated with TCP transport to be managed 168 effectively with minimal impact on the DNS transaction time. 170 This mechanism will be of benefit both for stub-resolver and 171 resolver-authoritative TCP connections. In the latter case the 172 persistent nature of the TCP connection can provide improved defence 173 against attacks including DDoS. 175 The reduced overhead of this extension adds up significantly when 176 combined with other EDNS0 extensions, such as [CHAIN-QUERY] and 177 [DNS-over-TLS]. For example, the combination of these EDNS0 178 extensions make it possible for hosts on high-latency mobile networks 179 to natively and efficiently perform DNSSEC validation and encrypt 180 queries. 182 2. Requirements Notation 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 3. The edns-tcp-keepalive Option 190 This document specifies a new EDNS0 [RFC6891] option, edns-tcp- 191 keepalive, which can be used by DNS clients and servers to signal a 192 willingness to keep an idle TCP session open to conduct future DNS 193 transactions, with the idle timeout being specified by the server. 194 This specification does not distinguish between different types of 195 DNS client and server in the use of this option. 197 [DRAFT-5966bis] defines an 'idle' DNS-over-TCP session from both the 198 client and server perspective. The idle timeout described here 199 begins when the idle condition is met per that definition and should 200 be reset when that condition is lifted i.e. when a client sends a 201 message or when a server receives a message on an idle connection. 203 3.1. Option Format 205 The edns-tcp-keepalive option is encoded as follows: 207 1 2 3 208 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 209 +-------------------------------+-------------------------------+ 210 ! OPTION-CODE ! OPTION-LENGTH ! 211 +-------------------------------+-------------------------------+ 212 | TIMEOUT ! 213 +-------------------------------+ 215 where: 217 OPTION-CODE: the EDNS0 option code assigned to edns-tcp-keepalive, 218 TBD1 220 OPTION-LENGTH: the value 0 if the TIMEOUT is omitted, the value 2 221 if it is present; 223 TIMEOUT: an idle timeout value for the TCP connection, specified in 224 units of 100 milliseconds, encoded in network byte order. 226 3.2. Use by DNS Clients 228 3.2.1. Sending Queries 230 DNS clients MUST NOT include the edns-tcp-keepalive option in queries 231 sent using UDP transport. 233 DNS clients MAY include the edns-tcp-keepalive option in the first 234 query sent to a server using TCP transport to signal their desire to 235 keep the connection open when idle. 237 DNS clients MAY include the edns-tcp-keepalive option in subsequent 238 queries sent to a server using TCP transport to signal their 239 continued desire to keep the connection open when idle. 241 Clients MUST specify an OPTION-LENGTH of 0 and omit the TIMEOUT 242 value. 244 3.2.2. Receiving Responses 246 A DNS client that receives a response using UDP transport that 247 includes the edns-tcp-keepalive option MUST ignore the option. 249 A DNS client that receives a response using TCP transport that 250 includes the edns-tcp-keepalive option MAY keep the existing TCP 251 session open when it is idle. It SHOULD honour the timeout received 252 in that response (overriding any previous timeout) and initiate close 253 of the connection before the timeout expires. 255 A DNS client that receives a response that includes the edns-tcp- 256 keepalive option with a TIMEOUT value of 0 SHOULD send no more 257 queries on that connection and initiate closing the connection as 258 soon as it has received all outstanding responses. 260 A DNS client that sent a query containing the edns-keepalive-option 261 but receives a response that does not contain the edns-keepalive- 262 option SHOULD assume the server does not support keepalive and behave 263 following the guidance in [DRAFT-5966bis]. This holds true even if a 264 previous edns-keepalive-option exchange occurred on the existing TCP 265 connection. 267 3.3. Use by DNS Servers 269 3.3.1. Receiving Queries 271 A DNS server that receives a query using UDP transport that includes 272 the edns-tcp-keepalive option MUST ignore the option. 274 A DNS server that receives a query using TCP transport that includes 275 the edns-tcp-keepalive option MAY modify the local idle timeout 276 associated with that TCP session if resources permit. 278 3.3.2. Sending Responses 280 A DNS server that receives a query sent using TCP transport that 281 includes an OPT RR (with or without the edns-tcp-keepalive option) 282 MAY include the edns-tcp-keepalive option in the response to signal 283 the expected idle timeout on a connection. Servers MUST specify the 284 TIMEOUT value that is currently associated with the TCP session. It 285 is reasonable for this value to change according to local resource 286 constraints. The DNS server SHOULD send a edns-tcp-keepalive option 287 with a timeout of 0 if it deems its local resources are too low to 288 service more TCP keepalive sessions, or if it wants clients to close 289 currently open connections. 291 3.4. TCP Session Management 293 Both DNS clients and servers are subject to resource constraints 294 which will limit the extent to which TCP sessions can persist. 295 Effective limits for the number of active sessions that can be 296 maintained on individual clients and servers should be established, 297 either as configuration options or by interrogation of process limits 298 imposed by the operating system. Servers that implement edns-tcp- 299 keepalive should also engage in TCP connection management by 300 recycling existing connections when appropriate, closing connections 301 gracefully and managing request queues to enable fair use. 303 In the event that there is greater demand for TCP sessions than can 304 be accommodated, servers may reduce the TIMEOUT value signalled in 305 successive DNS messages to minimise idle time on existing sessions. 306 This also allows, for example, clients with other candidate servers 307 to query to establish new TCP sessions with different servers in 308 expectation that an existing session is likely to be closed, or to 309 fall back to UDP. 311 Based on TCP session resources servers may signal a TIMEOUT value of 312 0 to request clients to close connections as soon as possible. This 313 is useful when server resources become very low or a denial-of- 314 service attack is detected and further maximises the shifting of 315 TIME_WAIT state to well-behaved clients. 317 However it should be noted that RCF6891 states: 319 Lack of presence of an OPT record in a request MUST be taken as an 320 indication that the requestor does not implement any part of this 321 specification and that the responder MUST NOT include an OPT 322 record in its response. 324 Since servers must be faithful to this specification even on a 325 persistent TCP connection it means that (following the initial 326 exchange of timeouts) a server may not be presented with the 327 opportunity to signal a change in the idle timeout associated with a 328 connection if the client does not send any further requests 329 containing EDNS0 OPT RRs. This limitation makes persistent 330 connection handling via an initial idle timeout signal more 331 attractive than a mechanism that establishes default persistence and 332 then uses a connection close signal (in a similar manner to HTTP 1.1 333 [RFC7320]). 335 If a client includes the edns-tcp-keepalive option in the first 336 query, it SHOULD include an EDNS0 OPT RR periodically in any further 337 messages it sends during the TCP session. This will increase the 338 chance of the client being notified should the server modify the 339 timeout associated with a session. The algorithm for choosing when 340 to do this is out of scope of this document and is left up to the 341 implementor and/or operator. 343 DNS clients and servers MAY close a TCP session at any time in order 344 to manage local resource constraints. The algorithm by which clients 345 and servers rank active TCP sessions in order to determine which to 346 close is not specified in this document. 348 3.5. Non-Clean Paths 350 Many paths between DNS clients and servers suffer from poor hygiene, 351 limiting the free flow of DNS messages that include particular EDNS0 352 options, or messages that exceed a particular size. A fallback 353 strategy similar to that described in [RFC6891] section 6.2.2 SHOULD 354 be employed to avoid persistent interference due to non-clean paths. 356 3.6. Anycast Considerations 358 DNS servers of various types are commonly deployed using anycast 359 [RFC4786]. 361 Changes in network topology between clients and anycast servers may 362 cause disruption to TCP sessions making use of edns-tcp-keepalive 363 more often than with TCP sessions that omit it, since the TCP 364 sessions are expected to be longer-lived. It might be possible for 365 anycast servers to avoid disruption due to topology changes by making 366 use of TCP multipath [RFC6824] to anchor the server side of the TCP 367 connection to an unambiguously-unicast address. 369 4. Intermediary Considerations 371 It is RECOMMENDED that DNS intermediaries which terminate TCP 372 connections implement edns-tcp-keepalive. An intermediary that does 373 not implement edns-tcp-keepalive but sits between a client and server 374 that both support edns-tcp-keepalive might close idle connections 375 unnecessarily. 377 5. Security Considerations 379 The edns-tcp-keepalive option can potentially be abused to request 380 large numbers of long-lived sessions in a quick burst. When a DNS 381 Server detects abusive behaviour, it SHOULD immediately close the TCP 382 connection and free the resources used. 384 Servers could choose to monitor client behaviour with respect to the 385 edns-tcp-keepalive option to build up profiles of clients that do not 386 honour the specified timeout. 388 Readers are advised to familiarise themselves with the security 389 considerations outlined in [DRAFT-5966bis] 391 6. IANA Considerations 393 The IANA is directed to assign an EDNS0 option code for the edns-tcp- 394 keepalive option from the DNS EDNS0 Option Codes (OPT) registry as 395 follows: 397 +-------+--------------------+----------+-----------------+ 398 | Value | Name | Status | Reference | 399 +-------+--------------------+----------+-----------------+ 400 | TBD1 | edns-tcp-keepalive | Standard | [This document] | 401 +-------+--------------------+----------+-----------------+ 403 7. Acknowledgements 405 The authors acknowledge the contributions of Jinmei TATUYA and Mark 406 Andrews. Thanks to Duane Wessels for detailed review and the many 407 others who contributed to the mailing list discussion. 409 8. References 411 8.1. Normative References 413 [DRAFT-5966bis] 414 Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 415 D. Wessels, "DNS Transport over TCP - Implementation 416 Requirements", draft-ietf-dnsop-5966bis (work in 417 progress), January 2016. 419 [RFC1035] Mockapetris, P., "Domain names - implementation and 420 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 421 November 1987, . 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, 425 DOI 10.17487/RFC2119, March 1997, 426 . 428 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 429 Rose, "DNS Security Introduction and Requirements", 430 RFC 4033, DOI 10.17487/RFC4033, March 2005, 431 . 433 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 434 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 435 December 2006, . 437 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 438 for DNS (EDNS(0))", STD 75, RFC 6891, 439 DOI 10.17487/RFC6891, April 2013, 440 . 442 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 443 RFC 7320, DOI 10.17487/RFC7320, July 2014, 444 . 446 8.2. Informative References 448 [CHAIN-QUERY] 449 Wouters, P., "Chain Query requests in DNS", draft-ietf- 450 dnsop-edns-chain-query (work in progress), January 2016. 452 [DNS-over-TLS] 453 Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 454 and P. Hoffman, "TLS for DNS: Initiation and Performance 455 Considerations", draft-ietf-dprive-dns-over-tls (work in 456 progress), January 2016. 458 [fragmentation-considered-poisonous] 459 Herzberg, A. and H. Shulman, "Fragmentation Considered 460 Poisonous", arXiv 1205.4011, May 2012, 461 . 463 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 464 "TCP Extensions for Multipath Operation with Multiple 465 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 466 . 468 [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting 469 (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012, 470 . 472 Appendix A. Editors' Notes 474 A.1. Abridged Change History 476 [Note to RFC Editor: please remove this section prior to 477 publication.] 479 A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-06 481 Introduction: Moved paragraph 8 to paragraph 2 for readability. 483 Introduction: clarified that TCP has expensive setup overhead 484 compared to UDP. 486 Section 3: Add explicit description of the idle timeout. 488 Section 3.3.2, 1st para: make explicit that query may or may not 489 contain edns-tcp-keepalive option. 491 Section 3.3.2: remove discussion of intermediary behaviour. 493 A.1.2. draft-ietf-dnsop-edns-tcp-keepalive-05 495 Reword Abstract and paragraph 9 in Introduction to remove discussion 496 on balancing UDP/TCP and talk about encouraging use of long-lived TCP 497 sessions. 499 Section 3.2.2: should -> SHOULD 501 Changed draft-ietf-dnsop-5966bis to be a normative reference, 502 therefore adding a dependancy on publication of that as RFC. 504 Reword sentence referring to RFC6824 since it is informational. 506 Update IANA option to Standard. 508 Remove last sentence from 1st paragraph of introduction. 510 Reword paragraph 6 in Introduction, merge paragraph 7 and 8. 512 Reword Section 3, first sentence to clarify the timeout is specified 513 by the server. 515 Correct missing URIs in 2 references. 517 Clarify statement in Section 3.2.2 as how clients should handle 518 updating the timeout when receiving a response. 520 Reworded first paragraph of Introduction discussing TCP vs (UDP + 521 retry over TCP). Changed 'fallback' to 'retry' in 2 places. 523 A.1.3. draft-ietf-dnsop-edns-tcp-keepalive-04 525 Adding wording to sections 3.2.1 and 3.4 to clarify client behaviour 526 on subsequent queries on a TCP connection. 528 Changed the should to a SHOULD in section 3.2.2 530 Changed Nameserver to DNS server in section 5. 532 Updated references. 534 Changed reference to RFC6824 to be informative. 536 Corrected reference to requested EDNS0 option code to be 'TBD1'. 538 A.1.4. draft-ietf-dnsop-edns-tcp-keepalive-03 540 Clarified that a response to a query with any OPT RR may contain the 541 ends-tcp-keepalive option. 543 Corrected TIMEOUT length from 4 to 2 in the diagram. 545 Updated references, including name change of STARTTLS -> DNS-over-TLS 546 and adding reference for cache poisoning. 548 Updated wording in section on Intermediary Considerations. 550 Updated wording describing RRL. 552 Added paragraph to security section describing client behaviour 553 profiles. 555 Added wording to introduction on use case for stub/resolver/ 556 authoritative. 558 A.1.5. draft-ietf-dnsop-edns-tcp-keepalive-02 560 Changed timeout value to idle timeout and re-phrased document around 561 this. 563 Changed units of timeout to 100ms to allow values less than 1 second. 565 Change specification to remove use of the option over UDP. This is 566 potentially confusing, could cause issues with ALG's and adds only 567 limited value. 569 Changed semantics so the client no longer sends a timeout. The 570 client timeout is of limited value as servers should be managing 571 connections based on their view of their resources, not on client 572 requests as this is open to abuse. Additionally this identifies 573 cases were the option is simply being reflected back. 575 Changed semantics for the meaning of a server sending a timeout of 0. 576 The maximum timeout value of 6553.5s (~1.8h) is already large and a 577 distinct 'connection close'-like signal is potentially more useful. 579 Added more detail on server side requirements when supporting 580 keepalive in terms of resource and connection management. 582 Added discussion of EDNS0 per-message limitation and implications of 583 this. 585 Added reference to STARTTLS draft and RFC7320. 587 A.1.6. draft-ietf-dnsop-edns-tcp-keepalive-01 589 Version bump with no changes 591 A.1.7. draft-ietf-dnsop-edns-tcp-keepalive-00 593 Clarifications, working group adoption. 595 A.1.8. draft-wouters-edns-tcp-keepalive-01 597 Also allow clients to specify KEEPALIVE timeout values, clarify 598 motivation of document. 600 A.1.9. draft-wouters-edns-tcp-keepalive-00 602 Initial draft. 604 Authors' Addresses 606 Paul Wouters 607 Red Hat 609 Email: pwouters@redhat.com 610 Joe Abley 611 Dyn, Inc. 612 470 Moore Street 613 London, ON N6C 2C2 614 Canada 616 Phone: +1 519 670 9327 617 Email: jabley@dyn.com 619 Sara Dickinson 620 Sinodun Internet Technologies 621 Magdalen Centre 622 Oxford Science Park 623 Oxford OX4 4GA 624 UK 626 Email: sara@sinodun.com 627 URI: http://sinodun.com 629 Ray Bellis 630 Internet Systems Consortium, Inc 631 950 Charter Street 632 Redwood City CA 94063 633 USA 635 Phone: +1 650 423 1200 636 Email: ray@isc.org 637 URI: http://www.isc.org