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

George Michaelson <> Wed, 06 June 2018 22:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 788E6130DEA for <>; Wed, 6 Jun 2018 15:49:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SB7b3WGU8f95 for <>; Wed, 6 Jun 2018 15:49:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56FE1130DE1 for <>; Wed, 6 Jun 2018 15:49:38 -0700 (PDT)
Received: by with SMTP id y4-v6so5095742qka.5 for <>; Wed, 06 Jun 2018 15:49:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BoOvbITB6pUh54BHpv5LoNFzpy0+4gOR/52delANQ2U=; b=Ie9QXiYJpcFXlC0PlQ6KR8pumo06G7jKkTv3IUmC0Q5J54WvEFXGpRAI6GU2qwB2Yp t/4Wug22Twkac3JriJhMtdeqAfX2R0D9zf5gfMLgXiZ5dg9j0L3Kj9mpEfofrleiphMl oZw7Zm7td2PzWmIAfIS/9saif/pBH7BALFDcKK9yuTvISJfPSAZltP2eBLKVywi6QpxD NholrILaiq8XJMF4tLHewxIUEZfJ1Jvio6wk/qRpbi+lXvuPJiZj61ThaEYLQvSpBdvB /eDRaBJc0esdUr1bPuAyx4P+zC3gKxFvabS1s/F2G7ID4ZEYbF5C20lG2HzCfiCxyK2f 40HQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BoOvbITB6pUh54BHpv5LoNFzpy0+4gOR/52delANQ2U=; b=Oif7dZQ2UnhKVvki/O76aMATpUeYQOGUGE4YECN6RYK1U8uPDQiMDlo/XXKca2uGGT xt0/3zg3zT9Bti5Nbf6KGdS74REhVJYErZYN79MLWSGHJo7Q423DJ4ZTNOubju/XQ++j /R2uSQeVxG9FFnktmKRYG0EEfMsv8kmZjwbwPztdLql3CnnjNSyC2Fi6BxBLlCRGg15m oOiLm+z28C2vjv2285NRRNzualukERSf+h9iX2LQ6VPwP+huQyQzOsPu/EQ50k/pOzl/ jBo4fL0CunruhOOSq625+dc2QcxStq1v0YpjmOnCfvwb/B4X7mdN8ipsulMMwCqHELVg XHEA==
X-Gm-Message-State: APt69E1+kpSmfSpoI0E8PINdCHUd7M8x67SgXIlo93NDxTE7kn2Fz63P n7FSoi+lFm5Vs58fsuDtrknyNkoryi0CLrr7FgzC6g==
X-Google-Smtp-Source: ADUXVKLCu2OmXIpntTczIj3ZnBgFJ+sf4hFekNUBNGH9JriDTljmuN/L8EvykFvofL4f2/6Q6qlS00uEO3YEgRJa7Uk=
X-Received: by 2002:a37:a608:: with SMTP id p8-v6mr4127012qke.82.1528325377357; Wed, 06 Jun 2018 15:49:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:aed:32a3:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 15:49:36 -0700 (PDT)
X-Originating-IP: [2001:dc0:2001:210:5c64:b88b:26a2:a5de]
In-Reply-To: <>
References: <> <> <>
From: George Michaelson <>
Date: Thu, 7 Jun 2018 08:49:36 +1000
Message-ID: <>
To: Paul Hoffman <>
Cc: DoH WG <>, bert hubert <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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:49:46 -0000

I believe the benefits of ensuring a "flow" or "session" underpinning
means that fragmentation doesn't happen: that the effective
application (DNS as the application) layer payload is delivered UN
fragmented, is huge.

signalling that in UDP/53 it *would* have happened, maybe thats
useful. But carrying a complete, unfragmented, processable, integral
outcome, thats a huge upside benefit operationally.

Making an unconstrained, non-fragmented channel perform as if it had
the same underlying 512 Octet UDP DNS constraint in all ways, I think
is a bit silly.

So I think a constraint which effects actual end-to-end DNS flow *to
the benefit of the client* is worth doing.


On Thu, Jun 7, 2018 at 8:42 AM, Paul Hoffman <>; wrote:
> 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
> _______________________________________________
> Doh mailing list