Re: [Doh] WG Review: DNS Over HTTPS (doh)

Ask Bjørn Hansen <ask@develooper.com> Thu, 21 September 2017 08:40 UTC

Return-Path: <ask@develooper.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 AF8F9134463 for <doh@ietfa.amsl.com>; Thu, 21 Sep 2017 01:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Qu0MirUZUigb for <doh@ietfa.amsl.com>; Thu, 21 Sep 2017 01:40:17 -0700 (PDT)
Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98553132620 for <doh@ietf.org>; Thu, 21 Sep 2017 01:40:17 -0700 (PDT)
Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mbox1.develooper.com (Postfix) with ESMTPS id BE1851758C1 for <doh@ietf.org>; Thu, 21 Sep 2017 01:35:11 -0700 (PDT)
Received: (qmail 28373 invoked from network); 21 Sep 2017 08:35:10 -0000
Received: from c-67-188-112-34.hsd1.ca.comcast.net (HELO ?10.0.200.101?) (ask@mail.dev@67.188.112.34) by smtp.develooper.com with ESMTPA; 21 Sep 2017 08:35:10 -0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\))
From: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= <ask@develooper.com>
In-Reply-To: <fd8aafdf-9fdd-f988-4390-84fc27ee5066@cisco.com>
Date: Thu, 21 Sep 2017 01:35:09 -0700
Cc: IETF <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E8E06836-7CAA-4A58-AED2-7D81FB46FD08@develooper.com>
References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <fd8aafdf-9fdd-f988-4390-84fc27ee5066@cisco.com>
To: doh@ietf.org
X-Mailer: Apple Mail (2.3445.1.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/R6bsNnKw0XcOSpAxxEJLO4LU6cQ>
Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 21 Sep 2017 08:40:19 -0000

I find it curious that much of the debate has been about a particular “DNS consumer” use case; I think dns-over-http can do more (and as was pointed out, application APIs seem a bit out of scope).

If you think of the DNS “flow” as

     consumer — client — resolver server — auth

(just to make my example above clearer; in case I am mixing up the proper terms used here, another example):

    application — OS stub resolver — [network] — bind/powerdns resolver/… — bind/nsd/powerdns auth/…

While I’d like access to lower level DNS information in browser javascript as much as everyone else, limiting “doh” as just a facility to bypass the OS resolver (and maybe the resolver server) seems a bit limited. I think the target should be something that could (eventually) be used in the rest of the “flow”, too.


From the dnsoverhttp group last November:

> On Nov 22, 2016, at 20:47, Shane Kerr <shane@time-travellers.org> wrote:
> 
> One thing that really stuck with me at the dnsoverhttp bar-BoF was when someone said that DNS is adopting features that look like HTTP (DNS sessions handling, DNS RR server-side push, etc.), and that HTTP is adopting features that look like DNS (sending certificate chains, providing address information, etc.).

The someone was me.

My thought is that if we’re changing the DNS protocol (or adding another…) there might be a big practical advantage in building on the huge implementation investments being made in QUIC.

The “value” in DNS is the delegation and data model, not the current “bits on the wire” protocol. For future features (privacy, encryption between resolvers and auth, etc) maybe a different protocol would be appropriate.

(Still quoting Shane)
> I wonder if our models are starting to break down? Having two protocols
> with seemingly very little in common adopting the same features kind of
> implies that our abstractions are broken, right?

It is (eventually) working out for IPv6! :-)


Ask