Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Paul Ebersman <> Tue, 21 August 2018 02:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC7A4130EB0 for <>; Mon, 20 Aug 2018 19:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TDqzB8snKq4a for <>; Mon, 20 Aug 2018 19:44:22 -0700 (PDT)
Received: from ( [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A888130EBD for <>; Mon, 20 Aug 2018 19:44:22 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 6FFF13740205; Mon, 20 Aug 2018 19:44:22 -0700 (PDT)
Received: by (Postfix, from userid 501) id 4A980AD6C3E; Mon, 20 Aug 2018 20:44:22 -0600 (MDT)
Received: from fafnir.local (localhost []) by (Postfix) with ESMTP id 46AF8AD6C3D; Mon, 20 Aug 2018 20:44:22 -0600 (MDT)
From: Paul Ebersman <>
To: Tom Pusateri <>
cc: dnsop <>
In-reply-to: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Comments: In-reply-to Tom Pusateri <> message dated "Mon, 20 Aug 2018 22:38:44 -0400."
X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <55900.1534819462.1@fafnir.local>
Date: Mon, 20 Aug 2018 20:44:22 -0600
Message-Id: <>
Archived-At: <>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Aug 2018 02:44:37 -0000

pusateri> Come to think of it, DNSSEC validation in the stub resolver or
pusateri> browser is really a place DoH could shine. Instead of all the
pusateri> round trips required for validating up (down) the chain, the
pusateri> webserver could package up all those validated records and
pusateri> push them so the client/stub could do the validation quickly
pusateri> for all of the links in a page in an order that the user is
pusateri> most likely to need based on previous statistics and scrolling
pusateri> position.


My discomfort with some current proposals where I get DNS answers to
questions I didn't ask yet would be a lot less if I had full validation
info to DNSSEC validate them. Even getting SRV and other service entry
points would be less if they're in the domain I'm already playing in and
the DNSSEC validate.

Trick with this will be getting browser support. We're still debating
why SRV is too many lookups vs CNAME at zone apex. Fingers crossed we
make progress on both.

For other apps, stubby seems like a fine way to get this in the app.