Re: [Doh] Clarification for a newbie DoH implementor

"Mark Delany" <d5e@xray.emu.st> Tue, 21 May 2019 04:48 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 6291A120123 for <doh@ietfa.amsl.com>; Mon, 20 May 2019 21:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 2gmS0DreSRXE for <doh@ietfa.amsl.com>; Mon, 20 May 2019 21:48:53 -0700 (PDT)
Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id B31F712009C for <doh@ietf.org>; Mon, 20 May 2019 21:48:53 -0700 (PDT)
Received: by f3.bushwire.net (Postfix, from userid 1001) id 50B8D3B05A; Tue, 21 May 2019 14:48:50 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1558414130; bh=0H3racZnYPJn8LpwyWt8C55nQXI=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=LRpP3hO1GH+MZeAk8ZwIHz8KdXq/7KWCgGEf4vX7YnvayyuwIGfrDgZoZ1OPQ+EW3 TfKds1PJN/WvGEFsdjgT4iY9EEFb5urwMDQoUgjaYDd7OXssLedZhl8M23y0Ia8Vwe jiEwzqUcW9fVTnyX1+CxF3q01t1WKy6aRAbpGkbQ=pGkbQ=
Comments: QMDA 0.3a
Received: (qmail 11544 invoked by uid 1001); 21 May 2019 04:48:50 -0000
Date: 21 May 2019 04:48:50 +0000
Message-ID: <20190521044850.11543.qmail@f3-external.bushwire.net>
From: "Mark Delany" <d5e@xray.emu.st>
To: "DoH WG" <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAHbrMsC-1OQnoaYFE5BO8UzDsebo7jhJBfc9F4J-zgeA2FZm7Q@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/gqHmJgzkQk62S0NnOyhquQlHV1k>
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: Tue, 21 May 2019 04:48:55 -0000

On 19May19, Ben Schwartz allegedly wrote:

> This is transparent and generally does not cause problems.

> In practice, none of this seems to be a problem.

I'm interested to know how you came to those conclusions. When you say
"generally" and "seems" that sounds more anecdotal than empirical.

(Was there ever a bake-off for DoH? Three independent implementations and all
that jazz?)

Having said that I accept the reality that as long as at least one IP address
gets returned in a response, then everything else that the DNS community has
layered on top of a DNS query/response is mostly icing on the cake.

IOWs the lowest common denominator is all that most clients rely on so all my
hand-wringing around TC and ECS and roles is so much esotericism. Sad for me but
hardly important.

As just one example of how indifferent clients are; as you observe, many DoH
servers re-query TC responses locally thus insulating clients. Contrast this
with dnsmasq which appears to arbitrarily clear TC and return the truncated
response to client as if it were whole.

That the Internet functions with these two completely opposing outcomes is
impressive. I'm not sure how that guides a DoH implementor to a robust solution
but it does seem to perpetuate the notion that any solution is legit as long as
it generally "seems" to work.


> DoH is a transport for DNS.

That misapprehension on my part is what initiated this thread in the first
place.

I initially saw DoH as a port 53 tunnel, but it is anything but that if you
include client and server behavior.

At the very least the DoH server is content-aware and responds to TC=1 and
server timeouts and who knows what else based on what local resolver it is
using. In addition the DoH client is specified to be aware of TTLs and HTTP
"Age" headers and modify the response accordingly.

We also saw earlier in this thread some discussion around DoH components
participating in ECS settings.

To my mind that makes DoH more akin to an RPC interface created by slicing thru
a stub resolver.


Enough ranting. You provided useful feedback that I can act on, so thanks for
that.


Mark.