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

Dave Lawrence <> Mon, 11 June 2018 21:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 92B5E131095 for <>; Mon, 11 Jun 2018 14:52:34 -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 u7cSQ1BcHjQM for <>; Mon, 11 Jun 2018 14:52:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 163F3130EF7 for <>; Mon, 11 Jun 2018 14:52:28 -0700 (PDT)
Received: by (Postfix, from userid 102) id 17CA532AD0; Mon, 11 Jun 2018 17:52:27 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Mon, 11 Jun 2018 17:52:27 -0400
From: Dave Lawrence <>
In-Reply-To: <>
References: <> <> <> <> <>
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 21:52:41 -0000

bert hubert writes:
> 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.

I hear you, I really do.  I don't think it is surprising that someone
might worry.  I too have concern about the overall health of the DNS
ecosystem, and I do not cavalierly make my arguments without regard
for it.

But spidey sense is not a technical argument, and worry is not a great
basis for making decisions.  So what do we do when we have vague
feelings?  Well most analytical computer folks, including you I bet,
puzzle it out to find out the root of the issue.  So far in my
puzzling I've been unable to think of any realistic scenario where the
deployed DNS software is at risk here.

If there were even one solid example of how this impacts the rest of
the DNS, I'd certainly be willing to reconsider my position.  And I
can certainly see that consensus of the open source DNS community
carries a lot of weight.  I just want it to be clear, for the list now
and for the posterity of the archives, that if that's the way it goes
then it was not a technical decision that drove it and it comes with
its own set of consequences.