Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

Joe Abley <> Tue, 10 July 2018 15:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32D1C131024 for <>; Tue, 10 Jul 2018 08:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CsYKb7SrTyEZ for <>; Tue, 10 Jul 2018 08:30:22 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 671AA131029 for <>; Tue, 10 Jul 2018 08:30:22 -0700 (PDT)
Received: by with SMTP id s13-v6so12937343wmc.1 for <>; Tue, 10 Jul 2018 08:30:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s5CFesfgJ2jLxkVR4YFgJKgPtCEkMh/3dbdo3NUhL7M=; b=dj2qc5Q6MTrnCEann9BXMzgT25sJ9W50NIWcDX3BDmUctr6ran8rQ8gzmEGAimKr86 on8PBdICex5dniywQhT0UsUdM7RtzH3ttCM0QVcnkQBKJX9vKTphGu1HpvIHMuiVqZ1N /dUeWsginS+mJFnhAMFYJ40PBeUk/U3G2Xjus=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s5CFesfgJ2jLxkVR4YFgJKgPtCEkMh/3dbdo3NUhL7M=; b=sbLYsvGYDLJT8YIdEMvGVc2vUM+iXgreMDa4K7FO8Nqr5nwF7T61FfzNgKqUw9HzHc mY4Xn+HswRTvpKNH8Mcyx3Fj1prdnwaVnFn2XGEX3rDkmO46G8X21yzQm676uT2pt4ES xDiysuQP8xLqumfpa2ONQE+O5UN+640Ws/l/3J3l1fErb/JfCQ2WK+k04YPXnjx0MgGk oyKj0a6vQh/dleKfBUN+5D0W7v9tyUCwbj/cwMpNVtXJsEjDHOg1e8z38BLKhh8izgMq 28stqUV4RkRw5ht10BMTOwzOgQGtEbCLj17kKvZPj6taVXcC4irbuta2UhGkcRf/rMxO A/9w==
X-Gm-Message-State: APt69E3MEB1dHxk3E2UMUKaxbcH1Qx73cFD8y1yNpuO5+srtVrwNPNCH KW+UqExsI8uyD2l4268jbxbDLA==
X-Google-Smtp-Source: AAOMgpdW45wVyAGV2TmCg6NS6o/7zU55P9wT7TtA3bVwyzl9bmgzwGXGAJfqKYN+8lU1zpdE+iGcfA==
X-Received: by 2002:a1c:30d2:: with SMTP id w201-v6mr14180928wmw.47.1531236620778; Tue, 10 Jul 2018 08:30:20 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id c10-v6sm17366203wrs.6.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 08:30:19 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Joe Abley <>
X-Mailer: iPad Mail (15F79)
In-Reply-To: <>
Date: Tue, 10 Jul 2018 16:30:18 +0100
Cc: Paul Wouters <>, Philip Homburg <>, Patrick McManus <>,, DoH WG <>,, HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Adam Roach <>
Archived-At: <>
X-Mailman-Approved-At: Tue, 10 Jul 2018 09:02:39 -0700
Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "DNS Resolver Identification and Use \(DRIU\)." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Jul 2018 15:30:26 -0000

On Jul 10, 2018, at 16:09, Adam Roach <> wrote:

> [as an individual]
>> On 7/10/18 9:59 AM, Paul Wouters wrote:
>> It seems more like an extension of the Public Suffix. Which domains can
>> make claims about other domains. 
> Based on the conversation that took place in DoH in Singapore, I think it's mostly *not* about this. The questions that have come up so far include: (a) If the record that is pushed to me is DNSSEC signed, is that sufficient to trust it? (b) If the record that is pushed to me is not DNS signed, but I'm using it in a context that requires TLS (e.g., HTTPS), and the thing that I connect to when I use the record can present a cert that proves its identity, is that okay?

I think perhaps the people who have been having these conversations are not being ambitious enough.

The pressures in the enterprise DNS market are overwhelmingly driven by the need to make web apps more reliable, load faster, and offer user-specific content. There are other reasons to want DNS tricks, but the customers that pay the big money are all concerned with HTTPS UX. Some of the decision points are in the DNS and some are in HTTP. The DNS is overwhelmingly involved at UX session initiation, but after that the HTTP layer has (can have) a far richer set of data about the user and is able to separate user-blocking decision-making from the flow of the UX which also affords extra time to make decisions without the user becoming frustrated.

[To illustrate the architectural lunacy of the status quo, consider the data sets that are gathered through real-user-monitoring in browsers, served at the HTTP layer, that are subsequently used to steer DNS traffic used to retrieve resources back at the HTTP layer. There's a whole layer of derived datasets relating to the DNS there that are being generated by the web and used by the web, but with a tangy sandwich filler of DNS that is just overhead.]

It seems like it would be nice then, after the UX-blocking elements are loaded and the user is already engaged, for subsequent lookups to be driven in HTTP and client-side scripting and to be presented to the stack as bare addresses rather than DNS names. That avoids the dependency on the DNS after initial page load altogether and leaves all the performance engineering decisions in the same place as the content decisions.

There are problems with this approach today (certificate matching, for example) but I don't think the problems necessarily relate to the DNS. Perhaps they relate to a local-context naming system that doesn't exist outside a javascript sandbox. I see the attraction of shifting name resolution to DOH since it makes it look like everything is a web app, but collapsing the address selection back to the extent that you can avoid name resolution at all seems like a better end goal.

So rather than resolverless operation, think about resolutionless or nameless, eliminating the DNS as unnecessary overhead.

Perhaps I have misunderstood the whole problem space, of course :-)