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

神明達哉 <jinmei@wide.ad.jp> Fri, 12 May 2017 15:30 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CD912F4B2 for <dnsop@ietfa.amsl.com>; Fri, 12 May 2017 08:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Fn_uVnbv0S5V for <dnsop@ietfa.amsl.com>; Fri, 12 May 2017 08:30:29 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FCB812741D for <dnsop@ietf.org>; Fri, 12 May 2017 08:25:42 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id y201so50630504qka.0 for <dnsop@ietf.org>; Fri, 12 May 2017 08:25:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MsuKVqVPqjtgSpVVPCEIhaCwzGqK2ODMzDgIwKw/zHY=; b=SOPwmdTe3zp9bfQSx/NuGJGWeTsyIMuXkRaGsira/jnHuk8pe0wQNOkANERf+JWer/ Yyf9TQUQ/UkiMzQszDh1yuqNywE2yM0wCEo79R/rRVsgMEp6UEWgkN07xXmVQz3oamvj AUD0EU+EeJYPZrqMnh0ettmhY9e/zsTYjM7Iko/yQFFjmQSec1JwiE3Zp8aMIDT8xanf eABHOjMaYv1seA8ShJ2Upq1dY+IrHP0ssmUMIKyJFWJO/8P9HyakwikIxnin/H/tSBOs OBpqOqcp3uC1umHIeOGTK49KiXR2yKwBrbf7ZW89qv/ZtlmHvM0WirTHrtOjZFK3f75U FESQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MsuKVqVPqjtgSpVVPCEIhaCwzGqK2ODMzDgIwKw/zHY=; b=Ygl1exDhEKD99apqaba7Nw0wNvVXe3u152GOgpHwfOZLMA8rwwgfh9cxusr/Y2I8Gx g6+B31Pvc2zoH2Zq3m/0JziDFW2olTH4ln+ZiydlOFutti1Vt1/faycKQi1+TM1ou3q+ i+jvPGjPZeS3CtuQ1CZDvQWWdCwgzSqC7GBx+wIZBC4nFinuqv5Qoj2RSxWqbx96bscP cOF7+jBRGTG8ZZweo1CouE9oYTgMQ01cwrXWISl795zEy24We0GIka8AyqAU8FS4ZG+B Gc349lpkDSEmTeFKwBm0mAnFpF4fgxjDyEdzDGD0SkA9z6LtI9wojBDeMDBJo6mkYDyD gyIg==
X-Gm-Message-State: AODbwcAPmVNybRjJFHRGN8fDNA5Z5jZrK/Eov5z4/oMEixXD5AvixKjH ejsqgO27boTItb8/ccLwax/DULNj0OuyoS8=
X-Received: by 10.55.123.132 with SMTP id w126mr3862286qkc.311.1494602741298; Fri, 12 May 2017 08:25:41 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.200.48.141 with HTTP; Fri, 12 May 2017 08:25:40 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.11.1705121118240.2058@grey.csi.cam.ac.uk>
References: <CADyWQ+GBgW9-BkNM9U9Y+9tDD29zh7ghngqhSJ5xH2awD52R=Q@mail.gmail.com> <CAJE_bqcPZ39jTEn9asaw6VJ8Qt3J_myAP4Brev9N3MBPNXodrg@mail.gmail.com> <alpine.DEB.2.11.1705121118240.2058@grey.csi.cam.ac.uk>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Fri, 12 May 2017 08:25:40 -0700
X-Google-Sender-Auth: ZkrW3dcPFTXGcFn281lbQD2xa38
Message-ID: <CAJE_bqdQhrGFe7WZCYM1UDa_JDT9qjb68woP6g86Q=s_K1Tc1g@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Cc: tjw ietf <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GPwSpwCrDgPQ3fpEWiOmWwFEHeI>
Subject: Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 May 2017 15:30:31 -0000

At Fri, 12 May 2017 11:35:26 +0100,
Tony Finch <dot@dotat.at> wrote:

> >   I'm not sure if DDNS update bolsters the need for TCP.  In
> >   my understanding DDNS update exchanges are largely done over UDP
> >   today (e.g., ISC's nsupdate utility uses UDP by default):
>
> Well, that depends on the transaction size :-) My servers fairly
> frequently handle updates containing hundreds or records.
>
> And `nsupdate` basically assumes that TCP is available - it doesn't give
> the caller a way to find out what the server's maximum update size is.
> (Similarly, my `nsupdate` wrapper `nsdiff` also assumes transactions can
> be up to 64KB in size.)
>
> So I think you'll be sad if you try to deploy an UPDATE server without TCP.

I didn't make that comment to say we can deploy DDNS without TCP.
Citing the draft text again:

   At least two new, widely anticipated developments were set to elevate
   the need for DNS over TCP transactions.  The first was dynamic
   updates defined in [RFC2136] and the second was <not about DDNS>.  The
   former suggested "requestors who require an accurate response code
   must use TCP", while the later <not about DDNS>

This read to me that DDNS elevates the need for DNS over TCP as
RFC2136 suggests to use TCP for an accurate response code (because TCP
is reliable but UDP isn't) and requestors are actually following that
suggestion.

My comment was to point out that this is probably not the case in
today's common practice: I suspect many requestors don't too much
worry about this particular point and don't really use TCP at least
for that reason by overriding utilities' default.  Of course, in some
deployments the transaction size can be quite large and require TCP.
I don't know how common such a deployment is, but regardless of that,
I don't think the current draft text tries to say that.  If the actual
intent is that large DDNS transactions can require TCP, it should
simply say so (it doesn't have to cite the above suggestion of
RFC2136; it's even a confusing distraction in that sense).  And, to
that end, it's not even specific to DDNS.  Even a normal query
response can be too large to fit in a UDP message even with EDNS(0).

So, in summary, I basically try to say I don't see anything special
about DDNS here.

Anyway, this is a pretty minor technical detail.  I don't think it
affects the overall quality of the draft very much.

--
JINMEI, Tatuya