Re: [Doh] Clarification for a newbie DoH implementor

Ben Schwartz <> Sun, 19 May 2019 02:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8981C1200F1 for <>; Sat, 18 May 2019 19:27:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.51
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v9hn2S83uch6 for <>; Sat, 18 May 2019 19:27:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8EC3C1200E9 for <>; Sat, 18 May 2019 19:27:40 -0700 (PDT)
Received: by with SMTP id u4so4143754uau.10 for <>; Sat, 18 May 2019 19:27:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Sat, 18 May 2019 22:27:26 -0400
Message-ID: <>
To: Mark Delany <>
Cc: DoH WG <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000015d9e80589345c72"
Archived-At: <>
Subject: Re: [Doh] Clarification for a newbie DoH implementor
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 19 May 2019 02:27:43 -0000

*From: *Mark Delany <>
*Date: *Sat, May 18, 2019 at 7:38 PM
*Cc: * <>

On 18Apr19, Mark Delany allegedly wrote:
> > I'm working on a proxy/server DoH implementation designed to install on
> > 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.

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

> 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