A DNS flag day

A flag day for DNS is coming on February 1; it may have escaped notice even though it has been planned for nearly a year. Some DNS servers will simply be marked as "dead" by much of the rest of the internet on or after that day, which means that domain owners need to ensure their DNS records will still be available after that point. A longstanding workaround for non-compliant servers will be dropped—mostly for better performance but also in support of DNS extensions, some of which can help alleviate security problems.

The Domain Name System, or DNS, is a foundational service on the internet. It is, of course, what connects domain names, like lwn.net, with their IP addresses. Without DNS records, and a server that will provide those records in response to queries, a domain is effectively "off the net". DNS provides for lookups of various types of information beyond just IP addresses, such as policy information for Sender Policy Framework (SPF) or keys for DomainKeys Identified Mail (DKIM).

The problem that has led to the flag day stems from DNS servers that do not implement the "Extension Mechanisms for DNS", also known as EDNS(0) or just EDNS; it is specified in RFC 6891. EDNS was introduced in 1999 and finalized in 2013. Some servers do not properly respond to requests that ask if they support various EDNS features. It is important to note that there is no requirement that the servers actually support any extensions, just that they reply properly (with a normal DNS response), rather than ignoring and not answering EDNS queries.

The lack of a reply to a query that uses EDNS coming from the non-compliant servers led to a workaround. When a requesting server notices that a query containing EDNS has timed out, it will send the query again without the EDNS content. That timeout ranges from five to ten seconds, depending on the server in question, which results in a major slowdown. DNS resolvers that use the workaround are also potentially subject to targeted denial-of-service exploits if an attacker can force all of their queries into the time-out state. Beyond that, some firewalls are dropping DNS queries with EDNS options, which also causes the workaround to be used.

In order to stop that misbehavior, the major players in the DNS world have gotten together to declare the flag day. After February 1, major DNS service providers will stop working around these buggy implementations. In addition, many DNS resolvers (e.g. BIND, Unbound, PowerDNS) will be (or have been) updated to stop doing the workaround as well. Once users start updating their servers to those newer versions, DNS servers beyond those run by the big providers will also stop working around the bug. It is an obvious power play to force the buggy, non-compliant DNS servers to either fix their bugs or for their users to switch away to something compliant.

One of the features that EDNS enables is DNS cookies, which is a simple mechanism that can provide some protection against denial-of-service, amplification, and cache-poisoning attacks. EDNS is also needed to implement DNSSEC. The lack of support for EDNS is holding up important defensive mechanisms that could be more widely deployed and the workaround is just making things worse, which is what led to the flag day.

Domain owners can check if their domains will be affected by using a web form at the "DNS flag day" site that was linked above. Internet Systems Consortium (ISC), which is the organization behind the popular open-source BIND DNS server, also provides the EDNS Compliance Tester (ednscomp), which can give additional information to those running DNS servers. Anyone with their own domains should consult these tools—and soon.

In some ways, this provides an object lesson in the perils of working around buggy implementations. Those workarounds eventually get cast in stone, which allows oblivious users (and vendors) to keep rolling along without dealing with the shortcomings of the software they provide or run. That can stifle innovation and, ultimately, prevent more secure options from being deployed. Given that the internet threat environment is always changing (and rarely, if ever, for the better), it is important to allow maximum flexibility, especially for important protocols like DNS.