Quo vadis DNS: DoT, DoH, DoQ?
By Monika Ermert - eLance journalist - The first meeting of the IETF Adaptive DNS Discovery (ADD) Working Group (WG) was inconclusive. While there is broad agreement that both DNS providers, clients and/or users need resolver choice, the WG looks set to be overtaken by yet another encrypted DNS resolution contender in DNS-over-Quic, or DoQ.
Participants heard three options for the discovery of DNS recursive servers, none of which received endorsement as a path forward.
DoT and DoH discovery locally please!
The proposal presented by Dan Wing for a group of authors including Orange, Citrix, Open Exchange and McAfee, offers the selection of DoH and DoT servers for fixed and mobile networks, preferably in the local network via new DHCP (and DHCP6) reference identifier (DoT) and dedicated DHCP/RA options or lists (DoH). The proposal underlines the advantages of keeping the resolver local for performance reasons, hinting at 5G traffic.
Compared to the other options this suite of drafts offers transparency for the user with regard to the privacy properties, says Alexander Mayrhofer, DNS expert at nic.at. “We are working on this for privacy in the first place, so communicating these properties, seems like a nice idea”, Mayrhofer says, “even if we do not know if something like ‘informed decision’ can be accomplished”.
A list of resolvers at IANA?
A lot of criticism was reserved for the proposal of Daniel Migault, engineer at Ericsson, on a ‘DNS Resolver Discovery Protocol (DRDP)’. The draft envisages discovery of recursives via a list managed by IANA or another dedicated forum. As it is expected that the number of global DoH and DoT capable public resolvers will stay low, Migault recommends that they should be retrievable from a special domain, rdns.arpa.
After the meeting Migault addressed the criticism and agreed that instead of having a central place for querying public resolvers, it would be better to have more decentralised “repositories” where possible.
Using HTTP to rebuild the DNS tree?
Some well-known faces from the HTTPS domain, Tommy Pauly from Apple and Patrick McManus from Fastly, have placed a different, but similar, proposal on the table in the DPRIV WG, which suggests that discovery should be based on HTTP requests. Resolvers would be found recursing from a well-known DNS authoritative/resolver (for bootstrapping). This would be combined with another DNS privacy draft: ‘oblivious DNS’, where authoritative/resolvers could act as proxies.
The important feature of ‘adaptive DNS’ according to McManus, was “less [e]mphasis on third party recursive resolvers – it would therefore do a better job of sharing name information with only those involved in the HTTPS transaction”. According to McManus the data flow, was “similar to that of a stub implementing their own recursive”, albeit with better security properties. The adaptive DNS proposal has a number of fans, even from some DNS experts. But most agree that much more DNSSEC deployment to prevent bootstrapping from a rogue resolver is necessary, even if McManus thinks HTTPS can also do the job.
In comes DoQ
QUIC, the new transport protocol expected to be finalized in 2020, could end up constituting a sizeable portion of future internet traffic, some think. Because it is UDP-based, but promises to add efficiency by ending head of line blocking while adding encryption by default, it could be a nice fit for the DNS. At least that is what the authors, privacy gurus Christian Huitema, former IAB member, Sara Dickinson, from Sinodun and Allison Mankin from Salesforce think.
DoQ will depend on QUIC being implemented more broadly, while HTTP3 implementation is not expected to be a prerequisite. For the time being the authors restrict DoQ to the path from stub to recursive. Also the risk of middleboxes blocking QUIC connections cannot be addressed, the authors write.
Making up your mind
Once there is a lot of support in browsers for QUIC and HTTP3 and TCP-based HTTP turns into “legacy”, DoQ could become much more attractive compared to DoH for application-level requests, says Mayrhofer .
For existing DNS software, adapting to DoT remains the easier option, even if it remains troubled by filtering and blocking through firewalls due to its special port number, Mayrhofer says. Therefore, for all infrastructure deployment (including the future recursive to authoritative server-path) it remains an attractive option. “Why should you add an HTTP stack here?”, Mayrhofer describes the attitude of parts of the DNS world. Peter Koch from DENIC is, for instance, one of those who questions the value of a re-creation of the DNS tree in HTTPS. But load-scaling and security benefits will continue to be the answer of browser vendors and mobile operating system providers.
Neither Mayrhofer nor Huitema believe the discussions between the DNS and Web communities will abate any time soon.
In a final brave attempt to structure the ADD WG work, outgoing IAB Chair Ted Hardie banded together with IAB colleagues Jari Arkko and Martin Thomson to present a proposal on privacy transparency for different resolver discovery procedures. The idea behind this draft is to make the decision processes and trade-offs faced by the IETF community visible to external parties, such as end-consumers and users.
One of their key observations is that, were discovery of multiple DNS resolvers to be allowed, this would open the pathway for future reductions in the concentration of information about client activity – adhering to the principle of both data minimization and the old security adage of not putting all your eggs in the same basket. However, no choices have been made and with discussions running across several WGs this will continue to be a balancing act.
So, stay tuned.