Hi Phillip, Nice summary, Please see inline
From: dns-privacy <[email protected]> On Behalf Of Phillip Hallam-Baker Sent: Tuesday, November 26, 2019 11:05 PM To: [email protected] Subject: [dns-privacy] Trying to understand DNS resolver 'discovery' CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe. ________________________________ This notion of DNS resolver discovery seems very strange to me. There are three ways in which a DNS resolver can be realistically determined by a client whether that is in the platform (Windows/OSX/Linux/etc) or the application. 1) Promiscuous DNS The client obtains the information to connect to a resolver either as part of DHCP configuration or by further interrogation of the local network. [TR] DHCP and NDP can be spoofed, and I don’t think secure neighbor discovery is deployed. https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-05 proposes a mechanism to securely bootstrap endpoints to discover and authenticate DoT/DoH servers provided by a local network. 2) Admin/User Configured DNS The client obtains the information to connect to a resolver through an Administrator or User configuration action. This may be inserting an IP address (8.8.8.8/1.1.1.1/etc<http://8.8.8.8/1.1.1.1/etc>) or some form of DNS label. 3) Application/Platform Provider Configuration. The application or OS platform can simply ignore user preferences and choose a DNS provider of its own liking. This is not an exhaustive enumeration of the possibilities of course. But please, assure me that we are not the brink of users being faced with pop ups asking them 'would you like to choose me as your DNS provider'. Of these three models, I have always considered (1) to be a security hole. It made some sense in the days when the smallest machine connected to the Internet was the size of a washing machine and portable computers didn't exist. But not today. [TR] IoT devices may also want to use DoT/DoH servers for both privacy and security. [As a pragmatic matter, it will continue to be necessary for devices to use the local network DNS resolver for the purpose of connecting to WiFi in kiosk type environments. ] We might well see the third model being imposed by government decree in some places. Along with the DNSSEC root key to be used for validation. Yes, there are situations where split DNS has to be considered so that the device knows that when it is on the employer network it behaves differently. But I see those as being a subset of VPN config. If Alice works for example.com<http://example.com>, then she can install a signed config file stating which DNS resolvers and IPSEC (or other VPN) parameters to use on which networks for which sets of DNS addresses. [TR] Yup, it is not a problem for IT managed or MDM devices but a challenge for BYOD devices. Cheers, -Tiru So what I see is a requirement for DNS resolver configuration. We already have rfc6763 to tell us how to get from a DNS label to an Internet service.. Albeit one that presupposes the existence of a resolution mechanism. I don't see it being problematic to use the local DNS to do this resolution provided that 1) we have the means to authenticate the connection and 2) we only use this mechanism once, to perform initial configuration. DNS resolution service providers do need to change their IP configs from time to time of course. But there is an expectation that the resolver IP is stable over very long periods of time. Moving to DNS names for resolvers does not free us from this expectation in this case. In my view, choice of a DNS resolver should be an event backed by ceremony so while I think we can and should insist on DNSSEC authentication for the resolver[1], there is certainly a potential role for a WebPKI certificate to establish accountability (i.e. EV). There is also a potential role for use of rfc3709 (logotypes) to provide a strong security signal during a one-time configuration operation. [1] Even if the local resolver does not support DNSSEC or insists on the use of an untrusted root, the DPRIV service being connected to can provide this information as part of the initial handshake.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
