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

Paul Vixie <> Sun, 19 August 2018 01:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 920A3130DD1 for <>; Sat, 18 Aug 2018 18:21:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AxWc_4Q5Y7eC for <>; Sat, 18 Aug 2018 18:21:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5742A130DCF for <>; Sat, 18 Aug 2018 18:21:28 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:1c6f:2fd8:8c7b:9a62] (unknown [IPv6:2001:559:8000:c9:1c6f:2fd8:8c7b:9a62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 106B9892C7; Sun, 19 Aug 2018 01:21:28 +0000 (UTC)
Message-ID: <>
Date: Sat, 18 Aug 2018 18:21:18 -0700
From: Paul Vixie <>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Ted Lemon <>
CC: Marek Vavruša <>, dnsop <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
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 01:21:29 -0000

Ted Lemon wrote:
> The thing is that most devices don't connect to just one network.   So
> while your devices on your network can certainly trust port 853 on your
> network, when they roam to other networks, they have no reason to trust
> it.

that's far afield of my stated use-case.

if i receive advice and pre-shared key, concerning tcp/853, from my dhcp 
server, the tcp/853 service i'm advised to use may not be on my own 
network, it could be part of my corporate VPN, or an anycasted 
commercial service, or almost anywhere else.

in that case, my DHCP transaction was local, and my resulting TCP/853 
transactions won't be local. and in that case i will have a greater 
reason to trust the pre-shared key and the TCP/853 advice because of 
where i received it, than i would have reason to trust privacy or 
integrity of the path to a UDP/53 + TCP/53 ("traditional DNS") server.

roaming is another matter, because in those cases, i'll speak DHCP to 
some new network provider, and will receive some advice concerning an 
RDNS service from that new DHCP transaction, which will obviate any 
previous advice, or whether i took that advice, or how trustworthy that 
advice turned out to be.

> ... If you have devices that never roam to other networks, that's
> fine, but we have to design for the more general case.   There's no way
> with DHCP for the device to tell that it's connected to a particular
> network, other than matching IP addresses, which isn't a great idea.

if i'm not roaming, i won't receive RDNS advice from the other DHCP 
servers that i never come into contact with. this seems a non-sequitur.

if i am roaming, then anyone who hands me an address via DHCP should 
feel free to advise me as to what DNS service i use, including a TCP/853 
service for which a pre-shared key may be needed. because the network 
operator may forbid and prevent the use of other DNS services which i 
may prefer, it would be wise for me to listen to that advice, and 
consider following it, especially if my usual service can't be reached 
while operating on said network.

roaming is off-topic. DHCP authentication and integrity is off-topic. 
this is a simple proposal to allow a network operator to include TCP/853 
("DoT") advice including pre-shared keys in their DHCP responses. it 
ought to be drama-free.

P Vixie