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

[Ballot comment]
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.

[Ballot discuss]

Don't we need text warning that TFO is likely problematic
with DNS privacy and that attacks that try to prepend
information (via TFO) to otherwise secured sessions could
occur? While that might sound a bit far-fetched we have
seen exactly that kind of issue with HTTPS that had
practical impact on Webdav. (The TLS renego and then
triple handshake attacks.) So while using TFO may not
enable a slam-dunk CVE level 10 attack, I think you do
need to consider and talk about it. (Or maybe you did and
figured out no attack can work, but then I'd guess you'd
be so happy, you'd say that too:-)

I'm not sure how this'd best be resolved, but one thing
might be to talk to the folks thinking about TCPINC as
they have at least hit this as a potential issue for
tcpcrypt and for tcp-use-tls.

Otherwise, this is a fine document on which I'll ballot
yes when the above is sorted.

[Ballot comment]
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".

[Ballot discuss]
I don’t have concerns over the technical content of this document, but I do have want to raise a process-related DISCUSS.

The Intended RFC Status of this document is “Internet Standard”, which seems like a logical progression from RFC5966 (Proposed Standard).  However, I am concerned that the proper process was not followed:

1. RFC6410 calls for “an IETF-wide Last Call of at least four weeks”, but the LS started on Nov/23 and ended on Dec/7, 2 weeks.

2. In looking at the archives I couldn’t find any discussion about changing the maturity level.

3. It also concerns me that the changes go beyond a simple revision of the old text.  For example, there are recommendations that are completely new and for topics that were not even mentioned in the original (e.g. pipelining).


I may have missed the discussions in the archive.  Not being a DNS expert I may also be overestimating the changes to this document. But knowing that the “document was actively discussed and reviewed” and that it “had a broad discussion as the wording of several points were more accurately described” (from the Shepherd’s write up), I think that this document may not be ready to be an Internet Standard.

The obvious solution to this DISCUSS is to change the intended status to Proposed Standard.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
-- 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]." ?

[Ballot comment]
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.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dnsop-5966bis-04.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: tjw.ietf@gmail.com, joelja@gmail.com, draft-ietf-dnsop-5966bis@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DNS Transport over TCP - Implementation Requirements) to Internet Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'DNS Transport over TCP - Implementation Requirements'
  as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-12-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Document Shepherd:  Tim Wicinski
Area Director:      Joel Jaggeli

Document Type:      Standards Track
Obsoletes:          5966

The document specifies the requirements for support TCP as a transport protocol for DNS. It also provides guidelines on optimizing performance of DNS over TCP.

2. Review and Consensus

This document was actively discussed and reviewed, partially because this is a revision of an older RFC, but also as more DNS falls back to TCP (DNSSEC) and the need for DNS to support the DNS-over-TLS work in DPRIVE working group.  The community feels updating the older RFC is well needed. This also include the initial author of RFC5966.

The document had a broad discussion as the wording of several points were more accurately described. Once these issues were resolved, consensus was strong with no complaints.

The shepherd did a deep editorial review of this draft and found it to be solid.  The shepherd has no concerns moving forward.

3. Intellectual Property

There is no IPR related to this document, and the authors have no direct, personal knowledge of any IPR.

4. Other Points

- Downward References:

There are no downward references in this document.

- IANA Considerations:

There are no IANA Considerations in this document.

Checklist
---------

X- Does the shepherd stand behind the document and think the document
is ready for publication?

X- Is the correct RFC type indicated in the title page header?

X- Is the abstract both brief and sufficient, and does it stand alone
as a brief summary?

X- Is the intent of the document accurately and adequately explained
in the introduction?

X- Have all required formal reviews (MIB Doctor, Media Type, URI,
etc.) been requested and/or completed?

X- Has the shepherd performed automated checks -- idnits (see
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist),
checks of BNF rules, XML code and schemas, MIB definitions, and so
on -- and determined that the document passes the tests?

X- Has each author stated that their direct, personal knowledge of
any IPR related to this document has already been disclosed, in
conformance with BCPs 78 and 79?

X- Have all references within this document been identified as either
normative or informative, and does the shepherd agree with how they
have been classified?

X- Are all normative references made to documents that are ready for
advancement and are otherwise in a clear state?

X- If publication of this document changes the status of any existing
RFCs, are those RFCs listed on the title page header, and are the
changes listed in the abstract and discussed (explained, not just
mentioned) in the introduction?

X- If this is a "bis" document, have all of the errata been considered?

X- IANA Considerations