4 ms·
In my opinion we don't want TLS at all, but rather a UDP based protocol, so that the latency advantages of DNS aren't lost. I believe DNSCurve solves this.
by gnode 8y ago
In my opinion we don't want TLS at all, but rather a UDP based protocol, so that the latency advantages of DNS aren't lost. I believe DNSCurve solves this.
- sanxiyn 8y agoIf you want UDP, DNS over DTLS also exists.
- gnode 8y agoDoesn't really save you anything; DTLS still involves a connection with a handshake, so you have increased latency and memory overhead. Its usefulness is in low latency transport where head-of-line blocking would be detrimental (e.g. real-time streaming video; phone calls; VPNs). DNSCurve, by comparison, is connection-less -- meaning no handshake latency, no connection overhead, and denial-of-service resilience.
- patrickmcmanus 8y agoDoH on QUIC is probably the end result
- bluejekyll 8y agoDNSCurve requires an out-of-band process for the exchange of key information. This is how it works around the handshake requirement. It's been a while since I read the spec though, so not sure what the current process is.
- fanf2 8y agoDNS-over-TLS with a persistent connection to the resolver can be more efficient than UDP-based protocols since you can put multiple queries or answers into one packet. DNS supports pipelined queries and out-of-order responses over TCP and TLS so there isn’t a head-of-line blocking problem.