Skip to main content
  • A New Model for the RFC Editor Function

    The new RFC Editor Model is intended to provide greater transparency, improved responsiveness to the needs of the community, and increased clarity regarding the roles and responsibilities of the groups and individuals involved.

    • Peter Saint-Andre
    27 Jun 2022
  • Finalizing the IETF tools transition

    The final stage of transitioning services from tools.ietf.org will take place over the next few weeks. New services are in place, and some older services will disappear. Several measures are planned to ensure these final steps proceed smoothly.

    • Robert SparksIETF Tools Project Manager
    17 Jun 2022
  • Update from the first in-person IAB, IESG, and IETF LLC Board joint retreat

    The IAB, IESG, and IETF LLC Board convened for the first joint retreat in San Francisco from May 17 to 20, 2022, generously hosted by Google at one of their offices.

    • Mirja KühlewindIAB Chair
    15 Jun 2022
  • Towards a net zero IETF

    Introducing a new project to measure and potentially offset IETF carbon emissions so that the IETF could potentially reach the level of a net zero emitter.

    • Jay DaleyIETF Executive Director
    6 May 2022
  • IETF 113 post-meeting survey

    The results from our IETF 113 post-meeting survey are now available on a web-based interactive dashboard. This commentary highlights where changes we have made based on feedback have been a success, and areas we still need to work on.

    • Jay DaleyIETF Executive Director
    2 May 2022

Filter by topic and date

Filter by topic and date

DNS-over-HTTPS (DoH) Operational and Privacy Issues

  • Patrick McManus
  • Paul E. Hoffman

5 Dec 2018

The DoH specification in RFC 8484 defines a standardized format and protocol for sending Domain Name System (DNS) queries through HTTP rather than the traditional DNS protocol.

HTTP enabled applications, such as web browsers and the JavaScript applications running within them, may interact with DoH enabled resolvers rather than relying on traditional operating system functions when obtaining DNS information. DoH is only defined for HTTPS, meaning that the DNS traffic is always encrypted and the resolver is always authenticated. Using DoH instead of plain DNS gives users provable integrity of responses and confidentiality of their DNS traffic.

DNS-over-HTTPS (DoH) Operational and Privacy Issues Image

Considerations

The DoH specification 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.

Next steps

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.


Share this page