2/ In 1999, an extension was added to DNS. Since them, a bunch of DNS clients have behaved badly with the extensions, so DNS servers have implemented workarounds to stop things from breaking.
-
Show this thread
-
3/ But this prevents the state of DNS from improving, holding back evolution. So the most popular DNS servers have agreed that as Feb. 1, they are going to stop providing these workarounds, so some ancient (we are talking 19 years here) clients will break.
1 reply 2 retweets 11 likesShow this thread -
4/ Most users won't notice. But some automated systems, may some industrial systems, will confusingly fail because they can no longer resolve some names when these servers are updated to the latest version.
1 reply 2 retweets 10 likesShow this thread -
5/ The orgs pushing this have some tools to check some things, but the easiest way is to put a packet sniffer on the wire and test which clients are generating requests that don't include EDNS0 flags in them. Those clients may have issues, if not now, eventually.
5 replies 4 retweets 17 likesShow this thread -
Replying to @ErrataRob
No, clients without EDNS0 support are fine. Issue is improper negotiation!
1 reply 0 retweets 0 likes -
Replying to @WatsonLadd
Hmmm. I just assumed that the main symptom was backing off to packets without EDNS0 and just giving up on timeouts. The second problem I assume would already be fixed, but the other would be visible.
2 replies 0 retweets 0 likes
Modern resolvers always set EDNS0. Sometimes auth servers don't reply, because they don't understand EDNS0, and the resolvers retry without EDNS0. What's changing is that they will no longer retry without EDNS0, they just mark the auth server as dead/failed.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.