Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements

Sara Dickinson <> Fri, 26 May 2017 12:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26D54129498 for <>; Fri, 26 May 2017 05:23:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5VgG06baCzF7 for <>; Fri, 26 May 2017 05:23:19 -0700 (PDT)
Received: from ( [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 740B4129489 for <>; Fri, 26 May 2017 05:23:19 -0700 (PDT)
Received: from [2001:b98:204:102:fffa::1b] (port=65408) by with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1dEEGy-000683-It; Fri, 26 May 2017 13:23:17 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Sara Dickinson <>
In-Reply-To: <20170525120048.1477cea5@p50.localdomain>
Date: Fri, 26 May 2017 13:23:10 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <20170525120048.1477cea5@p50.localdomain>
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: State = no_sa; Score =
Archived-At: <>
Subject: Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 May 2017 12:23:21 -0000

> On 25 May 2017, at 18:00, John Kristoff <> wrote:
>> Section 2: I think it might be useful to include a section in section
>> 2 describing the fact that the lack of, or very limited
>> implementation of TCP also fed the perception that it was a security
>> risk.
> The references
>  Cheswick, W. and S. Bellovin book

I sadly don’t have a copy of that book to hand so I can’t comment on the content there…. 

>  <>
> in section 2.4 I think may largely sums up the general concern.
> Maybe the section 2.4 is not correctly titled or incompletely detailed
> to highlight your point.  Any specific text or additional references are
> welcome of course.

How about:

   “There are many in the DNS community who configure DNS over TCP services and expect DNS over TCP transactions
   to occur without interference. However there has also been a long held belief
   by some operators, particularly for security-related reasons,
   that DNS over TCP services should be purposely limited or not provided at all [CHES94], [DJBDNS].  
   A popular meme has also held the imagination of some that DNS over TCP is only ever used for zone
   transfers and is generally unnecessary otherwise, with filtering all
   DNS over TCP traffic even described as a best practice. 
   The position on restricting DNS over TCP had some justification given that historic implementations of DNS nameservers provided
   very little in the way of TCP connection management (for example see Section 6.1.2 of [RFC7766] 
   for more details). However modern standards and implementations are moving to align with the more
   sophisticated TCP management techniques employed by, for example, HTTP(S) servers and load balancers. 

>> And since it is stated as TCP related development should RFC2136 be
>> there (even though it is discussed earlier)?
> Probably should be there.  Need I worry about section 6's length at
> all?  It could take up a significant portion of the document given the
> way this section is going.  Note, this section was added based on some
> earlier feedback that having this sort of list might be helpful.

If it gets too long then perhaps I could be moved to an Appendix? I think it is very useful for reference but as you say it should not necessarily dominate the document.