Re: [Doh] Clarification for a newbie DoH implementor

Ben Schwartz <bemasc@google.com> Sun, 19 May 2019 02:27 UTC

Return-Path: <bemasc@google.com>
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 8981C1200F1 for <doh@ietfa.amsl.com>; Sat, 18 May 2019 19:27:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Level:
X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 v9hn2S83uch6 for <doh@ietfa.amsl.com>; Sat, 18 May 2019 19:27:40 -0700 (PDT)
Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC3C1200E9 for <doh@ietf.org>; Sat, 18 May 2019 19:27:40 -0700 (PDT)
Received: by mail-ua1-x92d.google.com with SMTP id u4so4143754uau.10 for <doh@ietf.org>; Sat, 18 May 2019 19:27:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fFUEiOUEHJ+SI4w0L8h6UdRki28Dx2VD710mkmErcpQ=; b=uM/jWuj53hcAZnsmdU1z1TxSsdvoyDNOI6p4i9k++Jsih1mkiuk9BCQhaAzBeT4TS+ c2IxAMNjILZnp7Dqej/WnrzGGtAFDVta8t8tOmTyFUFhVNMmvN+6X/Y1J2MZGeAv1TOE ViHbF49BQBWXmD16GLrD63Wc+/EBxOrU7rSOohdnpD6TLMvfyu0ca2udsD2wOG5D2dN/ TYRySZro7auEkKvJUv7OpuvmdZSPNzQ8ZiwUZS/YyFANXZVO92Tg5OOglp1Gl1cpR1HZ hkSIK4sov+edSuWtyx6wQgGBghp9bsuPeqVtxmYCEPDDjOM1Qf/fABsJdysVNW0zxFoZ M+aA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fFUEiOUEHJ+SI4w0L8h6UdRki28Dx2VD710mkmErcpQ=; b=F7jFsyzsM8rMGLTtM2if02HzVc5UWLo2MofEMmXj24sWI6ozK58xNuubcSO2TjntXF cHkRjtPlO97zGJp52rPaJ24jod08sPGv7zFEC3WT1AU0N2eJAGF9UMNTAsApzg8ipX8b ngQ8dsvj6SrDe665otmPOfc0vbTDql2Yyz/l6iktAIlq4wzfk3xfCpONDlk8eLOpL9x9 RfNoxOACZOA5dbuoLln+YdsO2tmG6yR9iQN/UzZywRG4D8DL2FGUcrKIHu8xOZSNhs+h XID8Pif/mZxtEu5W03iAp7cQUnPk6Qw7JnSqhf7FGiSWXBO+p/rWov00hXKemNGQdGRm Dg4g==
X-Gm-Message-State: APjAAAW+V+zAotJx1zalun9hw7WrFUdgpTtjxXBwgbKjtcgPbGVDyqb4 2uptFQYjq5A2mOWiJWO5kRq4+jXvMbzoMcBgftoqf4oOfvQyTw==
X-Google-Smtp-Source: APXvYqxNhlhW2FY6wq08k+V6L8BmBZB+H6NrUvO0npzolk7EAYPxCCovg0VhTekY29z9qO4vD00lqR/GCS7YwhWyZQs=
X-Received: by 2002:ab0:7298:: with SMTP id w24mr8210896uao.119.1558232859235; Sat, 18 May 2019 19:27:39 -0700 (PDT)
MIME-Version: 1.0
References: <20190418071238.68406.qmail@f3-external.bushwire.net> <20190518233815.44249.qmail@f3-external.bushwire.net>
In-Reply-To: <20190518233815.44249.qmail@f3-external.bushwire.net>
From: Ben Schwartz <bemasc@google.com>
Date: Sat, 18 May 2019 22:27:26 -0400
Message-ID: <CAHbrMsCMWtzHXZvpodak59RtAkSQC_ZM03oekKj00WqzNkDaaA@mail.gmail.com>
To: Mark Delany <d5e@xray.emu.st>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000015d9e80589345c72"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/OnHse4h6fUpChrchYEzFR9X0n0M>
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: Sun, 19 May 2019 02:27:43 -0000

*From: *Mark Delany <d5e@xray.emu.st>
*Date: *Sat, May 18, 2019 at 7:38 PM
*Cc: * <doh@ietf.org>

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.
>

Correct.

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.


I don't think the implication you describe is intended.  This sort of
reissuance is the expected implementation in the architecture you're
describing.


> It's also unlikely to
> be a viable solution when using most of the off-the-shelf HTTPS
> front-ends.
>

In practice all the various DoH implementations do not seem to have
encountered a problem with this.  That might be because the easiest DoH
implementation is simply a wrapper around a traditional stub or recursive
resolver core, which already has to handle query reissuance.

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.
>

DoH servers are permitted to return TC responses.  Clients can do whatever
they like with their truncated response, which may or may not be of any use
to them.  Certainly a DoH server that returns TC frequently is not likely
to be very useful.  As RFC 8484 notes, when truncation cannot be avoided,

   a DoH server could use an HTTP error instead of a non-error
   response that has the TC bit set.


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 mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>