DNS Flag Day - Notes for Authoritative Zone Owners and DNS Hosting Companies

DNS flag day is when vendors of recursive name servers will stop releasing new software that accommodates ancient or broken authoritative servers and firewalls. Instead of trying over and over in different ways to coax the servers to send back an answer, new resolver software (and cloud-based resolver services that are supporting DNS Flag Day) will just declare the remote server to be broken, and give up.
DNS Flag day is 1st February 2019. Zones running on non-compliant servers or services will not all suddenly disappear on this date, but will gradually become unreachable, slow or intermittently unavailable as cloud resolver operators, ISPs and corporate resolver administrators upgrade their software.
Symptoms will vary:

• Some domains will become solidly unreachable
• Domains may be slower to resolve than before - this may give the appearance of slow connectivity rather than DNS problems
• Services may become intermittently unavailable due to variable authoritative server behaviour and how this is cached by resolvers.

Test your domains

You can use the online testing tool hosted by ISC here:
https://ednscomp.isc.org/ednscomp/
This tool is also available indirectly at https://dnsflagday.net/
The hosted testing tool is intended for low-volume use - therefore if you need to check a large number of domains, we recommend instead that you download and run it locally - is available for download from https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing. You might also be interested in Testing EDNS compliance directly using dig.

Interpreting the test results

• If you are using the online testing tool at dnsflagday.net then for any test results that are not a full pass, you will be provided with a link to a report generated by ednscomp (from ednscomp.isc.org) See below for more information on the report that has been generated.
• The online testing tool at ednscomp.isc.org will always display the full test results report.
• genreport(the EDNS compliance testing tool when you download, build and run it locally) will always display the full test results report for the tests that had been selected to be run.

The test output is a list of status codes (one per test) for each nameserver identified as authoritative for the zone being tested.
For example:

Which are the test failures that need priority attention?

The minimum compliance level for 2019 DNS flag day is to avoid having any timeout results in any of the plain DNS and EDNS version 0 tests. In the above example, you are looking for these specific test results as confirmation that you will not see problems as a result of resolver upgrades after DNS Flag day:
dns=ok
edns=ok
ednsopt=ok
ednsflags=ok

Are there any test failures that I don't need to be concerned about (right now)?

You don't yet need to take action to remedy test failures using future EDNS versions (i.e. EDNS1), but we strongly urge you to take steps to ensure that as soon as possible your DNS service is compliant in handling EDNS versions >0. It is a component of proper EDNS-compliant behavior that servers that respond appropriately when they receive client queries containing:

• EDNS versions greater than they currently support
• EDNS options that they don't currently support
• EDNS flags that they don't recognise

These are the tests that you do not need to worry about immediately, even if the status returned is not 'ok':
edns1=ok
edns1opt=ok
ednsflags=ok

Other ednscomp tests

The online testing tool checks routinely for support for specific EDNS0 options. It reports on:

• Specific EDNS0 options that are unsupported by the authoritative server - i.e. when the server indicates in its response that it does not work with these options. These test failures will not cause new service problems following DNS flag day but lack of support for new EDNS functionality will eventually limit your future security, privacy and performance capabilities.
• Non-compliant query responses (such as echoing the options without alteration, or returning unexepected status codes) to EDNS0 options. Non-compliant responses (excepting timeouts) should not cause any new service problems following DNS flag day but may already be affecting the ability of your customers to access your services.

The tests performed by the online tool are those where non-compliance will ultimately be detrimental to the failing DNS zone.

Other tests are available - these are predominatly of interest to researchers.

A reference list for the full set of ednscomp tests available and potential failure response codes can be found here:
https://kb.isc.org/v1/docs/ednscomp-tests-and-status-codes

Fixing non-compliance...

Here is a checklist of production environment software and configuration options that you need to check and fix (if you identify problems):

1. Ensure that you are running current versions of DNS server software (from your software or appliance vendor or OS packager).

All versions of ISC BIND 9 are EDNS compliant, but we always recommend running a currently-supported version: https://www.isc.org/downloads/

