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

Tom Pusateri <> Tue, 12 June 2018 22:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FA98130FAC for <>; Tue, 12 Jun 2018 15:02:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z7FfXyDsmFUe for <>; Tue, 12 Jun 2018 15:02:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 59A1E130FC4 for <>; Tue, 12 Jun 2018 15:02:13 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 86C30533; Tue, 12 Jun 2018 18:01:23 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Tom Pusateri <>
In-Reply-To: <>
Date: Tue, 12 Jun 2018 18:02:11 -0400
Cc: David C Lawrence <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Paul Hoffman <>
X-Mailer: Apple Mail (2.3445.8.2)
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: Tue, 12 Jun 2018 22:02:17 -0000

> On Jun 11, 2018, at 9:51 PM, Paul Hoffman <>; wrote:
> 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.
> The WG charter we are working under clearly says:
>  Specification of how DNS-formatted data may be used for use cases beyond
>  normal DNS queries is out of scope for the working group.
> Creating new queries, to me, seems "beyond normal DNS queries".
> --Paul Hoffman

If there is an uncertainty about how DoH will interact with existing message sizes, then this can be alleviated by having DoH use the TCP wire format instead of the UDP wire format. While the two byte length prepend is not necessary for HTTP, it will prevent the unknown translations that some people seem to be concerned about.

Then a future media type can be defined in another spec to handle larger messages.