Hi Christian, On 9/21/17 9:28 AM, Christian Huitema wrote: > > Eliot, it seems that what you are looking for is "configuration" rather > than "discovery". Tomato/tomato. > Of course, DHCP servers can provide hosts with the > address of a DNS server. This is a form of discovery. Right. Same with RAs. > 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. For clarity, I take you to mean that whether or not the client wishes to use what it receives from the network is a matter for it to decide. Absolutely true. > 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. "Really like" understates the case. It is what happens today, and it is necessary for the reasons I mentioned previously, specifically but not limited to, split dns and malware detection and prevention. I'm not saying that what you're saying above is in any way invalid, but the other use case is pretty darn serious. > > 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 matter has thus far been ducked, and it is time to stop ducking it. > 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. From an enterprise administrator perspective that's harmful for reasons discussed above. > 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. > Proponents should take responsibility for the problems that the new mechanisms they are standardizing will create. That was the intent of Security Considerations. Saying it's someone else's problem creates an externality in the form of a massive DOS attack on others. On the other hand, you raise an interesting question: why shouldn't the DoH draft go into DPRIVE such that the discovery problem for both mechanisms could be addressed there? The group is already chartered. Eliot
Attachment:
signature.asc
Description: OpenPGP digital signature