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: Sat, 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.
- [Doh] Clarification for a newbie DoH implementor Mark Delany
- Re: [Doh] Clarification for a newbie DoH implemen… Vladimír Čunát
- Re: [Doh] Clarification for a newbie DoH implemen… Mark Delany
- Re: [Doh] Clarification for a newbie DoH implemen… Mark Delany
- Re: [Doh] Clarification for a newbie DoH implemen… Ben Schwartz
- Re: [Doh] Clarification for a newbie DoH implemen… Mark Delany
- Re: [Doh] Clarification for a newbie DoH implemen… Ben Schwartz
- Re: [Doh] Clarification for a newbie DoH implemen… Ray Bellis
- Re: [Doh] Clarification for a newbie DoH implemen… Mark Delany
- Re: [Doh] Clarification for a newbie DoH implemen… Mark Delany
- Re: [Doh] Clarification for a newbie DoH implemen… Ben Schwartz
- Re: [Doh] Clarification for a newbie DoH implemen… Mark Delany
- Re: [Doh] Clarification for a newbie DoH implemen… Tony Finch