Re: [Doh] Clarification for a newbie DoH implementor

"Mark Delany" <d5e@xray.emu.st> Sun, 09 June 2019 20:08 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 9C1E8120121 for <doh@ietfa.amsl.com>; Sun, 9 Jun 2019 13:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Nhgy7uTCAced for <doh@ietfa.amsl.com>; Sun, 9 Jun 2019 13:08:25 -0700 (PDT)
Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3110A120108 for <doh@ietf.org>; Sun, 9 Jun 2019 13:08:25 -0700 (PDT)
Received: by f3.bushwire.net (Postfix, from userid 1001) id F11563AFF8; Mon, 10 Jun 2019 06:08:20 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1560110900; bh=6iHSa1YsYANedi2II72xcH9sAso=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=NfJRLl4k1dmdx+ECo7y6kq5r1KQsZc6nHzt4FZijs9+oKez9DQXB8TZGjXmLQKVir f5QRx+CUV0HuTEdGbW5G39Cmzz2qChMaKHavEsbQ0ES6uDTv0WQxcOllHOU64/8GOE Ka+UC3MA7O1lvC/xwESU63v41lLENZ2flvD/DG18=/DG18=
Comments: QMDA 0.3a
Received: (qmail 26161 invoked by uid 1001); 9 Jun 2019 20:08:20 -0000
Date: Sun, 09 Jun 2019 20:08:20 +0000
Message-ID: <20190609200820.26160.qmail@f3-external.bushwire.net>
From: Mark Delany <d5e@xray.emu.st>
To: doh@ietf.org
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> <CAHbrMsD5ioLvC9RXp6sGtjg-K-wfU3hk69dMFcDVy8WQoWYvCg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAHbrMsD5ioLvC9RXp6sGtjg-K-wfU3hk69dMFcDVy8WQoWYvCg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/PfF7qtJZK5bCPplOa0FT83sJrCM>
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 20:08:27 -0000

> I don't understand your logic.

Bah humbug. Nor do I now that I have a bit more of a think about
it. Just shows that coming back fresh isn't all it's cracked up to
be...

For some reason I was thinking the stub would retry with UDP which of
course it won't.

It's just an observation but if a DoH server "fully answers" it means
that when a proxy does have to locally truncate a response to fit into
UDP it means that the DoH server will ultimately issue the query four
times.

Stub UDP      -> Proxy HTTPS -> DoH Server ->      UDP resolver Query 1
                                           <- TC=1 UDP
                                           ->      TCP          Query 2
     UDP TC=1 <- (proxy truncates          <-      TCP
                  to fit into UDP)

(Stub retries with TCP due to TC=1 from proxy)

Stub TCP      -> Proxy HTTPS -> DoH Server ->      UDP resolver Query 3
                                           <- TC=1 UDP
                                           ->      TCP          Query 4
     UDP TC=0 <- (proxy doesn't need to    <-      TCP
                  truncate for TCP)

No big deal I suppose since over-sized responses are meant to be a
uncommon and of course the proxy could cache locally truncated
responses for a couple of seconds if it wanted to bother.


Mark.