Skip to main content
  • Suggested IETF 119 Sessions for Getting Familiar with New Topics

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

      26 Feb 2024
    • Google and consortium of local organizations to host first Australian IETF meeting in over 20 years

      Google, auDA, and Internet Association Australia (IAA) provide key support for Brisbane meeting to be held 16-22 March 2024

        23 Feb 2024
      • JSONPath: from blog post to RFC in 17 years

        Today the JSONPath RFC (RFC 9535) proposed standard was published, precisely 17 years after Stefan Gössner wrote his influential blog post JSONPath – XPath for JSON that resulted in some 50 implementations in various languages.

        • Glyn NormingtonRFC 9535 Editor
        21 Feb 2024
      • Stepping towards a Sustainable Internet

        The IAB’s new Environmental Impacts of Internet Technology (E-Impact) program will hold its first virtual interim meeting over two slots on 15 and 16 February 2024. These interim meetings are open to participation, and we invite all interested community members to join, participate, and contribute.

        • Jari ArkkoE-Impact Program Lead
        • Suresh KrishnanE-Impact Program Lead
        7 Feb 2024
      • What’s the deal with Media Over QUIC?

        In 2022, the IETF formed a working group for Media Over QUIC (MoQ)—a media delivery solution that has the potential to transform how we send and receive media during live streaming, real-time collaboration, gaming, and more.

        • Brett BralleyThought Leadership Content Writer, Cisco
        25 Jan 2024

      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