I can't really find a simple explanation of what this means. The warnings in the EDNS compliance tester aren't really helpful either. Is there a simple explanation somewhere?
To most people, it's not the "domains" that should be checked, but DNS servers and DNS resolvers, both the authoritative and recursive type. If you are using a major DNS provider for your domain, no action is needed, but just to be sure, use the test tool on the webpage to see if your provider has broken EDNS, and do check your local recursive server.
Classic DNS messages carried by UDP were restricted to 512 bytes, EDNS boosted this restriction and also introduced some flags, and it has been enabled by major DNS servers since 1999. But in practice, many deployments on the authoritative servers are broken, they signal EDNS support, but EDNS replies are silently dropped, due to broken DNS servers, misconfigured router, broken NAT, broken ISP installations, or broken firewalls or other middleboxes.
Previously, various DNS resolvers contained a workaround that disables EDNS as reaction if a DNS query timeout is detected. Now the workaround will be removed. If a DNS resolvers has EDNS but it's broken, it will be marked as a dead server.
"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.
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.
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.
Yes, this page provides virtually no detail either before or after getting a SLOW or SOME PROBLEMS result. I spent a lot of time in the weeds of EDNS a couple years back and I tested that company's domain, and have frankly no idea what the results mean, what the change is, etc. Seems like a source article trying to encourage change could have been a little helpful beyond "upgrade yo' shit" without explaining what it means.
If you're running a DNS server and have problems, it's probably not a simple matter of blowing out the latest version of your software. You probably have a rat's nest of thousands of entries added over a decade or more, different firewall policies in front of different authoritative servers, caches, etc.
bcaa7f3a8bbc|7 years ago
To most people, it's not the "domains" that should be checked, but DNS servers and DNS resolvers, both the authoritative and recursive type. If you are using a major DNS provider for your domain, no action is needed, but just to be sure, use the test tool on the webpage to see if your provider has broken EDNS, and do check your local recursive server.
Classic DNS messages carried by UDP were restricted to 512 bytes, EDNS boosted this restriction and also introduced some flags, and it has been enabled by major DNS servers since 1999. But in practice, many deployments on the authoritative servers are broken, they signal EDNS support, but EDNS replies are silently dropped, due to broken DNS servers, misconfigured router, broken NAT, broken ISP installations, or broken firewalls or other middleboxes.
Previously, various DNS resolvers contained a workaround that disables EDNS as reaction if a DNS query timeout is detected. Now the workaround will be removed. If a DNS resolvers has EDNS but it's broken, it will be marked as a dead server.
unknown|7 years ago
[deleted]
LeonM|7 years ago
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.
JdeBP|7 years ago
And about time, too.
* http://jdebp.eu./FGA/dns-edns0-and-firewalls.html
zAy0LfpBZLC8mAC|7 years ago
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.
jaachan|7 years ago
Twirrim|7 years ago
rconti|7 years ago
If you're running a DNS server and have problems, it's probably not a simple matter of blowing out the latest version of your software. You probably have a rat's nest of thousands of entries added over a decade or more, different firewall policies in front of different authoritative servers, caches, etc.
nottorp|7 years ago
Thanks HN commenters for doing the site's job :)