There are many stakeholders — and equally many ‘new’ protocols with complementary, or even conflicting, goals — in the popular fields of DNS privacy and security.
Some want to assure that upstream resolvers do not offer bogus results, or to prevent them from lying about domain ownership. Others add assurance to the identity of ‘preferred’ or ‘authoritative’ resolvers. Yet more attempt to offer clients some limited anonymity, tracking-resistance, or identity protection, or to prevent their requests from being blocked by intermediaries.
But what if a client could achieve all of that and more for themselves today? And the only cost would be in having merely adequate rather than blazingly fast DNS latency?
Well, they can. I know this because I have been using it for more than 18 months and have published my metrics and experiences, all of which have been ‘adequate to good’.
How it works
The Tor Project is a non-profit enterprise that offers volunteer-run machines that provide best-in-class strong privacy, anonymity, blocking-resistance and tracking-resistance for TCP circuits — most especially HTTPS — servicing the needs of millions of users per day.
Circuits that are routed semi-randomly over Tor generally experience moderate additional initial setup latency, some additional transport latency, and some degree of bandwidth choking. That said, Tor works remarkably effectively — so much so that Facebook, the BBC, the New York Times and several other enterprises offer service over it, including streamed video and audio.
Therefore it’s a simple step to ask “what if we build a DNS stub resolver that exclusively performs DNS resolution via DNS-over-HTTPS (DoH) but does so using the Tor network to provide circuit-level anonymity and blocking-resistance?”.
We can further configure the stub resolver to use HTTPS load-balancing across a large pool of DoH servers to dynamically offset the worst cases of Tor-related latency. This also, incidentally, reduces the scope for centralized logging and ’behavioural fingerprinting’ as well as reducing both capability and incentive for DoH providers to treat requests ’coming from Tor’ in some special manner. Using Tor also negates the upstream surveillance and tracking opportunities afforded by EDNS Client Subnet (ECS) extensions.
Standard HTTPS assures our choice of DoH resolver, and mandating that our pool of resolvers must all use DNSSEC will assure upstream trust. Careful and standardized tuning of the stub resolver removes the opportunity for ’SSL fingerprinting’ of cipher suites, session tickets, and request formats.
Publishing this as a port-53 service to the local network means that the solution is available to all services on the local network. This also provides an isolation layer that prevents cookie leakage and other fingerprinting risks that are considered to be inherent in DoH when directly embedded in browsers.
And if you were not aware of all these means of tracking and identifying DNS traffic before now, well… you are now.
Does it work?
DoHoT is simple to set up and works surprisingly well, given traditional (often, prejudicial?) expectations, using existing and stable open-source software. In a seven-month sample period, measurements at the stub resolver gave a median latency of 262ms across 2.4 million requests including the local cache, and 464ms across 1.6 million requests without caching.
These figures will sound high to people who deliver DNS as a product or service, however they are not far removed from the normal experience of many day-to-day DNS users, especially ones who, similarly interested in privacy, install stub-resolver privacy filters such as PiHole. Spot-testing amongst an unscientific peer group, performing 5 sets of 100 serial reverse lookups of randomly-generated IPv4 addresses (Figure 3) puts the DoHoT solution in the 70th percentile of deployments for performance:
User experience for the past 18 months has shown nearly zero negative consequences of deploying DoHoT, and in short, ’it works fine’. The single largest issue was the unknowing purchase of an IoT device that was hardcoded to use 8.8.8.8 for DNS resolution, and which had to be whitelisted because all other port 53 traffic had been blocked at the firewall, as an optional and additional privacy measure.
Impact
DoHoT works, though it is not a perfect solution for DNS security, privacy, integrity, and trust — however it may point the way towards one. Current research is firmly, but perhaps narrowly, directed towards the development of novel and inherently limited anonymity/privacy solutions to be delivered by existing DNS service providers, for whom latency remains the metric of greatest concern.
However, the DNS is a notoriously distributed protocol, and the client is able, perhaps even best advised, to be an active participant in achieving their own levels of trust. In such circumstances, some sacrifice of latency may be an appropriate price to pay.
The DoHoT project homepage contains links to presentation videos, slide decks, source code, and the white paper for the project, which go into much greater depth than can be afforded by this brief blog post.
Alec is a full-time dad who has worked in host and network security for more than 30 years, with 25 of those in industry, holding senior consulting, architecture, network and software engineering roles at Sun Microsystems, Facebook, and Deliveroo.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.