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

Dave Lawrence <> Mon, 11 June 2018 05:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE9CA130DF5 for <>; Sun, 10 Jun 2018 22:04:22 -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 z7V5WptPm8KT for <>; Sun, 10 Jun 2018 22:04:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D632E130DED for <>; Sun, 10 Jun 2018 22:04:21 -0700 (PDT)
Received: by (Postfix, from userid 102) id 31EB32AFDE; Mon, 11 Jun 2018 01:04:21 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Mon, 11 Jun 2018 01:04:21 -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: Mon, 11 Jun 2018 05:04:23 -0000

Andrew Sullivan writes:
> It's the part where the middle node _doesn't know_ it's a gateway for
> a "traditional client" that I've been worried about, because someone
> takes their existing code, plops an HTTPS transit on it, and thinks
> they're golden.  I know Tale thinks I'm worrying about something that
> Shouldn't Happen, but I think experience tells us this kind of thing
> happens _all the time_ in poorly-constructed DNS implementations. 

To be clear, I am not saying people don't write bugs.  People screw up
our modern specs all the time.

My point is that I don't see any practical way with unlimited-DoH that
legacy DNS software ends up having to deal with wire format over 64k
without someone taking an new, affirmative step to code that.  If they
take that step and are passing it into a function that's ill-equipped
to handle it, despite the standard that they're coding against warning
them of that very thing, that's a programmer error, not a
specification fault.

You just said it yourself.  Poorly-constructed.  Just how much
accommodation do we have to make for as-yet-unwritten bad software?