Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

Joe Abley <> Tue, 09 November 2021 00:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C9D03A08C4 for <>; Mon, 8 Nov 2021 16:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wLiBhmStOBES for <>; Mon, 8 Nov 2021 16:24:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E7123A088F for <>; Mon, 8 Nov 2021 16:24:05 -0800 (PST)
Received: by with SMTP id de30so3174973qkb.0 for <>; Mon, 08 Nov 2021 16:24:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=bSQpdYbaqhi7/UwT3Xo/Pm9GG2oj+ZJ8/sNeh3P3bKc=; b=eJ5VvxNy92jdpisGUcMO7LBliJMpG1Tu8cqTXEkv//q/PVlLj7qKdcnWj6jjoWAf2a rOM72WJz2C+VdrsTe1lMdh4yEUMrWw14ruPNnPxaBmlNViJ39Z05sIU0hz1rxLOo7xbI Qs+CJUhe/qau0beH/0MNXF//DrKafVPZp2ecE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=bSQpdYbaqhi7/UwT3Xo/Pm9GG2oj+ZJ8/sNeh3P3bKc=; b=JqnRhjEWI9NVZeF0IGo2u7dRItDiIzK0ojoV8obxMPNUcbccwrpZU0Et8tB68slG6s yRvSsBBTGkMIlrPPRSk/ff4S/ZCm1hB8TpXYLPt6D4V/d1peNwNxzXwMoTSvLHVSARaF yl2Q2OYwMSSRlLde/UhuDBoMIa4Vf3JZbIWA0OZ6S4k65cMCmsQyybyhIGJoCW1bts+M t9FjgGUOQZh9Lwc+CUwQyGOeSItqN6CcQI0GLyfY1RHiXTyEYNAPyvOqt6OA0CZr14jw CH1i21HMtDL3m/zUXxQMWZXk44CFPDs5HveAVcLa6czCz881EoYCYAqz3cTIgU1XnTdf X/AQ==
X-Gm-Message-State: AOAM530pxMgS6TVPZEtRpus5c585PpKOtZL6UYhECA/tguJlzUhyWN5a VNNmHOQwrcH+7Z1iNw+ienkVSQ==
X-Google-Smtp-Source: ABdhPJyePGA4bI0uNpCWkF54y/XbRXhTt8a+q0StaDzPxOR2+PKQCUJ/GoNy66hA+uFAdS9wt29QLA==
X-Received: by 2002:a05:620a:461f:: with SMTP id br31mr2666187qkb.436.1636417443550; Mon, 08 Nov 2021 16:24:03 -0800 (PST)
Received: from ([2607:f2c0:e784:c7:450d:3edb:4729:787]) by with ESMTPSA id 73sm3004474qkm.94.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Nov 2021 16:24:03 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
From: Joe Abley <>
Mime-Version: 1.0 (1.0)
Date: Mon, 08 Nov 2021 19:24:02 -0500
Message-Id: <>
References: <>
Cc: Benjamin Kaduk <>,,, Suzanne Woolf <>,, The IESG <>
In-Reply-To: <>
To: "Wessels, Duane" <>
X-Mailer: iPad Mail (19B74)
Archived-At: <>
Subject: Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Nov 2021 00:24:10 -0000

On Nov 8, 2021, at 17:35, Wessels, Duane <> wrote:

> Is this better?
>   The use of TLS places even stronger operational burdens on DNS
>   clients and servers.  Cryptographic functions for authentication and
>   encryption requires additional processing.

Require, not requires. I know, I know.

>  Unoptimized connection
>   setup with TLS 1.3 [RFC8446] takes one additional round-trip compared
>   to TCP.  Connection setup times can be reduced with TCP Fast Open,
>   and TLS False Start [RFC7918].  TLS session resumption does not
>   reduce round-trip latency becase no application profile for use of
>   TLS 0-RTT data with DNS has been published at the time of this
>   writing.  However, TLS session resumption can reduce the number of
>   cryptographic operations.


> Agreed, hopefully this is better:
>   o  Authoritative servers MUST support and service TCP for receiving
>      queries, so that resolvers can reliably receive responses that are
>      larger than what fits in a single UDP packet.

RFC 6891 anticipates reassembly and doesn't advise against setting a UDP payload size that would cause fragmentation (although it mentions that people should be careful). So "single UDP packet" seems a bit awkward, especially since in principle the size limit is 0xffff octets in both the UDP header and the corresponding EDNS(0) pseudo-header.

This paragraph (and the ones that follow) seem like they are implying that large responses are the only reason to use TCP (which is surely just a side-effect of wording; I'm not suggesting the authors are unaware of other reasons). Using truncated responses as an example seems fine though.

I don't think the taxonomy of "authoritative servers", "recursive servers" and "forwarders" is necessarily complete. The terminology in common usage is not tightly bound by common sense, and there is an apparently unlimited supply of words and phrases that people use to mean "a DNS thing attached to a network".

This seems like it could be a job for "initiators" and "responders", except that in this case I think we're really talking about all DNS implementations, regardless of function. Hooray! Bullet dodged, maybe.

How about something like:

 o All DNS implementations, regardless of function, MUST support and service TCP for sending and receiving queries, e.g. to accommodate the sending and receiving of DNS messages that are too large to handle using UDP without truncation.