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

Paul Hoffman <> Wed, 06 June 2018 22:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A89A130FE5 for <>; Wed, 6 Jun 2018 15:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ElxV1Yr7KMM7 for <>; Wed, 6 Jun 2018 15:42:11 -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 2A752130DE1 for <>; Wed, 6 Jun 2018 15:42:11 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 6 Jun 2018 15:42:08 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1367.000; Wed, 6 Jun 2018 15:42:08 -0700
From: Paul Hoffman <>
To: DoH WG <>
CC: bert hubert <>
Thread-Topic: [Ext] [Doh] DNS Camel thoughts: TC and message size
Thread-Index: AQHT/eeZrdvRGu1kHUiE0BSLfpZdOQ==
Date: Wed, 6 Jun 2018 22:42:08 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 06 Jun 2018 22:42:13 -0000

I hear a lot of support for Bert's wording:
   Specify that DNS messages carried over
   DOH can be up to 65536 bytes large and note that truncation should be
   handled as if the response was carried over TCP/53.

This thread has brought up a significant concern that I hope those supporting the language can clear up.

On Jun 6, 2018, at 7:18 AM, Tony Finch <>; wrote:
> I think the semantics of a DNS message transported over HTTPS should be
> the same as for DNS-over-TCP, wrt truncation, EDNS buffer sizes, and so
> forth.

Three people agreed with this statement. DNS-over-TCP is defined in RFC 1035 and significantly updated in RFC 7766. Unless I'm missing something, neither of those document support the 65535 length restriction; in fact, RFC 1035 section 3.3.10 indicates that restriction doesn't exist because a response with a single maximally-sized NULL Rdata record could be slightly longer than that, and there is no restriction on how many NULL records can be in the RRset. Such a message could not use name compression into the a section beyond the Answer in that message. Similarly, there is no restriction on the total length of a TXT record. Having such records is clearly a bad idea, but they are not prohibited by the specs.

So, if this WG puts such a limitation in DOH, we are adding a restriction to DNS messages that is not currently in DNS-over-TCP, even though it is a "sensible" restriction. If we do so, I would hope that (as a separate effort) we would get the DNSOP WG to start an update RFC 7766 to have the same restriction. If we don't want to do so, it would be better to only add the following from Bert's proposal (slightly reworded):
   DNS message truncation and the use of the TC bit should
   be handled as if the response was carried over DNS
   in TCP as defined in [RFC7766].

As document author, I'm OK with either outcome, but would prefer the second just because it doesn't require asking the DNSOP to have to add polish to an existing camel toe.

--Paul Hoffman