Re: [Doh] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size)

bert hubert <> Mon, 11 June 2018 20:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6344130EC9 for <>; Mon, 11 Jun 2018 13:21:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.652
X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ripFBdO8EUsc for <>; Mon, 11 Jun 2018 13:21:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 88780130EC4 for <>; Mon, 11 Jun 2018 13:21:32 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPS id AD1859FB55; Mon, 11 Jun 2018 20:21:30 +0000 (UTC)
Received: by (Postfix, from userid 1000) id 4A39CAC621C; Mon, 11 Jun 2018 22:21:30 +0200 (CEST)
Date: Mon, 11 Jun 2018 22:21:30 +0200
From: bert hubert <>
To: Dave Lawrence <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Subject: Re: [Doh] Are we missing an architecture? (was Re: 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: Mon, 11 Jun 2018 20:21:35 -0000

On Mon, Jun 11, 2018 at 12:52:02PM -0400, Dave Lawrence wrote:
> What's genuinely surprising to me is that of all the interesting
> architectural issues which come along with DoH, it's only message size
> that caused such debate.  It's not quite bike-shedding but it's in
> rock-throwing distance of it.

Perhaps this is at the root (or apex!) of our disagreement.  It is
relatively harmless to innovate at speed at the outer edge of DNS.  Because
various people (including me) are now implementing & deploying versions of
this draft already, I think we can reasonably conclude that what we are
doing is not obviously broken.  Worst we can do is deliver a sub-optimal DOH

Any changes that impact the core of DNS however have far bigger consequences
and will lead to a lot of work down the road.  We have not overseen, and in
fact can not yet oversee, all the consequences of the existence of newly
increased message sizes.  This is not what our proxies and experiments are
testing at the outer edge of DNS.

Specifically, I know we have no defined semantics for what a TCP DNS speaker
is supposed to do if it finds it has to truncate a response, nor what anyone
on the receiving side should do if it receives such a truncated message. And
once large DNS messages can exist, this becomes an issue. 

I (and many others) consider the existing DNS to be extremely complicated
and tricky enough already, and I'd hate to burden it with new dimensions
before we have really thought it through.  This goes beyond "I don't think
there should be problems". It needs the level of "after serious and
prolonged thought, we have identified what needs to be done".

The entire open source DNS community opined here that they too don't want to
go "large dns message" now, and I suspect this is because their spidey
sense, like mine, is tingling that trouble and complexity could be ahead -
for uncertain gain.

So maybe that explains why this part is getting bike-shedded, and many other
parts of DOH are not. We worry about core DNS complexity.