DNS Transport over TCP - Implementation Requirements
RFC 7766

Note: This ballot was opened for revision 05 and is now closed.

(Ben Campbell) Yes

Comment (2016-01-06 for -05)
No email
send info
I'm balloting "yes" under the assumption this is intended as proposed standard.

6.2.1.1:
Now that clients SHOULD pipeline, is it enough to say servers SHOULD expect it? Seems like a MUST would be in order.

=== Editorial===
-1: "... TCP is henceforth a REQUIRED ..."
Since the normative language is strengthened in section 5, the REQUIRED seems redundant here. I'd suggest stating this without the 2119 keyword.

- 5, 2nd to last paragraph:
I concur with Barry on the unclear antecedent of "It".

(Spencer Dawkins) Yes

Comment (2016-01-07 for -05)
No email
send info
In this text:

   It is however noted that certain primary/secondary
   configurations with many busy zones might need to use more than one
   TCP connection for zone transfers for operational reasons.
   
could "for operational reasons" be a bit more precise? I think I know the problem that's being solved, but I'm guessing, and other readers might not know.

(Stephen Farrell) (was Discuss) Yes

Comment (2016-01-15)
No email
send info
Thanks for addressing my issue about TFO & DPRIVE.

(Brian Haberman) Yes

Comment (2016-01-06 for -05)
No email
send info
While I am not a fan of standards-track requirements documents, I understand the history of 5966 and support the publication of this document. I do have a couple of comments for your consideration.

1. Is it worth mentioning in the Intro that another drive towards more TCP-based DNS exchanges may be the desire to re-use existing security associations for DNS privacy solutions?

2. Is there a reference to back up the statement "However, transport of UDP packets that exceed the size of the path  MTU causes IP packet fragmentation, which has been found to be unreliable in many circumstances."? It would be good to be able to gauge just how unreliable this issue has become.

3. I agree with Martin's suggested re-wording in Section 8.

(Joel Jaeggli) Yes

(Martin Stiemerling) Yes

Comment (2016-01-05 for -05)
No email
send info
One comment and request for clarification:

In the first paragraph of Section 8:
"   DNS clients and servers SHOULD pass the two-octet length field, and
   the message described by that length field, to the TCP layer at the
   same time (e.g., in a single "write" system call) to make it more
   likely that all the data will be transmitted in a single TCP segment.
   This is both for reasons of efficiency and to avoid problems due to
   some DNS server implementations behaving undesirably when processing
   TCP segments (due to a lack of clarity in previous standards).  For
   example, some DNS server implementations might abort a TCP session if
   the first TCP segment does not contain both the length field and the
   entire message.
"

This paragraphs says that DNS servers process segments. This is slightly inaccurate, at least under the assumption that DNS clients and servers are user land processes. 
Such a user land process does not see segments but data being read or written to the sockets. And such data might be one or multiple segments concatenated. 

I do understand the text, but I would like to propose a change (though the proposed text might not be perfect):

   This is both for reasons of efficiency and to avoid problems due to
   some DNS server implementations behaving undesirably when reading
   data from TCP  (due to a lack of clarity in previous standards).  For
   example, some DNS server implementations might abort a TCP session if
   the first data part read from TCP does not contain both the length field and the
   entire message.

(Jari Arkko) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Comment (2016-01-06 for -05)
No email
send info
I was slightly surprised by "implementation requirements" in the title.
If we write a RFC, we hopefully hope/require future implementations, right?
I understand the willingness to change as little text as possible compared RFC5966, but I would welcome the following update:

OLD:


          DNS Transport over TCP - Implementation Requirements
                      draft-ietf-dnsop-5966bis-05

Abstract

   This document specifies the requirement for support of TCP as a
   transport protocol for DNS implementations and provides guidelines
   towards DNS-over-TCP performance on par with that of DNS-over-UDP.
   This document obsoletes RFC5966 and therefore updates RFC1035 and
   RFC1123.

NEW:


          DNS Transport over TCP
                      draft-ietf-dnsop-5966bis-05

Abstract

   This document specifies TCP as a
   transport protocol for DNS implementations and provides guidelines
   towards DNS-over-TCP performance on par with that of DNS-over-UDP.
   This document obsoletes RFC5966 and therefore updates RFC1035 and
   RFC1123.

Alissa Cooper No Objection

Barry Leiba No Objection

Comment (2016-01-06 for -05)
No email
send info
-- Section 5 --

   This requirement is hereby relaxed.  Stub resolvers and recursive
   resolvers MAY elect to send either TCP or UDP queries depending on
   local operational reasons.  TCP MAY be used before sending any UDP
   queries.  If it already has an open TCP connection to the server it
   SHOULD reuse this connection.  In essence, TCP ought to be considered
   a valid alternative transport to UDP, not purely a fallback option.

The "If it already has" in the fourth sentence was clear in the original 
5966 text, but doesn't work here: there's no clear antecedent to "it".  
Please make it "If the resolver already has".

In the last sentence, I think we should say "not purely a retry option," 
as this isn't really "fallback" in the sense we usually use the term.

-- Section 6.1.1 --

   However it
   is common practice for clients to close the TCP connection after
   sending a single request

In the light of edns-tcp-keepalive, do we really want to say this?  It's 
true, but it sounds like a recommendation.  Maybe we might say something 
like, "Clients often close the TCP connection after sending a single 
request, but see [draft-ietf-dnsop-edns-tcp-keepalive]." ?

(Kathleen Moriarty) No Objection

Alvaro Retana (was Discuss) No Objection