DNS is one of the foundation protocols of the internet, designed around 1987- which can technologically seem like an eternity based on today’s standards. Since then, context of usage of the internet has changed, and the protocol has evolved to support new features like DNSSEC and message size limitations.
DNSSEC is used more and more on the internet in order to increase the global security of the system, but some servers or network components are either not compatible or not properly configured to support this enhancement. For example, there are many of firewalls configured to drop EDNS packets or high-length packets, which causes the service to not be compatible with the evolution of the protocol. Some old authoritative name servers are not able to support DNS extension, but routinely maintained equipment is compatible.
Over time, vendors and DNS editors have added workarounds in their software in order to allow the service to continue running even if these cases are encountered, resulting in a severe uptick in software maintenance efforts. This situation is no longer sustainable.
Therefore, in order to increase security of the whole internet network for all users and services, chief DNS software editors and service providers have announced that they will cease implementing DNS resolver workarounds to accommodate DNS authoritative systems that don’t follow the standard RFC(s) and Extensions of DNS (EDNS) protocol. The roll out of this change will be performed in versions of their software released after DNS Flag Day (1st February 2019).
What will happen on the 1st of February (DNS Flag Day)?
Nothing most likely, since new software versions will not be deployed on this specific date and most server software currently in production are supporting EDNS version 0 requirements which are 20 years old (August 1999, RFC 2671)- except for public DNS resolver services (e.g. Google DNS, Quad9, etc.) who might rollout the change at anytime. But any version deployed after this date will implement the new policy and authoritative name servers which are not compatible with EDNS will be considered non-reachable, preventing any resolution of hosted domains.
How could you be affected?
1) A domain is unreachable (no service available), 2) A domain may be slower to answer, 3) Service hosted on a domain may be unavailable from time to time, which could be caused by some of the authoritative servers being poorly configured. For most implementations, the likelihood is low.
What to do now?
1) Validate that your DNS server supports the EDNS extension (see compliance tester in the resources section below) and 2) Validate that the firewall and load-balancer protecting these servers are not configured to block specific EDNS queries (extensions and packet size).
If you are an EfficientIP customer: domains hosted on EfficientIP DNS servers and running a maintained version are not impacted by point 1 above. All DNS services provided to users of EfficientIP recursive servers are not impacted by filtering and DNS level (check point 2 anyway on load-balancers and firewalls above), and any new release implementing such filtering will be announced accordingly.
–> Resources on the web:
- EDNS compliance site of the ISC
- EDNS compliance report
- EDNS compliance tester
- DNS flag day on ISC
- DNS flag day on NLNetlabs
- RFC2671: Extension Mechanisms for DNS (EDNS0)
- RFC1034: DOMAIN NAMES – CONCEPTS AND FACILITIES
- DNS flag day special site
Have more questions on DNS Flag Day?