Re: [Doh] [Ext] DNS Camel thoughts: TC and message size

Dave Lawrence <tale@dd.org> Thu, 07 June 2018 16:54 UTC

Return-Path: <tale@dd.org>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C640130F62 for <doh@ietfa.amsl.com>; Thu, 7 Jun 2018 09:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 cT3ekYhb2Hgr for <doh@ietfa.amsl.com>; Thu, 7 Jun 2018 09:54:18 -0700 (PDT)
Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DD2130F5E for <doh@ietf.org>; Thu, 7 Jun 2018 09:54:17 -0700 (PDT)
Received: by gro.dd.org (Postfix, from userid 102) id 803E1299B2; Thu, 7 Jun 2018 12:54:16 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <23321.25400.502754.584769@gro.dd.org>
Date: Thu, 7 Jun 2018 12:54:16 -0400
From: Dave Lawrence <tale@dd.org>
To: DoH WG <doh@ietf.org>
In-Reply-To: <5B71AC15-80F4-427B-BABA-1BE3C514145F@icann.org>
References: <20180606093212.GA23880@server.ds9a.nl> <alpine.DEB.2.11.1806061501340.10764@grey.csi.cam.ac.uk> <F5774061-35B9-477F-ADDA-8BB3472F30EF@icann.org> <alpine.DEB.2.11.1806071121350.1809@grey.csi.cam.ac.uk> <5B71AC15-80F4-427B-BABA-1BE3C514145F@icann.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/QsDZV8khi--BuIPnHEjWx_cKhjo>
Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2018 16:54:27 -0000

Paul Hoffman writes:
> Tony is completely correct here. DNS messages have well-defined
> length limits: 512-or-more-depending if carried over UDP, and 65535
> if carried over TCP. 

Right.  And completely undefined over any other transport.  There is
no intrinsic limit to the limit of a DNS message, compression pointers
notwithstanding.  I could give you a parser that would happily churn
though a multi-megabyte DNS message.

I was among the first advocating for making it clear that there
needn't be an unnecessary limit imposed here, and I still stand by my
position though at the moment it looks like I'll end up on the wrong
side of consensus.  My point is that when there is not a strict
technical need driving some limit, I don't think it should be there.
Have we learned nothing of scaling on the Internet over all these
years?

While "existing DNS message parsers might have a problem with it" is a
legitimate potential issue, I don't see it as a compelling need to
drive the requirement.  It isn't even a given that all existing
parsers would have a problem with it.  In any event that's something
that should be looked at by the programmer before just blindly pumping
data through.

There's even a use case for going beyond 64k, AXFR.  Despite Tony's
other message claiming that AXFR needs multiple messages, that's not
fully accurate.  I have plenty of zones that fit in a single DNS/TCP
message when sent over AXFR, and DNS/HTTPS would cover the rest quite
easily, except with a restriction on message lengths it actually makes
things a bit more complicated.

I will readily admit that I personally don't currently have a plan to
start doing AXFR over DoH.  My point is that this isn't just purely
academic, but actually has some practical applications.

My personal take is that, given that there is no strict technical
limit for imposing a limit inside a transport that doesn't require it,
the existing "any size" text should remain, and be augmented with a
warning to developers about how that could be an issue with existing
code that assumes no message can be greater than 64k based on earlier
transport definitions.