TL;DR
We’ve built INVISV DNS, a Clientless Oblivious DNS service (update: July 2023, now deprecated – we’ll be launching a non-alpha version of this service in the future). It supports both DNS-over-HTTPS and DNS-over-TLS. It’s an alpha service running only on the free tier at fly.io (with servers in three regions/locations in the US: Los Angeles, Dallas, Washington DC) through GCP and Fastly (using our Multi-Party Relay stack). Despite that, it’s as fast as other popular DNS services for users in many areas of the US, and, more importantly, it’s more private and secure because it applies the decoupling principle.
Background
Nearly all Internet connections are preceded by DNS lookups. Devices are configured to use recursive DNS resolvers that are usually run by ISPs or cloud providers. DNS resolvers, despite not being on the network path between a user and the broader Internet, see nearly everything a user is doing: they can tie browsing behavior (DNS queries) to individual users (IP addresses and/or application-layer identifiers).
In prior research we developed Oblivious DNS (ODNS), which fixes this privacy issue that’s long existed in DNS. ODNS hides DNS queries from the first-hop resolver by encrypting those queries and sending them through the first hop to a second-hop resolver. The first hop sees the client’s IP but not the DNS query itself, while the second-hop resolver only sees the DNS query but not the client IP. The ODNS approach was later rolled out over HTTPS for Safari browsing by Apple in iCloud Private Relay.
The original Oblivious DNS protocols effectively tunnel DNS over DNS. Because of this, they require custom client stacks (meaning an ordinary phone or laptop can’t use them directly), and they use the first-hop recursive resolver in a non-standard way (so ODNS queries are uncache-able and always result in a recursive lookup).
Who is Private/Secure DNS Private/Secure From?
The last few years have seen a rise of so-called private DNS services. Some of these services argue that they are more private or secure because they promise not to keep logs. Others argue they are more private because they use DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT), both of which are increasingly standard everywhere, not just in such services.
As we talked about before regarding Multi-Party Relays (MPRs) vs. VPNs, it’s important to separate knowledge between parties (organizations/companies) so that no one party sees everything. None of the existing DNS services provide that decoupling, and that means they don’t provide the the sort of privacy and security we’d like to see.
INVISV DNS: Clientless Oblivious DNS
INVISV DNS is a new type of of Oblivious DNS where instead of tunneling DNS over DNS (requiring a custom client), we tunnel DNS over our Multi-Party Relay (which is transparent to the client stack and therefore doesn’t require any changes). DoH and DoT requests are secured using TLS certs as usual, so the first hop can’t see the contents of the request because it doesn’t terminate the TLS connection or have any certs. As in our Booth video conferencing service, the request goes through the MPR to the ultimate destination server, which in this case is an off-the-shelf knot resolver container running in fly.io’s free tier.
We call this “clientless” because it doesn’t require special client-side code. Also, since we no longer tunnel DNS over DNS, we don’t trigger adverse performance or caching behavior on any recursive resolver. There’s usually a tradeoff between performance and security/privacy in services like this, but we think it’s possible to keep that performance hit to a minimum, as we’ve done here.
Since this is an alpha service running only in three regions on free-tier infrastructure, we hope to directly partner with outside organizations that care about privacy and security who want to work with us to run this service at a global scale. That’ll improve both the performance and the privacy/security guarantees.
Appendix: Extra Details
IP SAN Certificate
To provide DoT service for clients that are configured using only the IP address, our TLS cert includes an IP Subject Alternative Name and a normal FQDN. We’ve found that some OSes/devices, such as Android, require the use of the FQDN for “private DNS” (DoT) configuration whereas others prefer the use of the server’s IP.
DoH Configuration
Using dns.invisv.com in browsers that support DoH works out of the box in standard browser secure DNS settings using this DoH URL – https://dns.invisv.com/dns-query – in general DoH is easier to configure because it’s done at the browser level (with the exception of Android, where DoT is easy to set up at the device level).