Hacker News Reader

Comment by exabrial | Hacker News Reader

DNS over TCP/TLS is a stupid idea for a lot of reasons. First off, DNSSec already takes care of integrity protection. No need to re-implement the wheel by adding TLS on top of it… and let’s not forget we’re doing in 150 packets which one we previously did in about two packets.

DNS needs to be connectionless; it’s building block protocol for TCP. DnsCurve is much closer to what we actually need.

View on HN

I've written a bit about DNSSEC. Adoption is only around 1-5%, deployment is a footgun [1], and validation currently imposes significant performance penalties [2], although that could be improved.

I've also written about performance of DNS over TLS [3] and found it to be negligible. The TLS setup is only done infrequently.

[1] https://ianix.com/pub/dnssec-outages.html [2] https://cyounkins.medium.com/costs-and-benefits-of-local-dns... [3] https://cyounkins.medium.com/performance-of-dns-over-tls-4f4...

Negligible only if you have enough DNS queries to keep the connection alive. Last I checked Quad9 and Cloudflare will close the connection quickly, regardless of EDNS keepalive setting.

DNS over TCP is fine, and I'd far prefer it to be the default over UDP, as any packet loss with DNS over UDP results in rather lengthy timeouts (typically >1 second). DNS over TCP fixes that (or at least reduces the delay to RTT). It's DNS over TLS that's the problem. Adding HTTPS into the mix is just sheer madness.

DNSSEC isn't "connectionless"; DNSSEC responses frequently exceed the maximum UDP packet size.

TLS DNS provides confidentiality, in addition to hop-by-hop integrity; DNSSEC provides no integrity, which has led to a decade of rationalizing by its advocates about DNS not "needing" confidentiality.

DNSSEC has the same bootstrap issue. I've had a device fail to sync its time because DNSSEC validation was on and all DNS requests were failing, which prevented lookup of the NTP server address.

> DNS needs to be connectionless; it’s building block protocol for TCP.

This doesn't make any sense as you could use DNS and TCP separately (for example finding a hostname using DNS to connect your video streaming ingestion server running via UDP and hardcoded addresses to bootstrap installation files via TCP respectively).

Another reason it's nonsensical: when a DNS response is too large to fit in the payload of a UDP datagram, the server sets the TC bit in the response header (alongside whatever truncated results it feels like including), notifying the client of the truncation. The client optionally (but SHOULD) falls back to retrying the query over TCP.

https://serverfault.com/a/698254

Slowly looks at musl's direction.

(musl doesn't even try DNS/TCP after receiving a TC packet)

Yes, this is a pretty grave flaw.

DNSSEC breaks DNS by giving fake answers to solve problems no one ever had.

Reply on news.ycombinator.com