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

"Livingood, Jason" <> Sun, 19 August 2018 18:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C4BB130E8C for <>; Sun, 19 Aug 2018 11:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U-fmA0hXpoGz for <>; Sun, 19 Aug 2018 11:02:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B8AB0130DD8 for <>; Sun, 19 Aug 2018 11:02:13 -0700 (PDT)
X-AuditID: 60729ed4-ee9ff70000006f94-73-5b79b0a80827
Received: from ( []) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by (SMTP Gateway) with SMTP id 42.41.28564.8A0B97B5; Sun, 19 Aug 2018 12:02:16 -0600 (MDT)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sun, 19 Aug 2018 14:01:29 -0400
Received: from ([fe80::3aea:a7ff:fe36:8a94]) by ([fe80::3aea:a7ff:fe36:8a94%15]) with mapi id 15.01.1466.003; Sun, 19 Aug 2018 14:01:29 -0400
From: "Livingood, Jason" <>
To: Doug Barton <>, "" <>
Thread-Topic: [DNSOP] Draft for dynamic discovery of secure resolvers
Date: Sun, 19 Aug 2018 18:01:29 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsWSUDRnsu6KDZXRBvO/GFvcfXOZxWLCpOus Dkwel1uDPZYs+ckUwBTVwGhTklGUmljikpqWmlecaselgAFsklLT8otSXROLciqDUnNSE7Er A6lMSc3JLEst0sdqjD5WcxK6mDJOT9cvmCFUsWtlD1MD4x3BLkZODgkBE4m3zy+xdjFycQgJ 7GKSOH1xEhuE08IksXv+Q0aQKiGB04wSx1a4gthsAmYSdxdeYQaxRQQ8JF7cb2MDsYUFXCQe vPgDFXeVOP3lBpSdJXFwUwsTiM0ioCoxt/cYC4jNC1T/Yko31LIjLBJvtn8EauDg4BRwlJi3 WgOkhlFATOL7qTVgvcwC4hK3nsxngrhaQGLJnvPMELaoxMvH/1hBWkUF9CWmXQ6ACCtIvP93 ig0kzCygKbF+lz7EFCuJ7V/usELYihJTuh+yQ1wjKHFy5hMWiFZxicNHdrBOYJSYhWTxLIRJ s5BMmoVk0iwkkxYwsq5i5LM00zM0NNEzNLXQMzI02sQITjDzruxgvDzd4xCjAAejEg9v8bLK aCHWxLLiytxDjBIczEoivK0LgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5H08sjRYSSE8sSc1O TS1ILYLJMnFwSjUw7nPfN/Pyk1VGTRs4N3NJ/AjgXLffK/2r0rNP60r0LtTZB1tlSzys5Nt/ V66Ig+lohnjussS1nxcZntIR5jMWv33lRcldx2OrnZzeTng7/eUkrnlXtnDmVSyrKBHT3O2y ePuDOW5LnqhwaUxt1tdcYhQYciuzKqf7wN7PWYfTMvZ+sVr/5OzhBUosxRmJhlrMRcWJAPsJ EI8sAwAA
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: Sun, 19 Aug 2018 18:02:16 -0000

On 8/19/18, 1:02 PM, "DNSOP on behalf of Doug Barton" < on behalf of> wrote:
> Personally I see securing the path from the stub to the resolver as a 
    good step in the ultimate goal of encrypting all of the things. :) 

[JL] No disagreement here. I think the issue may be more to do with choice over the resolver (how it gets assigned). To date on the Internet that's all been down to local policy or user choice to override those policies, but now it seems like the alternative proposal may look like a centralized / top-down policy model. That's probably more the friction point than the encryption itself. 

> So the question isn't, "Why encrypt?" the question is, why on earth 
    wouldn't you want to?
[JL] Again, I agree. I think it boils down quite simply to how the resolver is assigned, and whether user choice or local policy can override that assignment, and perhaps as well what data is passed from recursive to authority (e.g. EDNS-CS).
> So it's unlikely that an ISP would deploy DOH or DOT 
    in the first place, 

[JL] I would not make that assumption; it could well be ISPs would be natural early adopters given the chance to do so.

> so the idea of a DHCP option to support it isn't 
    necessarily relevant in that environment. That doesn't mean it's not 
    relevant elsewhere.

[JL] It seems silly not to allow for a way for DHCP assignment of DOH/DOT servers. Surely it must be the case this is possible? If the network wants to assign them, then so be it IMO. The user can always ignore and override that optionally - as they do today with various public recursive resolvers.