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

John Kristoff <> Fri, 12 May 2017 11:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 111DF12EB68 for <>; Fri, 12 May 2017 04:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IUjXCzDUD5_a for <>; Fri, 12 May 2017 04:51:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 75B2C128A32 for <>; Fri, 12 May 2017 04:45:53 -0700 (PDT)
Received: from p50.localdomain (localhost []) by (Postfix) with ESMTP id 8CD83199C; Fri, 12 May 2017 11:45:52 +0000 (UTC)
Date: Fri, 12 May 2017 06:45:52 -0500
From: John Kristoff <>
To: 神明達哉 <>
Cc: tjw ietf <>, dnsop <>
Message-ID: <20170512064552.5910d314@p50.localdomain>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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, 12 May 2017 11:51:28 -0000

On Thu, 11 May 2017 23:25:13 +0000
神明達哉 <> wrote:

> I've read draft-kristoff-dnsop-dns-tcp-requirements-02.

Thank you for taking the time to read, review, and comment on it!

> I think RFC7766 already pretty clearly states TCP is a MUST.

IETF RFC 7766 does very explicitly declare TCP is a MUST in the context
of DNS implementation.  It is also very explicit about not declaring
this to be so from an operational standpoint, although with a strong
warning about the consequences.  The last paragraph is Section 1 in that
document is the operative text.  It was that in addition to my own
operational and teaching experience I felt made this draft necessary. I
tried to make this case at the meeting in Chicago and elsewhere that
this is an important distinction that matters.  I can try to make this
case more compelling and convincing in the text.

>   I'm not sure if DDNS update bolsters the need for TCP.
>   And I don't see any new trend that changes this practice.

I see Tony has chimed on this so I'll simply add that the goal of
Section 2 was not necessarily intended to make or bolster the modern
argument for carrying DNS over TCP.  In fact, the purpose was to help
show how it is difficult to conclude one way or another whether carrying
DNS over TCP is an operational requirement or not. I can make this
objective more explicit at the beginning of that section.

>   The term "forwarder" can be ambiguous (see, e.g, RFC7766).  You
>   might want to use a different term to be clearer.

Thanks again, I can try to make the wording and meaning more precise.