idnits 2.17.1 draft-bellis-dnsop-connection-close-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6891]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6891, updated by this document, for RFC5378 checks: 2007-12-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 24, 2014) is 3471 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 5966 (Obsoleted by RFC 7766) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bellis 3 Internet-Draft Nominet UK 4 Updates: 6891 (if approved) October 24, 2014 5 Intended status: Standards Track 6 Expires: April 27, 2015 8 Connection Close Signalling for DNS 9 draft-bellis-dnsop-connection-close-00 11 Abstract 13 This document updates [RFC6891] by specifying a new single-bit flag 14 in a DNS response that when seen in a packet carried over a 15 connection-orientated transport protocol indicates to the client that 16 it should close the current connection. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 27, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Connection Handling . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 62 7.2. Informative References . . . . . . . . . . . . . . . . . 4 63 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 5 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 The DNS protocol [RFC1035] supports use of persistent TCP 69 connections, although guidance as to when a connection should be 70 terminated (and by which party) is limited [RFC5966]. 72 This document updates the Extension Mechanisms for DNS (EDNS(0)) 73 [RFC6891] by specifying a new single-bit flag in a DNS response that 74 when seen in a packet carried over a connection-orientated transport 75 protocol indicates to the client that it should close the current 76 connection. 78 Having the client close the connection reduces the amount of TCP 79 state information that must be stored by the server compared to that 80 resulting from the server initiating a unilateral close itself. 82 TODO: does it make sense to specify a request side meaning for this 83 flag, indicating that the server may half-close its "read" side of 84 the connection? This would make the semantics even closer to those 85 of the HTTP/1.1 "Connection: close" header (see Section 14.10 of 86 [RFC2616]) 88 2. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 3. Specification 96 The "Connection Close" (CC) bit is held in the third-most signifiant 97 bit of the third byte of the "extended RCODE and flags" portion of an 98 EDNS(0) OPT meta-RR: 100 +0 (MSB) +1 (LSB) 101 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 102 0: | EXTENDED-RCODE | VERSION | 103 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 104 2: |DO| Z|CC| Z | 105 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 107 Note to RFC editor: replace the first 'Z' in the figure above with 108 'TO' if draft-hzhwm-dprive-start-tls-for-dns is published as an RFC 109 before this specification. 111 4. Connection Handling 113 4.1. Servers 115 Servers MAY set this flag to indicate that further queries received 116 over the current connection should not be sent. 118 An incompatible client will not understand this flag and may continue 119 sending requests and therefore the server MUST NOT refuse to service 120 subsequent requests. The server MAY unilaterally close idle 121 connections regardless, per [RFC5966] and Section 4.2.2 of [RFC1035] 123 Since this flag requires EDNS(0) support, note that this flag cannot 124 be set unless the client has indicated support for EDNS(0) by sending 125 an OPT meta-RR itself, per Section 7 of [RFC6891] 127 TODO: note - the constraint in RFC 6891 appears unnecessarily strict 128 - it appears to mandate that the EDNS(0) support indication is on a 129 per-request basis, but it would be reasonable on a connection- 130 orientated transport to assume that ANY preceding request on that 131 connection with an OPT RR is sufficient to indicate that the client 132 supports EDNS(0). 134 TODO: if a request-side semantic is defined for this flag, what are 135 the TCP state-maintenance implications if the server performs a 136 'shutdown(fd, SHUT_RD)'? 138 4.2. Clients 140 Clients receiving a packet with this flag set MUST NOT send any 141 further queries over the current connection and MUST initiate closure 142 of that connection. 144 TODO: what are the TCP state-maintenance implications if the client 145 performs a 'shutdown(fd, SHUT_WR)'? 147 5. Security Considerations 149 None identified (yet). 151 6. IANA Considerations 153 IANA are requested to update the EDNS Header Flag Registry according 154 to Section 3. 156 Note to IANA and RFC Editor: The actual bit assigned will depend on 157 whether any other document specifies a used for the above-specificed 158 bit in advance of publication of this document as an RFC. 160 7. References 162 7.1. Normative References 164 [RFC1035] Mockapetris, P., "Domain names - implementation and 165 specification", STD 13, RFC 1035, November 1987. 167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 168 Requirement Levels", BCP 14, RFC 2119, March 1997. 170 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 171 Requirements", RFC 5966, August 2010. 173 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 174 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 176 7.2. Informative References 178 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 179 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 180 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 182 Appendix A. Change Log 184 Note to RFC editor: remove this section before publication. 186 draft-bellis-dnsop-connection-close-00 188 Initial draft 190 Author's Address 192 Ray Bellis 193 Nominet UK 194 Minerva House 195 Edmund Halley Road 196 Oxford Science Park 197 Oxford OX4 4DQ 198 United Kingdom 200 Phone: +44 1865 332211 201 Email: ray.bellis@nominet.org.uk 202 URI: http://www.nominet.org.uk/