February 1, 2019: is the DNS going to shake?

A new deadline is about to shake the internet ... After the Year 2000 bug, the drying-up of IPv4 addresses, and the first root key rollover, get ready for the "DNS Flag Day" ... In 1 week...

Explanation

The Domain Name System (DNS), as we know it, was standardized 30 years ago by IETF (RFC1034 and RFC1035). In internet terms, thirty years is an eternity. The context has changed since then and so have the issues and expectations, but despite its design dating from another age, the DNS continues to be an essential infrastructure for internet communications.

Rapidly limited in its structure and to meet new needs, an additional standard, EDNS (RFC2671 - published in 1999 and updated in 2013 RFC6891), brought complementary features to support new protocols/extensions, such as DNSSEC, that were not envisioned at the design time of the initial DNS standard. The EDNS standard came to remove limitations that did not make much sense anymore, such as the (too low) DNS maximum packet size (512 bytes).

Being not in limelight as a necessity for a long time, EDNS, gained importance with the wide deployment of DNSSEC, among others, which has become an essential part of the DNS protocol. However, there are implementations of the protocol that still do not meet this standard, not to mention poorly configured firewalls that block packets using this option. This leads to responses (or even no responses at all) that are difficult to interpret when processing DNS queries, which leads to a significant increase in processing time, thus detracting from the user experience.

The nonconformity of certain hardware has required setting numerous workarounds in the code (provided by major DNS software vendors) of the recursive resolvers, in order to distinguish the cases of servers that are genuinely unreachable from the cases of servers not correctly supporting EDNS. This makes the code more complex to maintain, less efficient, more fragile, and longer to modify when it comes to new technology handling EDNS.

As of February 1, 2019, these workarounds will be removed from the new versions of the tools of major DNS software vendors (the ISC for Bind as of version 9.14, CZ.NIC for Knot-Resolver as of version 3.3.0, NLnet Labs for Unbound as of version 1.9.0, PowerDNS for PowerDNS Recursor as of version 4.2.0). Any server not responding to queries using EDNS will consequently be considered unreachable. They will be accompanied by some of the major DNS service providers.

In practical terms, what is going to happen? Probably nothing on D-Day, since the change will only start to be noticeable when the latest versions of the tools (some of which are not yet released in their stable versions) are deployed. But, little by little, malfunctions could appear for DNS zones hosted on servers too lax with respect to the standard or for users behind a poorly configured firewall.

This is why you should check as soon as possible, if the servers that host your DNS zone(s) will be affected by the change and apply the necessary measures in a timely manner.

How to check?

It couldn't be simpler! Just go to the link https://dnsflagday.net/ (which provides a detailed technical explanation of this "DNS Flag Day") and use the interface provided for this purpose. Here is the type of result expected for a complying domain name (ie, not affected):

For a more complete test, it is also possible to use the Zonemaster tool which is about to be updated for the occasion (stay tuned) and which in addition to hundreds of tests done on DNS servers serving your domain names, performs new tests specific to EDNS.

Official communication from DNS software providers:

• ISC/Bind
• CZ.NIC/Knot-Resolver
• NLNETLABS/Unbound
• PowerDNS/PowerDNS Recursor

Level of compliance of the Top-Level Domains (TLDs) managed by Afnic

To determine the impact of this change, we can count on the results of the excellent tool developed by CZ.NIC, namely the "EDNS Compliance scanner for DNS zones" which allows us to scan the entirety of a TLD and carry out the conformance test on the whole TLD zone.

As we will see, the vast majority of delegated zones will not be impacted.

.Fr TLD (on a version of the base dating from January 2019)

A few keys to decipher the table:

• The Permissive (<= 2018) column corresponds to the current behavior of DNS resolution software, the Strict (2019+) column corresponds to tool versions without the workarounds;
• The Ok line corresponds to the domains that are compliant, i.e. the vast majority;
• The Compatible and High latency lines indicate non-compliant domains but for which resolution is nevertheless possible;
• The last line, Dead is the most critical because the difference between the 2 values indicates the number of domain names that will probably fail to resolve.

For the .fr TLD, we can see that to date, more than 100,000 delegated zones are not correctly resolved and that 10,000 new ones could join them from February 1. These are the 10,000 zones that may not be resolved any time after the “DNS Flag Day".

Impact on the other TLDs operated by Afnic

In the twenty or so TLDs we operate, we can see exactly the same distribution in terms of EDNS compliance levels. Of course, because of its size, it is under the .fr TLD that the largest contingent of problematic zones will be found.

All TLDs combined, nearly 11,000 zones will be impacted by the change from February 1.

The recommendation is to carry out the EDNS compliance tests and make the necessary modifications, either yourself or by asking your DNS hosting provider.