Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-5966bis-04

Sara Dickinson <sara@sinodun.com> Wed, 02 December 2015 13:52 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1941A8F4C; Wed, 2 Dec 2015 05:52:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvbzMyncNa-a; Wed, 2 Dec 2015 05:52:49 -0800 (PST)
Received: from shcp01.hosting.zen.net.uk (shcp01.hosting.zen.net.uk [88.98.24.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0261A8F43; Wed, 2 Dec 2015 05:52:49 -0800 (PST)
Received: from [62.232.251.194] (port=14808 helo=virgo.sinodun.com) by shcp01.hosting.zen.net.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from <sara@sinodun.com>) id 1a47pr-0005uG-VE; Wed, 02 Dec 2015 13:52:46 +0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_7D27007B-B1B9-438D-B421-C01D39562122"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <565B6B3A.9030703@gmail.com>
Date: Wed, 02 Dec 2015 13:52:44 +0000
Message-Id: <879ACEE4-18E2-474E-AD0F-287529B6B2E3@sinodun.com>
References: <565B6B3A.9030703@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3096.5)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - sinodun.com
X-Get-Message-Sender-Via: shcp01.hosting.zen.net.uk: authenticated_id: sara+sinodun.com/only user confirmed/virtual account not confirmed
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/dzwV5D8vsYVHZcpQGvrps9bg9uY>
Cc: General Area Review Team <gen-art@ietf.org>, draft-ietf-dnsop-5966bis.all@ietf.org
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-5966bis-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2015 13:52:51 -0000

> On 29 Nov 2015, at 21:16, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> Comment: I read all the text and have no technical issues.

Hi Brian, 

Many thanks for the review. After a discussion amongst the authors and Tim, responses below.


> --------
> 
> Major Issues:
> -------------
> 
> This draft replaces RFC 5966, which formally updates RFC 1035 and 1123. Therefore,
> logically this draft must also formally update RFC 1035 and 1123.
> 
> Specifically:
> 
> "Section 6.1.3.2 of [RFC1123] states:
> 
>      DNS resolvers and recursive servers MUST support UDP, and SHOULD
>      support TCP, for sending (non-zone-transfer) queries."
> 
> Please make an explicit statement that this SHOULD is changed to MUST.

The bis reproduces 2 statements verbatim from RFC5966 with regard to this. In paragraph 4 of the Introduction: 

“This document therefore updates the core DNS protocol specifications
   such that support for TCP is henceforth a REQUIRED part of a full DNS
   protocol implementation."

and in the first sentence of Section 5

“All general-purpose DNS implementations MUST support both UDP and TCP transport.”

In light of this do you still think we need another statement to this effect?


> 
> Minor Issues:
> -------------
> 
> 1) The last sentence of the Introduction says
> "It should be noted that failure to support TCP (or the
> blocking of DNS over TCP at the network layer) may result in
> resolution failure and/or application-level timeouts."
> 
> Isn't "may" understating the risk these days? I would have thought that
> "will probably result in ... failure" was justified.

Again, the wording here was lifted exactly from RFC5966, but the suggested change seems an improvement. I have updated the working copy with the new text. 

> 
> 2) If you want people to update existing code, the section "Changes to RFC 5966"
> should be kept when "Appendix B. Changes between revisions" is deleted. Also,
> please check which of the more recent changes need to be noted as changes compared
> to RFC 5966.

This is an excellent point. In the working copy I have moved the “Changes to RFC5966” section to a separate Appendix and updated the wording:

"Appendix C.  Changes to RFC5966

   [Note to RFC Editor: please leave this section in the final
   document.]

   This document obsoletes [RFC5966] and differs from it in several
   respects.  An overview of the most substantial changes/updates that
   implementors should take note of is given below:

   1.   A Terminology section (Section 3) is added defining several new
         concepts.

   2.   Paragraph 3 of Section 5 puts TCP on a more equal footing with
         UDP than RFC5966.  For example it states:

         1.  TCP MAY be used before sending any UDP queries.

         2.  TCP ought to be considered a valid alternative transport to
              UDP, not purely a fallback option.

   3.   Section 6.2.1 adds a new recommendation that TCP connection-
         reuse SHOULD be supported.

   4.   Section 6.2.1.1 adds a new recommendation that DNS clients
         SHOULD pipeline their queries and DNS servers SHOULD process
         pipelined queries concurrently.

   5.   Section 6.2.2 adds new recommendations on the number and usage
         of TCP connections for client/server interactions.

   6.   Section 6.2.3 adds a new recommendation that DNS clients SHOULD
         close idle sessions unless using a signalling mechanism.

   7.   Section 7 clarifies that servers are RECOMMENDED to prepare TCP
         responses in parallel and send answers out-of-order.  It also
         clarifies how TCP queries and responses should be matched by
         clients.

   8.   Section 8 adds a new recommendation about how DNS clients and
         servers should handle the 2 byte message length field for TCP
         messages.

   9.   Section 9 adds a non-normative discussion of the use of TCP Fast
         Open.

   10.  The Section 11 adds new advice regarding DoS mitigation
          techniques.”


Regards

Sara.