| HN Mirror

Quite the opposite, actually. A DNSCrypt client can be implemented in a couple lines of Python: https://github.com/tresni/dnspython-dnscrypt/blob/master/dns...

It probably took about 15 minutes to write these. Writing a fully functional client in Go, which is the core of dnscrypt-proxy 2, took about the same time: https://github.com/jedisct1/dnscrypt-proxy/commit/b076e01f7a...

Correctly implementing DNS-over-TLS is way more complicated.

It has to use TCP. So in order to avoid it being vulnerable to the most trivial slowloris attack, you need to implement a connection pool, reuse old connections, timers to enforce timeouts.

If you want half-decent performance, you need to make sure that multiple, out-of-order queries and responses can be sent over the same connection. This requires tracking query identifiers, making sure that there are no ID collisions in inflight queries, and if you are just building a proxy, you can’t expect any upstream server to support this.

TLS session tickets allow DNS operators to track devices no matter what their IP are. TCP sessions allow DNS operators to fingerprint devices sharing the same external IP. From a privacy perspective, this is effectively a regression over plain DNS. So for people who care about this, you need to add the ability to disable these. Performance will be terrible, but that’s what you get for using a transport protocol that was never designed for DNS. This can be partially mitigated with DoH using forthcoming HTTP/2 extensions. But for raw TLS that doesn’t allow much except send() and receive() packets, there’s no hope without reinventing HTTP.

Encrypted DNS requires padding. The way to do padding in DNS-over-TLS is to add extra records to DNS packets. So you need to parse and modify DNS packets. Which is slow and painful to write, if only because of name compression. Instead of that lousy hack, DNS-over-HTTP/2 can simply use existing HTTP/2 mechanisms: HTTP/2 frames already support padding. DNSCrypt doesn’t require packets to be parsed or modified either; padding bytes are simply appended to raw DNS packets before encryption, and are trivial to remove after decryption.

As we recently saw, DNS-over-TLS is virtually useless against attacks such as BGP hijacks, unless certificates are pinned. So, you need to implement pinning. Figuring out how to do it using the OpenSSL API is going to keep you busy for quite some time. DNSCrypt only requires one function call to verify a signature. DNS-over-HTTP/2 can leverage what browsers and modern HTTP library already do.

So, implementing DNS-over-TLS is hard. It’s not just about sticking stunnel in front of a stub resolver. Even just the TLS part is hard to implement securely. Validating TLS certificates in non-browser software remains the most dangerous code in the world: https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-...

But it’s also pointless. Other protocols are easier to implement and more efficient.

And from a server perspective, proposing DNS-over-TLS means that there is yet another thing to do certificate management for. Key management is hard. It’s the root cause of virtually all DNSSEC outages, and why people gave up with DNSSEC or didn’t even try. Software supposed to automate this exist, but the reality remains the same.

In contrast, key management has been solved in the HTTP world. Through built-in support in web servers, ACME clients, CDNs and proxies. People already run web sites. Let them leverage what they already have and that works well instead of forcing them to go back to square one and figure out how to do key management for DNS. Ditto for authentication and logging. Which is why DNS-over-HTTP/2 makes way more sense than DNS-over-TLS DNS-over-TLS also requires a dedicated port. Which is even not reachable from many restricted network environments such as the WiFi network I am currently on. This kinda defeats the whole point of the protocol. DNS-over-HTTP/2 uses the one port that is less likely to be blocked, and is fully compatible with proxies including transparent ones from mobile carriers. DNSCrypt also uses port 443 by default, can use TCP only if required, but it doesn’t even need a dedicated port either; DNSCrypt and regular DNS can share the same port, as done by Cisco servers.

So, DNS-over-TLS is hard to implement. Hard to deploy. Difficult to connect to. Slow. Won’t get any better without reinventing HTTP. Feels like it was invented 20 years ago, but it doesn’t really make sense any more today.