Re: [Doh] Clarification for a newbie DoH implementor

"Mark Delany" <d5e@xray.emu.st> Sat, 18 May 2019 23:38 UTC

Return-Path: <d5e@xray.emu.st>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432B3120072 for <doh@ietfa.amsl.com>; Sat, 18 May 2019 16:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.88
X-Spam-Level:
X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emu.st
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxTwzwqq7Uhi for <doh@ietfa.amsl.com>; Sat, 18 May 2019 16:38:23 -0700 (PDT)
Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id B9D3512004F for <doh@ietf.org>; Sat, 18 May 2019 16:38:22 -0700 (PDT)
Received: by f3.bushwire.net (Postfix, from userid 1001) id BDD573AFF7; Sun, 19 May 2019 09:38:15 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1558222695; bh=FKOyS3NqjDeGvYZC7jRlxWd8w3o=; h=Comments:Received:Date:Message-ID:From:Cc:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=OjKk+nHNSzJmkfn+hqxtlneCCuFw4eDfOur4QyrEZ4vp/Du0+/XAO+wiYCXGmkNBH uwKSAKZFu6LyILm/qdP4X7rTAA6XD97zZaETj7+tzPTajyXs3p1nWKNP1gWFJARJJL z1cJkhbxLKFjH+q1bLxoXIOFeQ4TBpP9Y77TvbLs=TvbLs=
Comments: QMDA 0.3a
Received: (qmail 44250 invoked by uid 1001); 18 May 2019 23:38:15 -0000
Date: 18 May 2019 23:38:15 +0000
Message-ID: <20190518233815.44249.qmail@f3-external.bushwire.net>
From: "Mark Delany" <d5e@xray.emu.st>
Cc: doh@ietf.org
References: <20190418071238.68406.qmail@f3-external.bushwire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20190418071238.68406.qmail@f3-external.bushwire.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/NLtMqK6nNzACzwxS-IGPoudO2pA>
Subject: Re: [Doh] Clarification for a newbie DoH implementor
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 May 2019 23:38:25 -0000

On 18Apr19, Mark Delany allegedly wrote:
> I'm working on a proxy/server DoH implementation designed to install on CPE

> The questions:

I have another.

## Truncated response

In the scenario where a DoH server is implemented as a HTTPS server
that relays the query onto a cache, say by using nginx/ATS as HTTPS
front-ends, RFC848 is silent on the matter of a truncated response
coming back from the cache and passing thru the DoH server.

Presumably the DoH server should simply pass the response back to the
DoH client with the TC bit intact.

However relegating TC handling to the DoH client can't work as the DoH
client has no way to re-issue the query with an "ask the DoH server to
use TCP" signal.

I also worry that a dumb stub/DoH client combo could easily get in a
loop as it sees the TC bit and re-issues the query gets another TC bit
and re-issues the query - rinse and repeat.

One solution is to have the DoH server detect TC and directly re-issue
the query via TCP on behalf of the DoH client but that seems to go
against the implicit design whereby a DoH server is mostly just a dumb
relay rather than an intelligent intermediary. It's also unlikely to
be a viable solution when using most of the off-the-shelf HTTPS
front-ends.

Another solution might be to have one of the DoH components
arbitrarily zero the TC bit to protect agsinst dumb stubs but that
doesn't seem right or resilient in terms of applications consuming the
results.

It seems to me that a TC response from a DoH server can never be
handled correctly which probably excludes otherwise legitimate
implementations which want to use off-the-shelf HTTPS front-ends.

Alternatively, if TC is never allowed as a return from a DoH server it
needs to be explicitly stated in the RFC or if it is allowed, provide
a mechanism for the client to signal the need for a TCP re-query.


For the curious, this whole question came about because I observed a
TC response and a subsequent TCP re-query from a "stub" in my
lab. Specifically from a macOS platform - which admittedly has an
interesting relationship with client-side DNS. Nonetheless, the
problem seems real enough to warrant trying to find a solution.


Mark.