Re: [Doh] a tad confused on response sizes

Dave Lawrence <> Tue, 05 June 2018 13:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE77F131012 for <>; Tue, 5 Jun 2018 06:02:34 -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 YPCn5few-hyQ for <>; Tue, 5 Jun 2018 06:02:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AE4B130DF3 for <>; Tue, 5 Jun 2018 06:02:28 -0700 (PDT)
Received: by (Postfix, from userid 102) id 6A5CC23720; Tue, 5 Jun 2018 09:02:26 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Tue, 5 Jun 2018 09:02:26 -0400
From: Dave Lawrence <>
To: bert hubert <>
In-Reply-To: <>
References: <>
Archived-At: <>
Subject: Re: [Doh] a tad confused on response sizes
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, 05 Jun 2018 13:02:35 -0000

bert hubert writes:
> This seems says sending a TC response is some kind of error, which
> implies a DNS API server should be willing to send 65 kilobyte
> answers.

Yes, based on previous conversations, this is basically the case --
though not just 6kk, but theoretically even longer.  While 64k is the
limit on DNS/TCP, it is not an intrinsic limit of DNS wire format

Note, I'm not advocating that DoH servers should be sending such large
messages, just that like with other HTTPS messages there is no hard limit.

> I think for the new usecases, this would be a fine default. However, there
> might be UDP-to-DOH bridges which would then need to put explicit EDNS
> buffersize of 512 in there if they get non-EDNS adorned UDP queries.

Right, there is a separate matter of handling transparent proxies, but
for the basic use case a client/server should not have to muck around
with the network limitations of the DNS protocol.  That's one of the
wins of using HTTPS.

> I can supply text that will hopefully make this explicit and
> unconfuse future implementers.

Excellent, but do note that we are on the cusp of moving the document
along.  Please do so quickly for the authors to evaluate.