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

神明達哉 <> Fri, 12 May 2017 15:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2F5212EBE2 for <>; Fri, 12 May 2017 08:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iKxqe1773mf0 for <>; Fri, 12 May 2017 08:52:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A61112EB23 for <>; Fri, 12 May 2017 08:47:01 -0700 (PDT)
Received: by with SMTP id l7so9246476qte.1 for <>; Fri, 12 May 2017 08:47:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UOHUe7qGH3QPcj0irQ5RywR9OMQxzkaejKST+LxbTGw=; b=Zql6faqCbIWRwjepJr0av4QqPxkkKcN/Nh5UMdTqferK6QIrNS3Se+GPTRzSTc9waw 4NYRcU7vLgcM3xwkGrFeCWb6DMfET6YAlYkiLejpPjMv1B58Miy9/AxSNgiG6tuSOvDf 99kbLj1GRLjmjeEZYf5QzplxEe5pBdBoqOofcA24oWRkQsXdFe7XaSWhpbjB9vtM4/ke k+dp73XXZk8XxSFsdnKgujz0b9IabUmEYyYJIkZGAwDRF8lXsNzaJ/KOrTuDe6e61o6i 2n1i4oVbqSN0zWzfiosBfQ6uXvq3ELH07aFOt75eJzMWUdmAZOXKEf8bLJhGivaWlCyo wbPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UOHUe7qGH3QPcj0irQ5RywR9OMQxzkaejKST+LxbTGw=; b=gwtY8Pj/gAmOxm8bh+ILariOslLh4IVTHwHvfYyh/DJRScd1rs2JZsHiVQ9DvWZZWk kkBqp7Gh80iKvHidiD6IMjNP5DCOc+QqQJ/0jWWknfeMUGdDNBeovd/V/44Ty3Z4sAqE vyv/0DADWwUUPMOUAhAbd0zlTb1VOW+nZ9BB7gbnj9z6EM+VB4avVdbu/j7EBcKNyzsU NBraOesiKn4pIWdsvNYoqv6YBRyRUoSof2c60hzU6LF0cobhZPPcndNO7Fo+dkWY/pBj efM/vqdMEzaKApntrUcQUsA/YxYp9vReU5aSYVvx2/YmCSgMNvL3DxjCw5iW0Bb+T27X SkRg==
X-Gm-Message-State: AODbwcAXfhWUYIq3cxxCgfBFfCRkUHSGeVKxNkam3FBh3ZfWvNG3lTFf 42J2AVrBobCMg5RC6oufoqQVC9XTqQ==
X-Received: by with SMTP id r10mr4189857qta.290.1494604020449; Fri, 12 May 2017 08:47:00 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 12 May 2017 08:46:59 -0700 (PDT)
In-Reply-To: <20170512064552.5910d314@p50.localdomain>
References: <> <> <20170512064552.5910d314@p50.localdomain>
From: 神明達哉 <>
Date: Fri, 12 May 2017 08:46:59 -0700
X-Google-Sender-Auth: xtJ9yQnK1t3TxGEl7aF3QhqQ-ns
Message-ID: <>
Cc: tjw ietf <>, dnsop <>
Content-Type: text/plain; charset="UTF-8"
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 15:52:41 -0000

At Fri, 12 May 2017 06:45:52 -0500,
John Kristoff <> 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 understand this draft tries to focus on an operational standpoint.
It states the intent pretty clearly.  It's just that I wasn't
convinced about the need to publish a separate RFC for that purpose
with all the overhead.  But, if a new version provides more compelling
arguments about the need it might change my mind.  And, in any case, I
wouldn't be surprised if others see stronger need for a separate
operational document - it can be quite subjective.  That's why I said
I wouldn't be (necessarily) opposed to
> >   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.

Regarding this, see my followup response to Tony.

JINMEI, Tatuya