Hacker News new | ask | show | jobs
by JdeBP 2713 days ago
The DNS protocol can be layered over UDP or over TCP. In its original form DNS/UDP has some quite draconian packet size limits that are reached quite quickly in the modern world. Originally, this mandated falling back to DNS/TCP. But TCP is significantly more expensive as a transport protocol, especially as the client has already had to try to perform the transaction once over DNS/UDP before falling back to it, and trickier for servers to implement than DNS/UDP.

EDNS0 ameliorated this greatly, allowing clients and servers to keep talking DNS/UDP without falling back to DNS/TCP, up to much larger packet sizes. That is primarily why one would want it, even if one did not want any of the other things that it incorporates.
1 comments
bluejekyll 2712 days ago
While packet size is one thing you can do with EDNS, it’s really a mechanism to allow the DNS protocols to add new features, as there’s no version in the DNS header.

Also, a lot of DNS hosts do not allow for large packet sizes over UDP to attempt to reduce the effect of reflection attacks.

link
Dylan16807 2712 days ago
> Also, a lot of DNS hosts do not allow for large packet sizes over UDP to attempt to reduce the effect of reflection attacks.

Do any allow a large response if you send a large (padded) request?

link
bluejekyll 2712 days ago
Hopefully someone else can answer this, but I think Google will limit the response UDP packet size to either 512 bytes or the size of the request.

So, yes, I think padding it could work. (EDNS does have a padding type)

link
Dylan16807 2712 days ago
> (EDNS does have a padding type)

"The use of the EDNS(0) padding only provides a benefit when DNS packets are not transported in cleartext. Further, it is possible that EDNS(0) padding may make DNS amplification attacks easier. Therefore, implementations MUST NOT use this option if the DNS transport is not encrypted."

Apparently it does have a padding proposal, but it wasn't thought through very well. They only had the use case of confidentiality in mind, and decided to deal with amplification by forbidding cleartext use, no matter what the response:request size ratio is.

link
bluejekyll 2712 days ago
Even in the intended use scenario, I’ve personally found it difficult to reason about how to append it to the end of a packet.

It basically needs to be the final record, which conflicts with things like SIG0 that also want to be the final record.

link