The IESG has approved the following document: - 'DNS Transport over TCP - Implementation Requirements ' <draft-ietf-dnsext-dns-tcp-requirements-03.txt> as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-tcp-requirements-03.txt Technical Summary This document expresses in clearly that general purpose DNS software needs to be able to to perform DNS queries over TCP. Working Group Summary The discussion in the working centered on following issues: * Is TCP required for some queries: Answer in general yes * How should TCP connections be handled: The document states that DNS servers can terminate open TCP connections when they want/need to. * Is the document requiring DNS operators to provide TCP query service: No. Such specification is outside the working group's scope and it is a decision for each DNS Operator. Document Quality The document is well written and expresses the issues clearly. The actions are clearly marked and the text that is being updated is quoted. Personnel Olafur Gudmundsson (ogud@ogud.com) is the document shepherd. Ralph Droms <rdroms.ietf@gmail.com> is the responsible AD. RFC Editor Note Changes to be made before publication: Section 1: OLD: Most DNS [RFC1035] transactions take place over UDP [RFC0768]. TCP NEW: Most DNS [RFC1034] transactions take place over UDP [RFC0768]. TCP Section 4: OLD: o Authoritative server implementations MUST support TCP so that they do not limit the size of responses. o Recursive resolver (or forwarder) implementations MUST support TCP so that the do not prevent large responses from a TCP-capable server from reaching its TCP-capable clients. o Stub resolver implementations (e.g. an operating system's DNS resolution library) MUST support TCP since to do otherwise would limit their interoperability with their own clients and with upstream servers. An exception may be made for proprietary stub resolver implementations. These MAY omit support for TCP if operating in an environment where truncation can never occur, or where DNS lookup failure is acceptable should truncation occur. Regarding the choice of when to use UDP or TCP, RFC 1123 says: ... a DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first. NEW: o Authoritative server implementations MUST support TCP so that they do not limit the size of responses to what fits in a single UDP packet. o Recursive server (or forwarder) implementations MUST support TCP so that they do not prevent large responses from a TCP-capable server from reaching its TCP-capable clients. o Stub resolver implementations (e.g. an operating system's DNS resolution library) MUST support TCP since to do otherwise would limit their interoperability with their own clients and with upstream servers. Stub resolver implementations MAY omit support for TCP when specifically designed for deployment in restricted environments where truncation can never occur or where truncated DNS responses are acceptable. Regarding the choice of when to use UDP or TCP, Section 6.1.3.2 of RFC 1123 also says: ... a DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first. Section 5: OLD: This document therefore RECOMMENDS that the default application-level idle period should be of the order of seconds, but does not specify any particular value. In practise the idle period may vary dynamically, and servers MAY allow dormant connections to remain open for longer periods as resources permit. NEW: It is therefore RECOMMENDED that the default application-level idle period should be of the order of seconds, but no particular value is specified. In practise the idle period may vary dynamically, and servers MAY allow dormant connections to remain open for longer periods as resources permit. Section 9: OLD: The author would like to thank the document reviewers from the DNSEXT Working Group, and in particular George Barwood, Alex Bligh, Alfred Hoenes, Fernando Gont, Jim Reid, Paul Vixie and Nicholas Weaver. NEW: The author would like to thank the document reviewers from the DNSEXT Working Group, and in particular George Barwood, Alex Bligh, Alfred Hoenes, Fernando Gont, Olafur Gudmondsson, Jim Reid, Paul Vixie and Nicholas Weaver. Section 10.1: OLD: [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. NEW: [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
