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

Dave Lawrence <> Thu, 07 June 2018 17:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9172130F75 for <>; Thu, 7 Jun 2018 10:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YvaF3tEKl3HW for <>; Thu, 7 Jun 2018 10:21:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C64D013113F for <>; Thu, 7 Jun 2018 10:21:23 -0700 (PDT)
Received: by (Postfix, from userid 102) id 17E38299D7; Thu, 7 Jun 2018 13:21:23 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Thu, 7 Jun 2018 13:21:23 -0400
From: Dave Lawrence <>
To: DoH WG <>
In-Reply-To: <>
References: <> <> <> <> <> <>
Archived-At: <>
Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jun 2018 17:21:32 -0000

> Before typing a lot more characters on this, can I ask who is actually
> arguing that we need bigger DNS messages?  Who is hurting under the 65536
> byte constraint?

Me, and not me.  The two questions are orthogonal.  

Tautologically, putting in limits results in limits -- limits on what
could be built if the limits were not in place.  I'm personally not
particularly hurting right now, though I do know of some people who
are in fact having trouble with large zone transfers that could be
ameliorated with HTTPS restarts (or, of course, by shoehorning some
other data transfer method in).

Beyond pain, I can't really tell you what interesting applications
that would us a hierarchically distributed public database are going
uninvented because of the existing limits.  Give people more powerful
tools and they can build more powerful things.

> I don't want to constrain what those new types might do based on our
> current understanding. For instance some media types might be very
> space inefficient but super efficient to access.. and we might fix
> that on the wire with a http compression encoding. heck maybe they
> come back as jpeg visualizations; I'm not here to judge.


> If we buy my argument then we don't so much as restrict DoH as note
> that the wireformat media types effectively have this limitation
> already that needs to be respected.

"Sort of".  Wire format itself does not have the limitation.  Its use
on certain transports does.  This distinction needs to keep being