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

Dave Lawrence <> Wed, 13 June 2018 04:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED9A0130DD8 for <>; Tue, 12 Jun 2018 21:10:41 -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 7w-QFg1GpRA8 for <>; Tue, 12 Jun 2018 21:10:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B387130DD0 for <>; Tue, 12 Jun 2018 21:10:38 -0700 (PDT)
Received: by (Postfix, from userid 102) id 0CB0B2F692; Wed, 13 Jun 2018 00:10:35 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Wed, 13 Jun 2018 00:10:35 -0400
From: Dave Lawrence <>
To: "doh\" <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
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 04:10:43 -0000

Paul Hoffman writes:
> On Jun 11, 2018, at 2:52 PM, Dave Lawrence <>; wrote:
> > 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.
> Great! Let me try again.
> The DNS message format is defined specifically for two
> transports. Looking at the format without looking at the transports,
> one can imagine a message that cannot be carried in either
> format. However, the original specifications and all the ones since
> have always treated the message format as being handled in one of
> the two transports. 
> When we define a new transport that allows messages different than
> the ones we have always assumed, gatewaying those different messages
> will be different than gatewaying between the two current transports
> and thus have an impact on the rest of the DNS. 

We appear to be two technical geeks separated by a common language.
I'm not sure where either my phrasing has gone wrong or I have not
understood yours.  In either case I apologize for my failing.

What I am looking for is a concrete example of how any pre-DoH clients
or servers are is going to have any sort of problem if a DoH DNS wire
format message exceeds 64k -- a specific mechanism for specific old
software that will react badly to an unexpectedly large message being
fed to it, where it hasn't gotten there as a result of new code that
could easily prevent it.

This is the sort of concern that we've had to worry about in the past
with the DNS and for which we did have concrete answers about
implementations that would have issues with a non-zero ADCOUNT in a
request or the semantics of a KEY RR changing or using compressible
names in rdata of new types or so on.  All of those things impacted
messages that existing servers would see.

As far as I can tell there is no way that the pre-DoH DNS/UDP and
DNS/TCP world can even be aware of the existence of DoH and its
potentially 64k+1 messages because nothing at all is being changed for
the messages that the existing code sends and receives.  You could
spin up a BIND 4 instance in a world of unlimited-DoH and it would
still work just as it always did.

The generalized gateway examples you give don't challenge this.  The
DNS/UDP an DNS/TCP network are still not impacted; they weren't able
to carry messages greater than 64k before, and they still won't after.
No change to their inputs, their outputs, or their behaviour.

I believe that makes not imposing a 64k limit on DNS fall within the
bounds of the charter.  In fact, I could make a case that it goes
right to the first paragraph:

  This working group will 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

... in addressing cases where existing methods experience problems.
I'm not going to get too hung up on rules-lawyering that argument
though, it's a sideshow.

Per our out-of-band conversation, I will later this week (new $dayjob
intrudes) be offering text for the proposal I made in another message
about using two mandatory-to-implement media types right out of the
gate, differing only in that one has a Content-Length limit.
Implementers can then choose to make it plainly explicit that they
are sticking to legacy TCP limits.