Last week we announced the Tenta DNS service and opensourced the underlying software. We've been humbled and awed by the response. We're reading all your comments and feedback from Twitter, Hackernews, blogs, Facebook and more. Your initial support is truly inspiring and we're looking forward to building a modern, open-source DNS alternative that protects online privacy with the community.

Next Steps: We're focused on speeding up the resolves, fixing DNSSEC issues and errors with reverse lookups, unexisting TLDs, and timeouts.
Feedback and contributions always welcome.

Why DNS-over-TLS?

"What about DNSCrypt?" tops the list of questions we've received about Tenta DNS. The questions "How does DNS-over-TLS compare to DNSCrypt" and "Will Tenta DNS add support for DNSCrypt?" also top our feedback. Although the comparisons provide a complicated topic, we've attempted to boil down to the main differences between each approach, address the pros and cons of TLS vs DNSCrypt and explain why we've very deliberately chosen not to support DNSCrypt.

Standard DNS Review

Humans like us are bad at remembering lots of numbers; quick, what's your doctor's number? But we're great at remembering names; how about your doctor's name? Computers, on the other hand, operate in a perfect clockwork universe of numbers. The Domain Name System, or DNS, provides the glue between human and machine which allows the internet to function. When you type a domain name in your browser (or follow a link to a site), your browser asks a massive global directory to convert the name of the site into an IP address. Only once it has resolved the name to a specific IP address can your browser actually connect to the server and fetch data.

The specific method employed when converting a name into a number resembles nothing so much as sending a postcard -- a petite item asking a simple question. In human translation, your computer asks "I'm requesting to see example.com. What's the IP address?". The DNS server provides a nearly identical response, simply asserting "You're requesting to see example.com. The IP address is 1.2.3.4."

As with a physical postcard, a DNS packet guarantees neither anonymity or authenticity, anyone who cares to look knows the sender, receiver, and the message. Furthermore, most computers are set up to automatically contact the DNS server provided by their ISP server.

Let's meet ISP server, or Internet Service Provider server when he's being formal. He's important to have around, since he's right next door, so he answers questions quickly. But he can be a little shit when you're not looking. He knows every website you've ever visited. Imagine inviting him to a family dinner and he tells everyone the sites you were checking out (try convincing people that Mr. Stickys is a website for glue). Also, ISP never seems to have enough money, and will happily lie to you for his own ends.

The failures with normal DNS don't stop there. Since your computer cannot distinguish between an authentic response and a fake response, any criminal or attacker may simply send a steady stream of fake answers for common websites, and eventually one of those fake answers will arrive right after a real question has been sent. Imagine going out to the mailbox to send a postcard, and then opening up the postbox to discover that you already had an answering postcard waiting. While you might think that was suspicious to have an answer already waiting, your computer only cares that an answer came in and does not question its "good luck".

Standard DNS Diagram:

Browsing data exposed when using your default DNS

• - The domain name you request (example.com)
• - How many requests you're making & amount of data transferred
• - Who's answering your request (which DNS server)
• - What answer the DNS server sent back
• - Who received the answer (You)

Formally, the normal DNS process provides:

1. Zero Privacy: Your browsing history is completely exposed. All the messages being sent back and forth are visible to anyone.

2. No Trust: You must trust that your message is delivered to the correct DNS server, that the server isn't evil, and that no one swaps out the real answer for a fake one in transit.

Naturally, the interwebz called a meeting and immediately developed a perfect solution ... who are we kidding? We got two decades arguing about the problem and coming up with multiple flawed solutions that didn't work or created worse problems. So instead, some smart people came up with DNSCrypt.

DNSCrypt Review

On it's face, DNSCrypt provides a panacea to the woes plaguing DNS. It encrypts both the question and answer, making them invisible to snoopers. It also effectively signs the message, so you know that the server you contacted really sent the answer and not an impostor. It's as if someone blocked out the messages on your postcard and the postcard you receive back includes a signature. The internet celebrated, and many cat pictures were shared. The DNS was finally complete.

Except, somehow, it wasn't.

See, DNSCrypt is far more reliable than ISP. Honest and upright. But also a little bit crazy around the edges. You just wanted to visit Speedofart. You didn't want to have to help DNSCrypt climb over your back fence to deliver the postcards in secret. Even more suspicious, the neighbors are really starting to wonder why all your postcards are redacted. And no matter how much DNSCrypt goes on and on about curves and numbers, you're not entirely sure the numbers add up.

So although DNSCrypt provides a significant security advantage, it comes with other disadvantages.

1. Not completely encrypted: Even though the domain requested (question) and IP address (answer) is hidden, the complete process is not obfuscated. The total number of questions, their relative size and more remain available. Furthermore, it remains trivial to identify that you are, in fact, performing DNS resolution.

2. Complex and not well supported: In the world of encryption, it's always safer to go with standardized protocols that have gone through a rigorous review process. Unfortunately DNSCrypt has not been standardized yet, and some of the ways it uses cryptography are unusual.

3. Hard to use: Because DNSCrypt isn't standardized, very few programs natively support it, requiring users to download and configure helper applications, significantly increasing the difficulty of use and risk of misconfiguration.

DNSCrypt Diagram:

Browsing data potentially exposed when using your DNSCrypt

• - How many requests you're making & amount of data transferred
• - Who's answering your request (which domain name's server)
• - Who received the answer (You)

DNS over TLS Review

DNS over TLS takes a completely different approach, establishing a fully encrypted tunnel between your computer and the DNS server. Rather than sending requests in the clear, with just the critical data encrypted, the whole connection is encrypted. Furthermore, since TLS is the encryption protocol used to secure almost all other internet services, the technology is well understood and constantly improved.

DNS-over-TLS is like putting all your DNS postcards in an armoured truck. Your nosy neighbors have no idea what's in the truck. Might be postcards. Might be your latest order from penisland.net. Furthermore, since the truck is big, it can hold multiple postcards, big and small, thus solving the annoying problem of getting postcards which aren't big enough to contain the complete answer.

DNS over TLS Diagram:

Conclusion

DNSCrypt pioneered a working, secure transport for DNS in the wild. But it's implementation complexity, lack of standardization and failure to improve large message support prove fatal flaws in the long run. Although new in the DNS space, TLS provides the standard of security for most other protocol, a wealth of implementations and documentation. And now that the interwebz have finally finished standardizing tea they've found the time to standardize DNS-over-TLS.

With standardization, operating system manufacturers can provide implementations in every platform, and in fact, it's already in progress on Android and we expect more to follow. And thus our most controversial point: If we don't hate DNSCrypt (and we don't), then why not support it? We don't want to expand the use of an older technology when a better standard is within reach. Since DNSCrypt never found significant adoption, let's not stick to it. Let's throw it off and move straight to a future of DNSSEC (although that's another post) and DNS-over-TLS.

Update: Some folks have asked us that if DNS over TLS encrypts your DNS requests, do you still need a VPN? The short answer is yes. DNS over TLS is one part of the solution in protecting against data leaks, but for truly private browsing you still need to establish a VPN connection to encrypt all the data and traffic you send when browsing. We'll explain why having both is important in another post.

Share this post