Hacker News Reader

Comment by LeonM | Hacker News Reader

"Starting February 1st, 2019 there will be no attempt to disable EDNS as reaction to a DNS query timeout. This effectivelly means that all DNS servers which do not respond at all to EDNS queries are going to be treated as dead."

So it basically means that authoritative DNS servers are now required to support the EDNS protocol. If not, it is no longer guaranteed the domain will resolve on DNS resolvers.

This is a performance improvement, because the EDNS fallback method requires a timeout.

Edit: My answer isn't correct, see the comments below.

View on HN

No. It means that content DNS servers (and their concomitant network infrastructure) must either support EDNS properly or ignore it properly. The halfway house of having clients fall back to re-trying without EDNS, because some bad servers failed to send replies (or the network infrastructure that they communicated over failed to send on those replies) in response to EDNS queries, is going away.

And about time, too.

* http://jdebp.eu./FGA/dns-edns0-and-firewalls.html

No, authoritative servers are simply required to follow standards, EDNS support is not required, none of this is about any sort of forced migration, it is only about discontinuing support for broken software after 20 years of compatibility hacks.

The EDNS fallback method does not require a timeout. A standards-compliant DNS server that does not support EDNS should ignore EDNS records in the request and simply send an old-style response that any EDNS capable resolver is still required to handle correctly. The problem is only with servers that simply don't respond to requests containing EDNS records at all, even though they are required to by the (old, pre-EDNS) standard.

Testing my DNS server gets me:

    edns=ok edns1=noerror,badversion,soa
    ednsopt=ok edns1opt=noerror,badversion,soa

Wikipedia doesn't mention anything about EDNS versions, so I'm not sure what to make of it.

likely your DNS server is using PowerDNS. Versions before 4.1.0-rc1 had a bug with the query cache:

https://github.com/PowerDNS/pdns/issues/6806

This issue isn't affected by the configuration change on flag day and judging by the slow adoption so far, by the time where edns support really gets mandatory, the current version of the distro at that time will long have updated their built-in PowerDNS version.

Those are test name, not version. The test is detailed in the test report, you just need to read all the text..

What is EDNS, and why would people want it?

basically small clarifications and enhancements of the original DNS standard with rather huge impact which allow the functioning of modern DNS features like DNSSEC (due to the need for larger messages, which need EDNS compliance, as EDNS mandates larger minimum supported message sizes), and EDNS in itself is a signaling mechanism to indicate support for these newer features (like bigger message sizes, DNSSEC, etc)

If I remember correctly, the big thing about EDNS is that DNS UDP datagrams were originally restricted in size to a total length that would be unlikely to see IP fragmentation on a network of 1980s hardware, meaning that in practice DNS packets had to be much smaller than the maximum reasonable size of an IP packet. In addition to setting up extended options, EDNS0 also allows DNS packets to be large.

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.

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.

> 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?

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)

> (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.

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.

Reply on news.ycombinator.com