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

Mark Nottingham <> Sat, 09 June 2018 13:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B19F612785F for <>; Sat, 9 Jun 2018 06:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Wgi40D6i; dkim=pass (2048-bit key) header.b=htfkYP11
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QhIrltQr2WA3 for <>; Sat, 9 Jun 2018 06:07: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 062A8127148 for <>; Sat, 9 Jun 2018 06:07:56 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 104E920B52; Sat, 9 Jun 2018 09:07:56 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute3.internal (MEProxy); Sat, 09 Jun 2018 09:07:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=yCHlI9DVVZFMLxz3RwuT8/k5hEiaW PGshH8SZiNWgLQ=; b=Wgi40D6ib8gaq2wGazRDcHgbCVi1kflB50dcyhYpxAaTv bYoBBwrfFdSUxyWMmRITs/AXRXOoYGMKuOUEdBTAU/2XjQ/J722e1S6ix5sYvie/ FPed9ONkW0r+JBMk//JfLEx36d0uC0uwuA6LWpABr7L99sHl2AXtC0RiXZmquzQ/ RhbtFc1j6lqBROzMAFml7AvOFbsuIbk/DApLjfjBuM0sJWIVSofYruCghFVW0jRB TCndPE2hoC9vEqI5BEJtXst4Rt2AU0xqxHFfM0RKTa/TrRhFb9NCCU1fzk924Gpg 7qYqQW+lXbRzUlQm4+36y/vlCdUDrqlllvVMrTb+Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=yCHlI9 DVVZFMLxz3RwuT8/k5hEiaWPGshH8SZiNWgLQ=; b=htfkYP11nUsh9JyYhFjr06 ehTNB+mgaQddW57hmsvzWHjd3tfp0rzckPB+lypUwB521WDAhph1XxjpYWQeMWmE fcBbc6NjGq6GE+CKSk0/WiqWpiSGUlXIB1UKvFCaMEWNpdQrStl3G3a1u2m8vdQT 7KvsmZ/nvK05W/eIS0wcPGXMuFWoEhO3T3YPuXCJXTWM26P2ShOHyrIsVy8YsVfl k8RWVIh4Pu5DFDjtHsIjQwExH9dwuasJPqUdhznz3H4KK94/1xONNhO+cVltcgZt SWoCFMmbFRwT6s+xbh/qFk0e3JsvaQT/rNmGKDKXm0pXs50HW3NJ3tdYmEk2fDiw ==
X-ME-Proxy: <xmx:K9EbW634iQsRsA-UFtQr3TxiPzhpbYIPKJnFMJtMzeCCfNcZXYXKDw>
X-ME-Proxy: <xmx:K9EbW7QC1Z4KTc1HTbOPGGMI885xrO5k0GsYrVhUooEo813PwjjSww>
X-ME-Proxy: <xmx:K9EbW5PDfckrsn5MMAIKDZSOs0eE1LMrGRdqvnuCCRK0JQjJ35GMaw>
X-ME-Proxy: <xmx:K9EbW_scJ3G675e3iNe-weRwcgbweXjAkXSfMMShmfg9pUvPZMkYqQ>
X-ME-Proxy: <xmx:K9EbWxLlXJiU2lqet-amQji96wX8nQqrPhaEiXJckjZ_rBO9u7oqeQ>
X-ME-Proxy: <xmx:LNEbWylLB839KGitCaEWG3Xnj00oA_yGgGY0fPRwOcQFtjAiTd5Kyg>
X-ME-Sender: <xms:K9EbW96kTpZW-e_SsFiyqrmNgrQ-AkL7haM2fSIiwxpikVmSDEUONw>
Received: from [] ( []) by (Postfix) with ESMTPA id 0B92AE464A; Sat, 9 Jun 2018 09:07:54 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Sat, 9 Jun 2018 15:07:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Andrew Sullivan <>
X-Mailer: Apple Mail (2.3445.8.2)
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: Sat, 09 Jun 2018 13:07:59 -0000

Hi Andrew,

> On 8 Jun 2018, at 7:07 pm, Andrew Sullivan <>; wrote:
> I don't have any trouble saying, "We are actually just going to insist
> on assuming a clean, modern architecture; things that make assumptions
> not justified by the letter of the RFCs -- including assumptions about
> transport -- are going to be broken."  But I think that's the sort of
> principle that really does need to be written down somewhere.  At the
> moment, the I-D is too cute about this:

"Cute" is a very loaded term.

>   The integration with HTTP provides a transport suitable for both
>   existing DNS clients and native web applications seeking access to
>   the DNS.
> As several posters have already pointed out, this is only true if you
> accept a somewhat unusual meaning of "existing DNS clients".  Those
> clients are going to have assumptions in them, and they are
> assumptions that are based on more than 30 years of deployment -- an
> eternity on the Internet.
> Architecture inheres not only in how the elements of the thing fit
> together, but also how the thing fits with everything else.  In this
> case, we have to fit with the deployed Internet systems.  It is
> perfectly fine to decide that 64k is not enough for anybody.  But if
> that's an assumption we're going to modify, then I think we are in
> fact specifying a new architecture for the DNS, and we need to be less
> glib about that.

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).

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.


Mark Nottingham