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

Andrew Sullivan <> Sun, 10 June 2018 16:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA6CE130E81 for <>; Sun, 10 Jun 2018 09:32:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=nlDQsrL2; dkim=pass (1024-bit key) header.b=RkK8A+qt
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n9fq6gdhbTBo for <>; Sun, 10 Jun 2018 09:32:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2500A130E7C for <>; Sun, 10 Jun 2018 09:32:57 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A2EDBDEF9 for <>; Sun, 10 Jun 2018 16:32:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1528648376; bh=gW+PjnpS1GMyi9TXDoSyZutfuwjkeTjUB9V9BLpXCLk=; h=Date:From:To:Subject:References:In-Reply-To:From; b=nlDQsrL2mPKssq6VxtiNm/1DsivJwsLwMUyjzuCShNAOOdAkMs3/gbZ3aiV5TSAME wgEgE1wWJ4Zis+Y3ftUfKI3VJXKq/B2KBy/KoRvk2L/mcPvq1u7j4AWo9WVdciiRHr q6EiMGXeQRIIKiYowy+d/nMervmJskyJ/8NqNi+8=
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6PGWgaG-nQwg for <>; Sun, 10 Jun 2018 16:32:55 +0000 (UTC)
Date: Sun, 10 Jun 2018 12:32:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1528648375; bh=gW+PjnpS1GMyi9TXDoSyZutfuwjkeTjUB9V9BLpXCLk=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RkK8A+qtn+4SQzBo4Mz5EoJqGs/CEb/oj0IqTeMJF/0ZU5+rmc56hYgDRguHUY8u1 9KU4x+aEqP/QOyybCh5wLvoy2RH24ggp4rmGIZ8vc1Btij5qwCDWx5J1xabTR5qzO+ k2Nz0eIsnleD59DvqT/LGBc22NjheSgtNl0+5EQo=
From: Andrew Sullivan <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
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: Sun, 10 Jun 2018 16:32:59 -0000


On Sat, Jun 09, 2018 at 03:07:53PM +0200, Mark Nottingham wrote:
> "Cute" is a very loaded term.

Apologies; I didn't mean to be loaded.  I just mean that the claim is
either true in a pretty unusual way, or it isn't really true.

> Or we could just change "clients" to "client use cases," thereby removing the implication that it'll work when dropped in front of any existing client library (which isn't terribly interesting anyway, IMO).

Well, you might not find it interesting, but people who have been
struggling with the limitations of DNS for a long time might find it
interesting and might try to plumb their bog-standard DNS systems
through this new transport -- especially if the document says that
it's suitable for such use.

> DNS may very well need a new architecture, but loading this responsibility onto DOH post-WGLC is asking too much of it, and is unfair to the folks who brought this work to the IETF in good faith.

If that is true, then it is illegitimate in the IETF context to notice
a technical issue late in any document's life cycle and raise it.  I
don't think that's how the IETF works, and I think it would be an
abuse of rough consensus to insist that, because a problem shows up
late it shouldn't be taken into consideration since people brought
work to the IETF in good faith and had been working on it.

But in any case, my point is just that, whether we like it or don't,
we are _in fact_ making a new architecture in this effort, and we're
doing it with assumptions that appear not to line up correctly across
the sub-communities who are working on the problem.  That ought not to
be too surprising: these are two important protocols that work in
quite different ways, and the people who have worked on them over
time, unsurprisingly, have developed different intuitions about what
to expect.  If we put them together, we're gong to find differences.
It takes time to draw those out, and now we have drawn out an
expectation that some people have because people have attempted to
work through what the I-D will mean in practice.  We ought to be
pleased that we discover these corners now.

Best regards,


Andrew Sullivan