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

Dave Lawrence <> Fri, 08 June 2018 23:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07394130DE0 for <>; Fri, 8 Jun 2018 16:47:00 -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 6nWKIt_Ry0CJ for <>; Fri, 8 Jun 2018 16:46:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5E59130DC0 for <>; Fri, 8 Jun 2018 16:46:58 -0700 (PDT)
Received: by (Postfix, from userid 102) id E673C23F06; Fri, 8 Jun 2018 19:46:56 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
Date: Fri, 8 Jun 2018 19:46:56 -0400
From: Dave Lawrence <>
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 23:47:01 -0000

Andrew Sullivan writes:
> On Fri, Jun 08, 2018 at 05:31:24PM -0400, Dave Lawrence wrote:
> > I'm a DNS person
> …

You're questioning that assertion?

> > 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.
> I am surprised to see those two claims in the same email.  It is
> certainly true that the part of the software that is talking to the
> HTTPS channel is new.  I am way less convinced that the rest of it
> will be, particularly when the draft explicitly says, "The integration
> with HTTP provides a transport suitable for both existing DNS
> clients…." 

It does provide a transport suitable for existing DNS clients.
DNS/HTTPS carries messages that are usable with existing clients.  The
possibility of a DNS/HTTPS message being bigger than a DNS/UDP or
DNS/TCP client wants to deal with doesn't invalidate that.  It means
that when interfacing from one transport to the other, you have to be
mindful of the difference between them.  You *already* have to be
mindful of the difference between TCP and UDP.  DNS servers can
*already* store data that is too big for the largest possible DNS/TCP
message.  When writing new code *of course* you have to be mindful of
the differences between the transports.

> Yeah, I'd be much less concerned about if the draft gave those
> warnings.

Completely agree.  So if Patrick and Paul add the warning, you're on

> I am by no means opposed to this WG saying, "We're the new
> transport, and we're Doing It Right, and broken stuff can all be
> broken."  But we need to carry that bag in through the front door.

I'm on board with this.  Especially since it hasn't been demonstrated
that this would break stuff that any competent programmer writing new
code should be able to avoid.  If someone is writing DoH code and
concerned that they might be pumping a message longer than 64k
directly into a API that you are even a little unsure of its ability
to handle messages of that size, then don't do that.  This is not
hard.  Especially since if the limits are put in they have to do the
check anyway.