On 9/21/2017 12:02 AM, Eliot Lear wrote: > > The IETF has provenance over the DNS standards, and that ought not be > so quickly relinquished. That includes discovery, which we have > covered in the past through mechanisms such as DHCP and RA. We > needn't be the only ones to speak on the subject nor need there be > only a single method defined within IETF, but not speaking about it at > all runs the risk of creating a massive mess for enterprise > deployments, because if the wrong resolver is discovered, any number > of functions commonly used in enterprises will break, not the least of > which would be malware detection. Perhaps enterprises could put up > with that if they knew how to regain the capability, and that ties > back to discovery (and scoping). Eliot, it seems that what you are looking for is "configuration" rather than "discovery". Of course, DHCP servers can provide hosts with the address of a DNS server. This is a form of discovery. On the other hand, deciding whether to entrust name to address resolution to the DHCP-discovered name server is a configuration issue, not a discovery issue. You mention that in enterprise networks would really like the hosts to use the DNS server managed by the enterprise; I understand that, but it is a configuration decision. The same hosts, when roaming outside the enterprise, may not really want to trust the resolution service provided by some random Wi-Fi network. The issue of configuration is not limited to DoH. The exact same issue arises with DNS over DTLS or DNS over DTLS, or even with the rather common practice of chosing a DNS service independent of the network, such as Google DNS. The only difference is that firewalls can easily block these other transports, while blocking DNS over HTTPS is harder, but even that is debatable. In Prague, DKG demonstrated that you can in fact run DNS over TLS on port 443, and defeat most existing firewalls. I would argue that the tension between user chosen configuration versus network chosen configuration is not specific to DoH, and that it should be addressed in either DNSOP or DPRIV. -- Christian Huitema
Attachment:
signature.asc
Description: OpenPGP digital signature