Connection Close Signalling for DNSNominet UKMinerva HouseEdmund Halley RoadOxford Science ParkOxfordOX4 4DQUnited Kingdom+44 1865 332211ray.bellis@nominet.org.ukhttp://www.nominet.org.uk/
Operations Area
This document updates by specifying a new single-bit flag
in a DNS response that when seen in a packet carried over a connection-orientated
transport protocol indicates to the client that it should close the current
connection. The DNS protocol supports use of persistent TCP
connections, although guidance as to when a connection should be terminated (and by
which party) is limited . This document updates the Extension Mechanisms for DNS (EDNS(0)) by specifying a new single-bit flag in a DNS response that
when seen in a packet carried over a connection-orientated transport protocol
indicates to the client that it should close the current connection. Having the client close the connection reduces the amount of TCP state information
that must be stored by the server compared to that resulting from the server
initiating a unilateral close itself. TODO: does it make sense to specify a request side meaning for this flag, indicating
that the server may half-close its "read" side of the connection? This would make
the semantics even closer to those of the HTTP/1.1 "Connection: close" header (see
Section 14.10 of ) The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in . The "Connection Close" (CC) bit is held in the third-most signifiant bit of the
third byte of the "extended RCODE and flags" portion of an EDNS(0) OPT meta-RR: Note to RFC editor: replace the first 'Z' in the figure above with 'TO' if
draft-hzhwm-dprive-start-tls-for-dns is published as an RFC before this
specification. Servers MAY set this flag to indicate that further queries received over the
current connection should not be sent. An incompatible client will not understand this flag and may continue sending
requests and therefore the server MUST NOT refuse to service subsequent
requests. The server MAY unilaterally close idle connections regardless, per
and Section 4.2.2 of Since this flag requires EDNS(0) support, note that this flag cannot be set
unless the client has indicated support for EDNS(0) by sending an OPT meta-RR
itself, per Section 7 of TODO: note - the constraint in RFC 6891 appears unnecessarily strict - it
appears to mandate that the EDNS(0) support indication is on a per-request
basis, but it would be reasonable on a connection-orientated transport to assume
that ANY preceding request on that connection with an OPT RR is sufficient to
indicate that the client supports EDNS(0). TODO: if a request-side semantic is defined for this flag, what are the TCP
state-maintenance implications if the server performs a 'shutdown(fd, SHUT_RD)'?
Clients receiving a packet with this flag set MUST NOT send any further queries
over the current connection and MUST initiate closure of that connection. TODO: what are the TCP state-maintenance implications if the client performs a
'shutdown(fd, SHUT_WR)'? None identified (yet). IANA are requested to update the EDNS Header Flag Registry according to . Note to IANA and RFC Editor: The actual bit assigned will depend on whether any
other document specifies a used for the above-specificed bit in advance of
publication of this document as an RFC.Note to RFC editor: remove this section before publication.draft-bellis-dnsop-connection-close-00Initial draft