The Domain Name System has been around for over 30 years now, since the days of the ARPANET, the precursor to the Internet. DNS is remarkable: It’s scaled from serving a network of thousands of computers to a network of billions of computers and other devices. It’s decentralized, made up of millions of cooperating resolvers and DNS servers, yet it (usually) provides rapid resolution of arbitrary domain names from all over the globe.
There are dozens of makes and models of DNS servers, and as you might guess, not all of them implement all aspects of the DNS specifications equally well. Take, for instance, EDNS0, which specifies extension mechanisms to DNS, notably the use of larger DNS messages over UDP, the User Datagram Protocol.
Despite the fact that EDNS0 was written in 1999, 20 years ago, there are some DNS servers that don’t support it correctly. EDNS0’s specifications say that, if a DNS server that doesn’t support EDNS0 receives a query with EDNS0 options in it, it’s supposed to respond with a standard DNS response code called a “Format Error.” Unfortunately, some DNS servers respond instead with a “Not Implemented” or “Server Failed” response code, or simply don’t respond at all.
It’s that last case that’s particularly troublesome, because to accommodate those DNS servers, a recursive DNS server that queries an authoritative DNS server but doesn’t get a response must consider the case that the authoritative DNS server a) doesn’t support EDNS0 and b) is one of the few that simply doesn’t respond at all to queries with EDNS0 options. Until recently, almost all recursive DNS servers accommodated this small percentage of misbehaving DNS servers by retransmitting the same query without EDNS0 options to an unresponsive DNS server.
But what if the unresponsive DNS server didn’t respond because it was down, or because its IP address was wrong in DNS, or for some other reason? Well, your recursive DNS server would still retransmit a query to it, rather than quickly moving along to a different authoritative DNS server, and your resolution performance would suffer.
It seems a little silly to penalize everyone on the Internet for the sake of a few DNS server implementations out there that can’t be bothered to support a 20-year-old extension to DNS. (In the words of a famous philosopher, “The needs of the many outweigh the needs of the few.”) That’s what DNS Flag Day is all about. A group of developers of popular DNS servers said, “Enough!” and announced that as of February 1st, they start tearing out the mechanism that accommodated these old DNS servers at the expense of the rest of the Internet.
Now this won’t happen overnight. The latest versions of software from these developers will incorporate these changes, but it’ll take time before everyone upgrades to new versions of these DNS servers. For example, here at Infoblox, we track the Internet Systems Consortium’s extended release versions of BIND, and there won’t be one that includes this change for some time. Even then, it’ll take time for us to test it and integrate it into our products. But the good news is that before long—or in the foreseeable future, anyway—DNS resolution will speed up for most of the Internet.
