Are you ready for DNS Flag Day?
They were only trying to do the right thing. When a recursive DNS server issues a query using DNS Extensions (EDNS) to another DNS server and the answer indicates a format error or there is no answer at all, developers of various recursive DNS server implementations created workarounds such as reissuing the query without extensions or querying another server authoritative for the same zone. This philosophy centered on coding the recursive server to fetch an answer even if it meant trying to ask in many different forms.
While a noble pursuit in "doing what it takes" to obtain an answer, these and similar workarounds introduce additional queries of various formats and additional processing requirements on the recursive server. These inefficiencies, while intended to satisfy the requirement of answering the query, are needlessly reducing performance and scalability of the Internet. And as more extension features are introduced, complexity of recursive server software will increase; and if such code must include workarounds for each new feature, the inefficiencies and fragility of the code become untenable.
EDNS was initially defined in 1999 as RFC 2671 as a means to expand existing constraints of defined DNS protocol message field sizes and to enable advertising of supported extension capabilities to queried DNS servers. The intent was to enable extension of the DNS protocol to support more response codes, enable larger message payloads, e.g., for DNSSEC, and to facilitate support for new features.
Since its inception, EDNS now enables such feature extensions as providing the responding name server identity (NSID, useful particularly in anycast deployments), DNS-over-TCP keepalive messages, signalling of DNSSEC algorithm support, client subnet (used by authoritative servers to provide query answers "close" to the querier), and DNS cookies (a lightweight DNS transaction security mechanism).
RFC 2671 has been updated and obsoleted by RFC 6891 which mandated all DNS servers support the OPT resource record type, the prime mechanism of EDNS. Now major DNS vendors are mandating fully compliant support of EDNS. February 1, 2019 is DNS Flag Day, or perhaps more appropriately EDNS Flag Day. As of this date, major open source DNS software will begin to make available software updates to remove the EDNS workarounds and apply strict conformance to EDNS standards. How will this affect you?
First, don't panic. If your recursive DNS servers do not fully comply with the new less tolerant EDNS processing recommendations, your servers should continue to support fully compliant and perhaps those not fully compliant, but you will be contributing to a less efficient Internet. In addition, your recursive servers may not support some or all of the aforementioned DNS feature extensions.
If your authoritative DNS servers do not fully and compliantly support EDNS, strictly compliant recursive servers querying your namespace to reach your web server, email server, etc., may have queries go unanswered. If your server does not answer using EDNS as requested and in the proper format, the querier not reattempt the query. You can check your level of compliance by entering your domain name at https://dnsflagday.net. If you are not compliant, remember the flag day stipulates the beginning of software availability of strict EDNS processing. Talk with your DNS vendor and plan to upgrade as soon as practical to make full avail of your namespace.
While a noble pursuit in "doing what it takes" to obtain an answer, these and similar workarounds introduce additional queries of various formats and additional processing requirements on the recursive server. These inefficiencies, while intended to satisfy the requirement of answering the query, are needlessly reducing performance and scalability of the Internet. And as more extension features are introduced, complexity of recursive server software will increase; and if such code must include workarounds for each new feature, the inefficiencies and fragility of the code become untenable.
EDNS was initially defined in 1999 as RFC 2671 as a means to expand existing constraints of defined DNS protocol message field sizes and to enable advertising of supported extension capabilities to queried DNS servers. The intent was to enable extension of the DNS protocol to support more response codes, enable larger message payloads, e.g., for DNSSEC, and to facilitate support for new features.
Since its inception, EDNS now enables such feature extensions as providing the responding name server identity (NSID, useful particularly in anycast deployments), DNS-over-TCP keepalive messages, signalling of DNSSEC algorithm support, client subnet (used by authoritative servers to provide query answers "close" to the querier), and DNS cookies (a lightweight DNS transaction security mechanism).
RFC 2671 has been updated and obsoleted by RFC 6891 which mandated all DNS servers support the OPT resource record type, the prime mechanism of EDNS. Now major DNS vendors are mandating fully compliant support of EDNS. February 1, 2019 is DNS Flag Day, or perhaps more appropriately EDNS Flag Day. As of this date, major open source DNS software will begin to make available software updates to remove the EDNS workarounds and apply strict conformance to EDNS standards. How will this affect you?
First, don't panic. If your recursive DNS servers do not fully comply with the new less tolerant EDNS processing recommendations, your servers should continue to support fully compliant and perhaps those not fully compliant, but you will be contributing to a less efficient Internet. In addition, your recursive servers may not support some or all of the aforementioned DNS feature extensions.
If your authoritative DNS servers do not fully and compliantly support EDNS, strictly compliant recursive servers querying your namespace to reach your web server, email server, etc., may have queries go unanswered. If your server does not answer using EDNS as requested and in the proper format, the querier not reattempt the query. You can check your level of compliance by entering your domain name at https://dnsflagday.net. If you are not compliant, remember the flag day stipulates the beginning of software availability of strict EDNS processing. Talk with your DNS vendor and plan to upgrade as soon as practical to make full avail of your namespace.
Comments
Post a Comment