Re: [Doh] Clarification for a newbie DoH implementor

Ben Schwartz <> Sun, 09 June 2019 17:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80F281200D7 for <>; Sun, 9 Jun 2019 10:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.509
X-Spam-Status: No, score=-17.509 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_HELO_NONE=0.001, 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 NhS6hDVtlWyt for <>; Sun, 9 Jun 2019 10:04:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9D081200B7 for <>; Sun, 9 Jun 2019 10:04:35 -0700 (PDT)
Received: by with SMTP id v69so1246325vke.0 for <>; Sun, 09 Jun 2019 10:04:35 -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=2CB92dfXye+PCdtbLoey4MOIgYWfWJ2/HEzw+1VJfI8=; b=XMWjs7oDN5btOcaJ48/z5GxdUbN3LHZaQsdM8TUsqQdMwSnfE9YKrpX2oAM6Cc08jo NdmS6w4Jz+lTkte1qFUhyF5y3+i24KFaUfFkxnJd+FOOgeADVlxKa48M81sETwV7Q8ev CtbJht3zrBoy3s3uZqdEFgOxcx02JAVWeSnZmHO5f6FwnLcieHuWc49eUbT1+iEef37h bQsCdt5u5+idY2wTCqMfpIWs/RUQ4rPmSPhz3A15TOaZV5iM8UhaxETHpVaBDzCKVyVK WzA+6Kc6WwPTDIUFVY0rdZw848J2z16o2+AMFo4jQl7YhH+66utT/PH4gkcyzZMrz97L oYTQ==
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=2CB92dfXye+PCdtbLoey4MOIgYWfWJ2/HEzw+1VJfI8=; b=kBcYCHoIO/SiI96L0v3VUlhBIyzh4Plt+QxXGB5kYLUXeFTAqaS5saPIPrm9GBpMQh 5e7HYEprjKBeBR+HXQizyo5J++bIbC/5ROcyJG8nIQ7BTas+lTCn3EM+IVUASbJ59uPz OlcamO/OwgSL7Zhg8rJuxz3Gjab/FvlzlRdoBIpRtgtNVdYK6pVra/vzVixkLAoCq2zS VC7dHLl2zHtNDsaTohqajr23LiSxl5wZ1BHmKmJnxp5g1ciTuzTrQoyrsQW70bVKtm9M ec8GXUPZUjARQkLZ+tKAOjofvoVf21wg3DD+/LxQUG2chhE2T1MMHmpXW0jjbnXWgxJH xPtg==
X-Gm-Message-State: APjAAAXI741sZSkpNTiIvIEfN+ISHCqYgQWknIsgxgyGnX7veCsbhwMX BEsLSDoBeifYFLvyezmqqkhxwtgEBX7Qp/UzWPlsM0nD0G8=
X-Google-Smtp-Source: APXvYqyUVJTOal0Olu8tO2Wfh3PoAG6HOXLI3VleZCb4KS/bWo/aGDh8UU0mu+ZZe7pCPRhkRT06f7zbZZMS+3XnQwM=
X-Received: by 2002:a1f:ccc4:: with SMTP id c187mr23679234vkg.56.1560099874222; Sun, 09 Jun 2019 10:04:34 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Sun, 9 Jun 2019 13:04:22 -0400
Message-ID: <>
To: Mark Delany <>
Cc: DoH WG <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000d9b63e058ae70eac"
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, 09 Jun 2019 17:04:40 -0000

On Sun, Jun 9, 2019, 4:37 AM Mark Delany <> wrote:

