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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75D2A131028 for <>; Sun, 19 Aug 2018 06:18:40 -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 CT_BLJp5YHU2 for <>; Sun, 19 Aug 2018 06:18:38 -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 95CB81274D0 for <>; Sun, 19 Aug 2018 06:18:38 -0700 (PDT)
X-AuditID: 60729ed4-ee9ff70000006f94-26-5b796e31a496
Received: from ( []) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by (SMTP Gateway) with SMTP id B6.BB.28564.13E697B5; Sun, 19 Aug 2018 07:18:41 -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 09:18:06 -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 09:18:06 -0400
From: "Livingood, Jason" <>
To: Paul Vixie <>, Ted Lemon <>, dnsop <>, Marek Vavruša <>
Thread-Topic: [DNSOP] Draft for dynamic discovery of secure resolvers
Date: Sun, 19 Aug 2018 13:18:06 +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+NgFtrIKsWRmVeSWpSXmKPExsWSUDRnsq5hXmW0wcE+VYu7by6zWLxZc4TJ YuKkp+wW254+YnRg8fg4ewKbR9OFZeweS5b8ZPLo23qdNYAlqoHRpiSjKDWxxCU1LTWvONWO SwED2CSlpuUXpbomFuVUBqXmpCZiVwZSmZKak1mWWqSP1Rh9rOYkdDFlHL4+iaWgT6RiW/98 1gbGM8JdjJwcEgImEoeW3WbtYuTiEBLYxSTx+cJmKKeFSWLbh8dQzmlGie5Ty9hAWtgEzCTu LrzCDJIQEZjKKLH/wilmkISwgIvEgxd/wGwRAVeJ019uQNlREicX72ECsVkEVCU2TZvPCGLz AtX/XNrKArHhErNE59HnQA4HB6eApsSBF4UgNYwCYhLfT60B62UWEJe49WQ+E8TdAhJL9pxn hrBFJV4+/scK0ioqoC8x7XIARFhBYvv+bWATmYEmrt+lDzHFSuLBuXVsELaixJTuh+wQ1whK nJz5hAWiVVzi8JEdrBMYJWYhWTwLYdIsJJNmIZk0C8mkBYysqxj5LM30DA1N9AxNLfSMDI02 MYIT0rwrOxgvT/c4xCjAwajEw2tpXxktxJpYVlyZe4hRgoNZSYS31RkoxJuSWFmVWpQfX1Sa k1p8iFGag0VJnPfxxNJoIYH0xJLU7NTUgtQimCwTB6dUA2OJvdibqweaXsjJ/F8Q87ZtSZ3P 3f/Pz/zklP1/xkLNL1w48FZd1/Kcs7xT9J0rnlz71z/TyvGK+OUzbR4Tr4Uw9za+uR9r+N7+ d5Qys1TbinzRXjs2pyWKKnVrMpp7F37S2fcvftX0+pY599d2u7VvOhKSXHt4bYHz7dRdaoEm N0x2i51NZlRiKc5INNRiLipOBABPRLjLRAMAAA==
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 13:18:41 -0000

In a DOCSIS network, for whatever that's worth, the link from the home (cable modem) to the next hop (CMTS) is encrypted. It is then usually just one or two hops within the ISP's regional network to the recursive DNS (in some cases DNSSEC-validating, as in our case). So I suppose that the threat model in this example is presumably someone (1) eavesdropping on the relatively short path between CMTS and resolver or (2) modifying non-DNSSEC-validated responses - and that's does not seem like a very high risk threat IMO, given all the other potential and real threats lurking around on the Internet. 

In any case, if a user felt it was a high risk then letting their stub pick up the same resolver address (such as via DHCP) and choose to use TLS to secure the DNS query stream to the same resolvers would seem like an easy solution. But I am sure there are countries where this might carry a higher risk, in which case users have traditionally used Tor, VPNs, etc. In the latter (user-directed) case this suggests an implementation model where an end user optionally turns something on rather than a 3rd party deciding it should always be on (given the likely downsides of this operationally).

- Jason

On 8/18/18, 8:54 PM, "DNSOP on behalf of Paul Vixie" < on behalf of> wrote:

    my threat model is intruders or eavesdroppers on the path between me and 
    my rdns. i'd like the dhcp announcement to include a tcp/853 signal 
    along with a pre-shared key or the hash thereof. the benefit would be 
    that if my rdns network path is less secure than my dhcp network path, 
    i'll improve the former by not using traditional udp/53. does that help?
    DNSOP mailing list