The RFC 8484 documents what is already available to HTTP applications in an ad-hoc fashion: the ability to send DNS queries over HTTPS to servers that are willing to act as DNS resolvers. The main expected use cases for DoH is sending DNS queries to sites with whom the user already has an authenticated connection, or sending DNS queries to resolvers that the user or the user’s operating system trusts. The two-party nature of HTTPS challenges some traditional network based DNS management strategies.
For example, many organizations are accustomed to providing all DNS resolution services for their users. Some organizations even use firewalls that intercept DNS queries to resolvers selected by the end client and redirect those queries to the organization’s own DNS resolvers or third parties they have selected. Because DoH traffic is encrypted, those firewalls cannot detect it unless the firewalls are also doing TLS interception. Thus, some of the users’ DNS traffic will go to resolvers not controlled by the organization.
Of course, since DoH’s traffic to resolvers is encrypted, malicious parties who are watching the network cannot see that traffic. This is an obvious privacy gain; however, HTTPS’s benefit is restricted to the transport of the DNS data. DoH continues to require that browsers and web applications send their DNS queries to a server the user or operating system knows and trusts because the server is able to infer important information about the user such as their interests, their likely location, and so on.
So far, the overriding issues around DoH can be characterized as related to “centralization.” For example, if a small number of service providers control a large portion of global DNS resolution, it becomes easier to track users and their browsing habits. On the other hand, centralized service providers are likely to provide better DNS service and, so far, the large public DNS resolvers have been much quicker to adopt technologies like DNSSEC validation and query minimization.
The major browsers do not yet have DoH turned on by default. There is a general expectation that when a browser starts turning on DoH, it will give the user a choice of trusted DoH providers and enable end users to specify their own trusted configurations, similar to the list of search providers seen in browsers today. It is not at all clear how a browser vendor will populate that list, or what the defaults will be.
Many DNS providers have indicated that they are or will be open DoH servers. However, there is not yet agreement on how those organizations can publish their privacy policies or how the community can verify that the operators are following those policies.
Even though DoH is just making an open standard of a practice that has been available to browsers for well over a decade, there have been concerns raised about its development. The issues around operations and privacy issues are yet to be fully considered against the better confidentiality and response integrity DOH offers. It is likely that further interactions between the operations community and browser vendors and, of course, the reactions of and choices by Internet users, will determine the final path of DoH’s future.