NLnet Labs NSD versions 1.0.0 and newer are EDNS compliant https://www.nlnetlabs.nl/projects/nsd/download/

PowerDNS 4.1 is fully EDNS compliant; 4.0 has some corner cases that ednscomp notices but that are not a problem in practice - disabling caching removes those edge cases. https://www.powerdns.com/auth.html

All versions of Knot authoritative server are EDNS-compliant. https://www.knot-dns.cz/

2. If running OpenSource DNS software indirectly obtained via your OS packager, compare this with the latest versions available directly from the packager.

3. If running an appliance or proprietary DNS authoritative solution, contact your provider for advice - most have already posted information on their websites, blogs and social media.

4. Are you running a firewall, packet filter, or load-balancer in front of your DNS servers? If your DNS servers are fully EDNS-compliant, then problems may be arising elsewhere - check with your vendor for advice.

Common DNS problems seen with load-balancers, firewalls and older DNS implementations

• Client queries using TCP are blocked. Ensure that in your device configuration that TCP is allowed. (Additionally if the device keeps state, check that it is has a large enough state table and internal buffer space)
• Incomplete zone delegation to load-balancer. Some load-balancer devices operate as proxy authoritative servers, but may have be configured only do so for IPv4. It is important that they also have IPv6 delegated to them, even if you don't have AAAA RRsets in your zone, otherwise they may offer broken query responses
• Some routers and packet filters drop DNS packets that contain EDNS options. This behavior will result in significant resolution failures for your domain after DNS Flag day, even if your DNS servers themselves are running modern software. Refer to your device documentation or ask your provider for advice. In the short term, you may be able to work around problems by disabling packet inspection or filtering
• Some EDNS-unaware equipment echoes back unknown EDNS options and flags in the query response. This behavior will cause non-critical EDNS test failures and will not cause DNS resolution problems after DNS flag day, but you do need to fix this to future-proof your zone. Refer to your device documentation or ask your provider for advice.
• Older versions of the Juniper SRX (and some other routers) will drop EDNS1 packets by default. The ednscomp signature combination of test failures for Juniper devices is edns1=timeout edns1opt=timeout optlist=timeout(other tests pass unless failed by the DNS server behind). The workaround is to disable DNS doctoring via # set security alg dns doctoring none. Upgrade to latest versions for full EDNS support.
• Some older Checkpoint firewalls also drop EDNS1 packets, but with a slightly different signature of test failures: edns1=timeout edns1opt=timeout ednsflags=timeout(other tests pass unless failed by the DNS server behind it). Upgrade your firewall and/or contact Checkpoint for advice
• Some firewalls block DNS packets larger than 512 bytes. Check your firewall configuration and remove or reconfigure maximum packet sizes to match those supported by the DNS servers in your infrastructure.
• Although not strictly an EDNS compliance problem, UDP packet fragmentation can cause timeouts that previously would have been accommodated by resolver retries. UDP packet size delivery problems will become a problem after DNS Flag Day. We recommend testing and then tuning your infrastructure either to allow UDP fragmentation and reassembly or to identify MTU and then configure your DNS servers not to send query responses that will exceed this. Your servers also need to support client queries over TCP.
• Very old STD 13 (RFC 1034 & RFC 1035) DNS servers that don't support EDNS typically respond to EDNS queries with FORMERR and omit the OPT pseudo-record from their reply. They also may return the SOA RR in their query response. Look in the ednscomp test results for this combination of failures: dns=ok edns=formerr,noopt edns1=formerr,noopt edns@512=formerr,noopt ednsopt=formerr,noopt edns1opt=formerr,noopt do=formerr,noopt ednsflags=formerr,noopt optlist=formerr,noopt signed=formerr,noopt ednstcp=formerr,noopt. Note that although this is a response from a very old server that does not support EDNS, the FORMERR response will prompt most resolvers to retry the query without EDNS, so this server should not be further disadvantaged by DNS Flag Day unless it also implements a feature that ratelimits FORMERR responses. Either way, an upgrade is strongly recommended

Hosted DNS Zones