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

Dave Lawrence <> Fri, 08 June 2018 21:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 610F9131048 for <>; Fri, 8 Jun 2018 14:31:27 -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 fGEHK9K4zpg4 for <>; Fri, 8 Jun 2018 14:31:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E630131047 for <>; Fri, 8 Jun 2018 14:31:25 -0700 (PDT)
Received: by (Postfix, from userid 102) id 42A6823E96; Fri, 8 Jun 2018 17:31:24 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
Date: Fri, 8 Jun 2018 17:31:24 -0400
From: Dave Lawrence <>
To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= <>
Cc: Mark Nottingham <>, Patrick McManus <>, DoH WG <>, bert hubert <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
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: Fri, 08 Jun 2018 21:31:28 -0000

Ólafur Guðmundsson writes:
> Actually I think what DNS people are concerned about is:
>  Query over DNS ==> DoH ==> Auth server generates big answer ==> Doh
>  Reply => Answer over DNS fails due to size limit.

I'm a DNS person and I don't have a concern about this.  The software
that gets an answer over HTTPS that is too big for the implementer to
want to handle, whether for technical or philosophical reasons, is
free to just not handle it.

Any software that is taking a DoH answer from an HTTPS channel is
brand new software, not some legacy problem that we have to worry
about.  If it imposes size limits before passing it on to whatever
legacy code it wants to pass it on to, so be it.  The new software
shouldn't be just blindly passing whatever data it gets into some
legacy parser anyway, especially if the draft comes with an
admonishment to be wary of that very thing.

The DoH recipient will of course be fundamentally incapable of turning
a > 64k DNS/HTTPS answer into a > 64k answer on DNS/UDP or DNS/TCP, so
nothing on the other end of DNS/UDP and DNS/TCP will be dealing with
any new problem.

In the end, what onerous "fails due to size limit" problem is there?
We've already had a demonstration on the list today of a DNS server,
with no HTTPS involved at all, having a zone with a > 64k RRset that
it can't send over faithfully DNS/UDP or DNS/TCP.  Clearly some legacy
software is already cognizant of things that should be representable
in DNS wire format but just can't be because of a legacy transport
limit.  All it means is that the client that wants the data can't get
it in a pre-DoH world, but the world keeps revolving nonetheless.