Re: [Doh] Clarification for a newbie DoH implementor
Ben Schwartz <bemasc@google.com> Sun, 09 June 2019 17:04 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 80F281200D7 for <doh@ietfa.amsl.com>; Sun, 9 Jun 2019 10:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.509
X-Spam-Level:
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: 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 NhS6hDVtlWyt for <doh@ietfa.amsl.com>; Sun, 9 Jun 2019 10:04:36 -0700 (PDT)
Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 A9D081200B7 for <doh@ietf.org>; Sun, 9 Jun 2019 10:04:35 -0700 (PDT)
Received: by mail-vk1-xa36.google.com with SMTP id v69so1246325vke.0 for <doh@ietf.org>; Sun, 09 Jun 2019 10:04:35 -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=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; d=1e100.net; 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: <20190418071238.68406.qmail@f3-external.bushwire.net> <20190518233815.44249.qmail@f3-external.bushwire.net> <CAHbrMsCMWtzHXZvpodak59RtAkSQC_ZM03oekKj00WqzNkDaaA@mail.gmail.com> <20190519055255.45717.qmail@f3-external.bushwire.net> <CAHbrMsC-1OQnoaYFE5BO8UzDsebo7jhJBfc9F4J-zgeA2FZm7Q@mail.gmail.com> <20190609083724.23965.qmail@f3-external.bushwire.net>
In-Reply-To: <20190609083724.23965.qmail@f3-external.bushwire.net>
From: Ben Schwartz <bemasc@google.com>
Date: Sun, 09 Jun 2019 13:04:22 -0400
Message-ID: <CAHbrMsD5ioLvC9RXp6sGtjg-K-wfU3hk69dMFcDVy8WQoWYvCg@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="000000000000d9b63e058ae70eac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/6egz90b-kuQf3YvuOMnuLg6Wq08>
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, 09 Jun 2019 17:04:40 -0000
On Sun, Jun 9, 2019, 4:37 AM Mark Delany <d5e@xray.emu.st> 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 > UDP > 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 > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh >
- [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