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

Ben Schwartz <> Wed, 13 June 2018 18:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF10D130F75 for <>; Wed, 13 Jun 2018 11:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -18.21
X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k3inRfZ6eoom for <>; Wed, 13 Jun 2018 11:16:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 823D8130F69 for <>; Wed, 13 Jun 2018 11:16:24 -0700 (PDT)
Received: by with SMTP id d22-v6so4403775iof.13 for <>; Wed, 13 Jun 2018 11:16:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fogyiRmCpjTi6OlbZUkseOc8KzAGfqTCtYgTgrelY8c=; b=LpyFrUBRiC+bBvs6w8tTC3+x1hbgR4aXSeoCwdkkZoKNBlAEi30e60xqQdJuymNrIX 0epAyhdGCbmieIPiDJYbkTY+990pHRjRdapzL2Lm+ESdQZN82v1AoUaM2xoi9Ie26Jo6 +zyl1X4cDt1JV307zmNst99mrr8zwCDuNw58v46erKOQOuxJ6r76qzGz4z3od4w1AZSp JQHcPFwnwZNu61Mih5l9TWmJ4bYEF8y3IfyDGGCUvAG8Kjf1g48aPQg2+AvGON6cC38Q NTHiAuTVbjdjsRXXhPlw1gIWVyIT3gmdzf8npeNEXrTjjNHLX/3jSphkLuTJxqAA7PDh SlgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fogyiRmCpjTi6OlbZUkseOc8KzAGfqTCtYgTgrelY8c=; b=mbC5XZqZNi9a2L6f9GcSXAtsI0XSQY6YCiSEoeDOQmX9zLBdTOvfmaz4E1LRiTUwY5 pLQkMqrCoaG07FH6k3/QFXOo3VGOlitIew0lkfakQCV02fSetWlwkNTSp8BZLVMfums1 D49zzYz8COBN5KKN5V5kZJtuAUJCs/n0hBNgLKRYcm9YiQAV9fwxfK8FHJNf+6Y9lt9M fUrjzPmFFdvLnAU2lZso2Bc19y2rH3ssG4Tp+W69VcdsV6XXOQ5bZhdM16pO2gIcQKSM wUwhbw7I6LXICuKoKspC5SjNCA5GeRNaSul9jGrSReAsw58mMgehzxqFK2+Se6kIEnYj WJLQ==
X-Gm-Message-State: APt69E3zXXuYOV9AHWMjhoaj+DnWkRU7coRrv/nQaFXzt+zmlbTzcY65 iy/DAuv8GVt36XzFSzk6eK41nWsuEspQ8C2g2CCJOTbbXc8=
X-Google-Smtp-Source: ADUXVKLTQ8obXnHvu/NGs9k7mVCuYaeCzyvw+A4evnEC5G7VPcLQO0L0noDhLfMOkmy6pRc4rHB7QxaK+kTMq6gubpM=
X-Received: by 2002:a6b:df45:: with SMTP id d5-v6mr5461123iop.230.1528913783425; Wed, 13 Jun 2018 11:16:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Wed, 13 Jun 2018 14:16:11 -0400
Message-ID: <>
Cc: DoH WG <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000fe0f25056e89fa4e"
Archived-At: <>
Subject: Re: [Doh] [Ext] 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: Wed, 13 Jun 2018 18:16:28 -0000

On Wed, Jun 13, 2018 at 1:47 PM Petr Špaček <>; wrote:

> On 13.6.2018 00:19, Paul Hoffman wrote:
> > On Jun 12, 2018, at 2:46 PM, Ray Bellis <>; wrote:
> >> I do think it would be helpful to consider in more detail where DOH is
> >> expected to sit in the DNS architecture.
> >
> > This is the DNS: "is expected" almost always turns out to be wrong. (No
> smiley appended.)
> >
> > The same can be said for HTTP.
> >
> >> Is it going to be a new "first class" transport (sic) protocol, or is it
> >> merely a tunneling protocol for carrying DNS messages whose sole purpose
> >> is to provide interworking for those that cannot use the "normal"
> >> transport protocols because either a) there's a stoopid middlebox in the
> >> way, or b) they're a web client ?functional
> >
> > These are good questions, but if we try to base our protocol on what "is
> expected" and our expectations turn out to be wrong, we will probably
> design the protocol badly.
> I think Ray was too shy to ask The Question:
> Is the goal of the current doh WG
> a) "standardize encodings for DNS queries and responses
> that are suitable for use in HTTPS. This will enable the domain name
> system to function over certain paths where existing DNS methods (UDP,
> TLS [RFC 7857], and DTLS [RFC 8094]) experience problems." in an
> interoperable way, i.e. doing a thing the WG was chartered to do?
> OR
> b) Invent DNS 2.0 and attempt to hide that the proposal goes beyond the
> original DNS protocol? We badly need DNS 2.0 so let's admit that, it is
> not a shame.

I appreciate your concern but please try to avoid accusing members of the
working group of trying to hide anything.

The question of what message size limits to require or recommend does not
resemble an attempt at any kind of "DNS 2.0".  Note that message size
interoperability questions are not a new issue within the DNS: many
endpoints will reject messages larger than 4K or 8K, even though there is
no way to signal this limitation.  HTTP has similar issues (e.g. URL length

The charter does not require that the standard guarantee functionality in
all possible use cases and multi-system interactions, and both choices (to
apply a limit or not) fail to serve a desirable use case: either we don't
support 100% reliable gateways from DoH into DNS-over-TCP, or we don't
support large zone transfers over DoH.  It's up to the working group to
balance these concerns, either by choosing one option or by finding a
middle ground.

So far, I've heard two middle-ground proposals: a new media type for >64K
DNS messages, or usage of multipart/related to deliver multiple DNS
messages in a DoH response.  I hope the working group will seriously
consider these proposals, or other ways to satisfy both of the desired use
cases above.

> If the answer is b) then I will applaud and support doh doing DNS 2.0,
> we only need to stop pretending that current doh work is just a new
> transport for the original DNS.
> My reading of the doh charter is that doh protocol is a transport which
> should help to get the existing DNS to endpoints. Changes beyond
> existing DNS semantics are work on DNS 2.0 and thus outside of current
> doh charter.
> I strongly support work on DNS 2.0 but we must not pretend that it is
> still the original DNS with minor tweaks, and recharter doh to admit that.
> Clean cut will make all discussions about "what happens if there is a
> dumb proxy" moot because it will be clear to everyone that "doh is going
> to be DNS 2.0".
> Or even better, let's use a new name for the new protocol:
> HTTP naming system (HNS)
> and do not confuse everyone with references to the legacy DNS.
> Can we get consensus call to answer what doh WG participants want to do?
> a) just do new transport for the existing DNS
> OR
> b) invent "HTTP naming system" without the burden of legacy DNS
> (HNS == DNS 2.0)
> Can we get clear answers to this question? Pretty please!
> --
> Petr Špaček  @  CZ.NIC
> _______________________________________________
> Doh mailing list