> On 19May19, Ben Schwartz allegedly wrote:
> > In practice, none of this seems to be a problem.  DoH servers simply do
> > their best to fully answer the query
> I know this is getting close to flogging a dead horse, but I'm still
> troubled by
> the silent truncation implied by a DoH Server processing TC=1.
> Notwithstanding clients which directly connect to DoH servers (such as some
> browsers) the typical scenario is likely to be existing stub clients using
> to talk to a DoH proxy/client which in turn talks to a DoH server, i.e.:
>  stub (UDP) ->        DoH proxy (HTTPS) -> DoH server (UDP) -> resolver
>  stub (UDP) <-        DoH proxy (HTTPS) <- DoH server (UDP) <- resolver
> (Sorry, you'll need to render this in a fixed-width font).
> As I understand Ben's response, if the resolver returns TC=1 then a
> typical DoH
> server (or its resolver library) will retry with TCP which makes the flow
> for a
> large response actually look like:
>  stub (UDP) ->        DoH proxy (HTTPS) -> DoH server (UDP) -> resolver
>                                            DoH server (UDP) <- (TC=1)
> resolver
>                                            DoH server (TCP) -> resolver
>  stub (UDP) <- (TC=0) DoH proxy (HTTPS) <- DoH server (TCP) <- (TC=0)
> resolver
> Which certainly meets the "do their best to fully answer the query" as the
> stub
> never has to worry about TC=1 and simply gets the "full result".
> However... It makes me wonder how a large TCP response the DoH Server
> sends back
> via HTTPS can possibly fit into the response the DoH proxy sends back via
> UDP to
> the stub.
> Let's say the DoH proxy receives a 5K response over HTTPS, does it blindly
> try
> and transmit this 5K response over UDP back to the stub and just hope for
> the
> best? Or should it know this is likely to fail and act accordingly? If so,
> how
> should it act?
> I can't think of what a DoH proxy can sensibly do in such circumstances
> apart
> from arbitrarily truncate the response down to the UDP size indicated by
> the
> stub and *not* mark the response with TC=1.

I don't understand your logic.  From my perspective, the obvious thing for
this proxy to do is to truncate the response, and set TC=1 if truncation
occurred.  Truncating without setting TC=1 seems like a violation of the
DNS protocol.

Thus the stub loses some of the
> answer and more importantly loses knowledge of the truncation. That seems
> bad to
> me.
> As we've discussed previously, it's pointless returning TC=1 to the stub
> as it
> will simply re-issue an identical query as far as the DoH server is
> concerned.
> Note that I said "identical query as far as the DoH server is concerned".
> The
> same is not the case for the DoH proxy as the query re-issued from the stub
> *can* be disambiguated since the stub connects to the proxy via TCP.

Indeed.  It seems obvious to me that the proxy will not truncate the
response to a query that arrived over TCP, since truncation is not required
for DNS-over-TCP, and therefore the full query will succeed from the stub's
perspective.  To summarize, a proxy that does the simplest thing to comply
with DNS and DoH RFCs will correctly deliver full responses to the stub
without requiring any changes to either protocol.

Which offers a possible solution.
> Since a proxy knows whether the inbound query has come via UDP or TCP it
> can
> annotate the HTTPS request accordingly (let's invent a "Use-TCP"
> header). The DoH server acts on this header thus the flow becomes:
>  stub (UDP) ->        DoH proxy (HTTPS)           -> DoH server (UDP) ->
> resolver
>  stub (UDP) <- (TC=1) DoH proxy (HTTPS)           <- DoH server (UDP) <-
> (TC=1) resolver
>  stub (TCP) ->        DoH proxy (HTTPS - Use-TCP) -> DoH server (TCP) ->
> resolver
>  stub (TCP) <- (TC=0) DoH proxy (HTTPS)           <- DoH server (TCP) <-
> (TC=0) resolver
> IOWs TC=1 is sent all the way back to the stub for it to deal with. If the
> stub
> re-queries with TCP, the proxy forwards the query with the "Use-TCP"
> annotation
> to the DoH server which in turn instructs its resolver library to use TCP.
> Not only does this alleviate a DoH server from trying their best to "fully
> answer the query" in the blind, it also avoids the impossibility of
> transmitting
> a large response back to the stub over UDP. Most importantly truncation is
> no
> longer silently performed - rather it is communicated back to the stub
> which
> lets it decide what to do as has traditionally been the case.
> I think all stubs should work in this "Use-TCP" scenario whereas clearly
> they
> cannot in the "DoH server transparently handles TC=1" scenario.
> The one down-side is that a TC=1 response incurs higher latency due to the
> flow
> going all the way back to the stub for a retry, however given these TC=1
> responses are uncommon, that seems like a minor price to pay for a
> consistent
> outcome.
> Mark.
> _______________________________________________
> Doh mailing list