Skip to main content
  • IETF Community Survey 2025

    Each year the IETF Community Survey provides a comprehensive assessment of community demographics, engagement patterns, and perceptions of organizational effectiveness. The full report from the 2025 edition is now available.

    14 Jul 2026
  • Birds of a Feather at IETF 126

    The IETF 126 Vienna meeting takes place 18–24 July 2026. As at every IETF meeting, alongside the established Working Groups there will be a handful of Birds-of-a-Feather (BoF) sessions—and these are often the most interesting place to watch where Internet standards work is heading next.

    2 Jul 2026
  • From Lab to RFC: A PhD Student's Journey through the IETF

    Martine Sophie Lenders has been regularly participating in the IETF for over a decade, starting with the IETF 93 meeting in Prague in 2015. She has authored several Internet-Drafts—two of which recently were published as RFCs—and at the same time works on a PhD at FU Berlin and as a research associate at TU Dresden. We asked a few questions about what her experience in the IETF has been like while pursuing an academic journey.

    1 Jul 2026
  • Suggested IETF 126 Sessions for Getting Familiar with New Topics

    These IETF 126 meeting sessions are likely to include discussions and proposals that are accessible to a broad range of Internet technologists whether they are new to the IETF or long-time participants.

    29 Jun 2026
  • IETF LLC Board Retreat 2026

    The IETF Administration LLC Board of Directors held its annual retreat 29-30 April 2026 in Amsterdam. In addition to all Board members, the IETF Executive Director, the Director of Finance, and the Board Secretary were present. Here is a short summary of the main points we discussed.

    4 Jun 2026

Filter by topic and date

Filter by topic and date

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

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