Re: [Doh] [Ext] DNS Camel thoughts: TC and message size

bert hubert <> Thu, 07 June 2018 09:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB4C3130FE9 for <>; Thu, 7 Jun 2018 02:37:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.652
X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F-ioIGoRBomj for <>; Thu, 7 Jun 2018 02:37:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 57EF3130E86 for <>; Thu, 7 Jun 2018 02:36:59 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPS id C39889FB55; Thu, 7 Jun 2018 09:36:48 +0000 (UTC)
Received: by (Postfix, from userid 1000) id 9C3C5AC5B25; Thu, 7 Jun 2018 11:36:47 +0200 (CEST)
Date: Thu, 7 Jun 2018 11:36:47 +0200
From: bert hubert <>
To: Patrick McManus <>
Cc: Paul Hoffman <>, DoH WG <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Subject: Re: [Doh] [Ext] 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: Thu, 07 Jun 2018 09:37:02 -0000

On Thu, Jun 07, 2018 at 09:19:06AM +0200, Patrick McManus wrote:
> it seems possible that this is a property of the default media type not of
> DoH. e.g. a negotiated json response wouldn't have this kind of limitation.
> Does that make sense?

Firstly, it is not a media type limitation. It is a question of if we want
to extend DNS into a territory where it has never been before. The moment
100 kilobyte DNS answers become possible, we need to redo a ton of software.
This is true if the end transport is JSON or a DNS message wrapped into an
HTTP response.

Before typing a lot more characters on this, can I ask who is actually
arguing that we need bigger DNS messages?  Who is hurting under the 65536
byte constraint?  DNS over HTTPS implies that we have access to HTTPS.  This
protocol supports messages as large as you want.

The one reason you might like DNS to be able to do something new and large
is because you might have no alternate way of getting large data.

So I ask, who wants to fundamentally extend the DNS protocol with messages
of a size never seen or supported? Who is the customer?