Re: [Doh] [Ext] a tad confused on response sizes

Paul Hoffman <> Tue, 05 June 2018 14:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39ED013107D for <>; Tue, 5 Jun 2018 07:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ECD9jEp4EuyJ for <>; Tue, 5 Jun 2018 07:13:04 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C246F131055 for <>; Tue, 5 Jun 2018 07:13:04 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 5 Jun 2018 07:13:02 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1367.000; Tue, 5 Jun 2018 07:13:02 -0700
From: Paul Hoffman <>
To: bert hubert <>
CC: "" <>
Thread-Topic: [Ext] [Doh] a tad confused on response sizes
Thread-Index: AQHT/MWCHKfSaHDR5060bxLSfOCW76RSKm2A
Date: Tue, 5 Jun 2018 14:13:02 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_CB4ABEEA-5066-4A5C-8B19-97F2535D4C62"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Doh] [Ext] 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 14:13:06 -0000

On Jun 5, 2018, at 5:05 AM, bert hubert <>; wrote:
> Dear DOH-people,
> As I'm implementing DOH in dnsdist (expect something you can try later this
> week), I am a bit confused.
> The question is what maximum response size I should send in the absence of
> an EDNS buffer size.  So let's say a query comes in without EDNS for
>, but the answer exceeds 512 bytes.  Should I truncate?
> I have read the draft and previous discussion, which has led to:
> 	Also note that while [RFC1035] says "Messages carried by UDP are
> 	restricted to 512 bytes", that was later updated by [RFC6891].  This
> 	protocol allows DNS on-the-wire format payloads of any size."
> This is not explicit on what an implementation should do, only what the
> protocol could support. Some further text:
> 	A DNS API server is allowed to answer queries with any valid DNS
> 	response.  For example, a valid DNS response might have the TC
> 	(truncation) bit set in the DNS header to indicate that the server
> 	was not able to retrieve a full answer for the query but is
> 	providing the best answer it could get.  A DNS API server can reply
> 	to queries with an HTTP error for queries that it cannot fulfill. 
> 	In this same example, a DNS API server could use an HTTP error
> 	instead of a non- error response that has the TC bit set.
> This seems says sending a TC response is some kind of error

Not at all. The first sentence is quite explicit. 

> , which implies
> a DNS API server should be willing to send 65 kilobyte answers.

...if it wants to, yes.

> 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.

Bridges and proxies and gateways, for any protocol, always have to make these kinds of decisions. 

> If the '65 kilobyte' interpretation is correct, I can supply text that will
> hopefully make this explicit and unconfuse future implementers.

Sure, please do.

--Paul Hoffman