Quad9 and DNS Flag Day

Some of you may have seen announcements of Quad9’s participation in the industry-wide “DNS Flag Day” event, slated for February 1, 2019.

By participating in the Flag Day, we are confirming that our recursive resolvers will no longer try an exhaustive set of different ways to test a remote authoritative server to see if it has problems with EDNS (RFC2671 and RFC6891). EDNS is an extension to DNS that has been around for almost 20 years – this is not a new or surprising change to the standards, but we’re now committing that we are holding remote servers to those IETF RFC basic responses. Making sure that servers can support EDNS is future-proofing the DNS system, as more and more critical services utilize DNS, such as DNSSEC. Remote servers need to comply with a bare minimum of standards to remain inter-operational and cooperative with other systems that wish to communicate.

Servers that do not respond at all to EDNS-compliant DNS messages will be marked as non-operational and no further attempts to send the request will be made. If the remote authoritative server does not support EDNS responses, then that’s fine, too – but it should reply back and respond with an equivalent message of “I don’t support EDNS” instead of just giving no answer at all, and our systems will communicate using non-EDNS methods and the request will be completed normally. This Flag Day change is actually much less aggressive than it could have been – it’s only saying that we require a response that is standards-compliant, and no response at all is treated the same way as a network failure. More details can be found on the DNS Flag Day site – https://www.dnsflagday.net/

What does this mean to me? What will break?

Chances are very good that this will not cause any interruption in any of your normal Internet activity if you’re a user of Quad9’s recursive resolution services. The number of older or non-compliant DNS servers is small, and the number of domains that will stop working is similarly a tiny percentage of active domains.

As of this writing (February 1) there are 761 domains in the Alexa top 1 million that have a good chance of failing as a result of the Flag Day changes that we will be implementing. Those 761 zones represent just 0.07% of the domains – less than 1 out of 14000. This is just a statistical sample of the most popular domains, but the percentages are a reasonable place to start with estimating. Here is compliance list put together by ISC (Internet Systems Consortium) that is updated regularly and automatically. If you have a domain name, you can check for compliance by your DNS operator https://dnsflagday.net/

One of the core results of this Flag Day event is to help bring attention to those last operators who have not updated their code or systems to meet the standards that have existed for two decades. We hope and expect that the list of failing authoritative resolvers and domains will quickly drop to zero.

The whole Quad9 array will not cut over to this more strict interpretation on February 1 in one large conversion event. February 1 is the date that we’ve said that non-standards compliant DNS servers (and the domain names served by them) will no longer be subject to “work-around” code that falls outside the IETF standards for DNS. It’s the last day that we’re saying that efforts will be applied towards solving the problems that are introduced by these non-standards-compliant systems. The code deployments with workarounds removed will follow our standard deployment pipeline and appear in our locations as soon as it has been tested and proven out as with all our other major release updates.

What’s the point? Why even an announcement?

There are sets of standards that underpin all of the technology that makes the Internet a working network. Everyone agrees upon those standards, and that’s what allows for functionality between the tens of thousands of vendors who build interconnecting platforms and the millions of programs that rely on those common reference descriptions. There are dozens of different ways that it is possible not to follow a standard, and pushing the costs of bad standards or code onto everyone else cause the protocols and networks to grind to a halt.

For a very long time, the various DNS software authors and recursive DNS services operators have built-in workarounds for bad EDNS behavior, which can cause problems with local memory/CPU resources or code complexity. After long enough, workarounds have become ‘standard operating procedure’ and became buried under more layers of practices and code. Like a house built on a poor foundation, this eventually started to cause problems that were painful, and a decision to remove the workarounds became less effort than continuing to try to layer on repairs. Current workarounds have been in place for so long that a shift to better adherence to the RFCs deserved a very long pre-announcement phase and to give authoritative operators an opportunity for updates and repairs. Our goal is to cause as little interruption to services as possible while still pushing forward to make the network more stable in the long term. DNS Flag Day is the result of that process and decision, and we’re happy to see the simplification and improvement of the DNS ecosystem.

Questions?

If you have questions or concerns about the Quad9 DNS Flag Day participation, please send them to send us a request via our support form.

Thanks!

We want to thank everyone in the DNS community who have pushed for this effort, including our software partners at NLNet Labs and PowerDNS.