What You Need to Know About DNS Flag Day
This blog was written by Michael Schneider, Lead Product Manger.
The internet is built on Postel’s law, often referred to as the robustness principle: “Be conservative in what you do, be liberal in what you accept from others.” In the protocol world, this means that receivers will try to accept and interpret data that they receive to their best knowledge and will be flexible if the data doesn’t fully match a specification. Senders should adhere to specifications and comply with protocol specifications, as laid out in Request for Comment documents (RFCs) by the Internet Engineering Task Force.
DNS was released as RFC 1035 in 1987 and was superseded by EDNS in 1999 with RFCs 2671 and 6891. EDNS, or extension mechanisms for DNS, aimed to flexibly deploy new features into the DNS protocol, including protection against DNS flooding attacks amongst other performance and security enhancements. These attacks can cause a major outage for cloud-based infrastructure, which happened in 2016 with the DDoS attack on DNS provider Dyn.
To avoid such attacks and improve DNS efficiency, several DNS software and service providers—like Google, Cisco, and Cloudflare—have agreed to “coordinate removing accommodations for non-compliant DNS implementations from their software or service,” beginning Feb. 1, 2019, or DNS Flag Day.
Before DNS Flag Day, if an EDNS server requested a name resolution from a non-EDNS resolver, it would first send an EDNS query. If there was no response, the server would then send a legacy DNS query. That means that the timeout for the first query would need to be reached before the legacy DNS query was sent, generating a delayed response. These delays ultimately make DNS operations less efficient.
But with the new changes introduced for DNS Flag Day, any DNS server that doesn’t respond to EDNS will be seen as “dead” and no additional DNS query will be sent to that server. The result? Certain domains or offerings may no longer be available, as name resolution will fail. Organizations should plan to provide a bridge between their internal DNS and a provider’s DNS to ensure that the EDNS protocol is used. They should also work with their vendors to verify that EDNS is part of DNS communication and obtain a version of the respective product that complied with the requirements of EDNS.
The DNS Flag Day protocols are a disruptive move, as they break from Postel’s law—servers can no longer automatically accept every query. But as with most internet-related innovations, progress requires a little disruption.