3 ms·
> The transport protocol picked for the DNS, the User Datagram Protocol (UDP), was the best option at the time, but is fraught with issues, including being a ma
by zrm 8y ago
> The transport protocol picked for the DNS, the User Datagram Protocol (UDP), was the best option at the time, but is fraught with issues, including being a major ingredient for DNS-based DDoS events. Only recently has attention turned to finding a more suitable transport arrangement.
UDP is perfect for DNS. The problem is the original protocol design itself. For example, DNSCurve uses UDP and doesn't have these problems.
The only reason people are turning to TLS now is that errant middleboxes have been interfering with all attempts to improve the security of DNS, and using TLS is seen as a way to get the traffic through.
If DNS had been DNSCurve from the beginning then middleboxes breaking it would be seen as a flaw in the middlebox instead of the new protocol, and protocol ossification would be less of a problem because encrypting the data inhibits interference.
But TLS seems obviously worse than defaulting to DNSCurve or similar and falling back to TLS when breakage is detected.
- bluejekyll 8y agoPersonally, I'm excited for DNS-over-QUIC, which should be a best of both worlds.
- zrm 8y agoDNS-over-QUIC is a plausible alternative to DNSCurve, but you're still looking at a fallback to TCP TLS when you encounter a middlebox which is interfering with all the UDP traffic it doesn't outright block.
- jedisct1 8y agoUDP indeed fit DNS like a glove, except on links with excessive latency / packet loss. This is more of an implementation issue than a problem with UDP, though. I'm not very familiar with DNSCurve but I don't think it has any mechanisms to prevent amplification. DNSCrypt solved this by requiring a question to be at least as large as its response.
- zrm 8y ago> I'm not very familiar with DNSCurve but I don't think it has any mechanisms to prevent amplification. The DNSCurve page discusses amplification: https://dnscurve.org/amplification.html https://dnscurve.org/amplification.html The main point is that amplification is primarily a problem because of DNSSEC records causing small requests to generate very large responses, so if people would use DNSCurve instead then even if the responses were somewhat larger than the requests they wouldn't be so by a factor of 120:1 or more, which is the real issue. But yes, there are multiple ways to solve the problem. CurveCP (a derivative of DNSCurve) does the same thing, requiring the initial packet to be as large as the response. For that matter DNSCrypt is somewhat a derivative of DNSCurve/CurveCP as well. The point is that it's quite possible to solve the problem and still use UDP.