reportCompatibleHtml: ': <span style="color: orange;">Minor problems detected!</span></div>' +
	'<div><img style="height: 5em;" src="/signs/compatible.svg"/></div>' +
	'<div>This domain is going to work after the 2019 DNS flag day BUT it does not support the latest DNS standards. As a consequence this domain cannot support the latest security features and might be an easier target for network attackers than necessary, and might face other issues later on. We recommend your domain administrator to fix issues listed in the following',

	reportHighLatencyHtml: ': <span style="color: red;">Serious problem detected!</span></div>' +
	'<div><img style="height: 5em;" src="/signs/high_latency.svg"/></div>' +
	'<div>This domain will face issues after the 2019 DNS flag day. It will work in practice, BUT clients will experience delays when accessing this domain. We recommend you request a fix from your domain administrator! You can refer them to https://dnsflagday.net/ and',

	reportFailHtml: ': <span style="font-weight: bold; color: red;">Fatal error detected!</span></div>' +
	'<div><img style="height: 5em;" src="/signs/dead.svg"/></div>' +
	'<div>This domain is going to STOP WORKING after the 2019 DNS flag day! Please retry the test to eliminate random network failures. If the problem persists you really need to request a fix from your domain administrator. You can refer them to https://dnsflagday.net/ and',

	reportTestErrorHtml: ': Test cannot be evaluated because of an error. Please make sure the domain name entered refers to a <strong>DNS zone</strong>, i.e. use "example.com" instead of "www.example.com". Retry the test to eliminate random network failures or investigate',
	reportLinkText: ' technical report ',  // text before URL to report
},
status: {
	loading: 'Testing in progress, please wait… It might take several tens of seconds.',
	done: 'Testing completed:',
	errorApi: 'Communication error! API unavailable… please try again later',
	errorInput: 'Invalid input or other unexpected error, sorry!',
},

}; </script>

DNS resolver operators

On or around Feb 1st, 2019, major open source resolver vendors will release updates that implement stricter EDNS handling. Specifically, the following versions introduce this change:

• BIND 9.13.3 (development) and 9.14.0 (production)
• Knot Resolver already implemented stricter EDNS handling in all current versions
• PowerDNS Recursor 4.2.0
• Unbound 1.9.0

Also public DNS providers listed below will disable workarounds.

DNS server operators

For introduction to EDNS compliance we recommend you to use form above which produces simplified result for a whole domain.

It is also possible to test your DNS servers directly using the tool ednscomp which displays detailed technical report. Simply enter the name of a zone hosted on your DNS servers into the zone name field and click the Submit button.

The summary result of ednscomp tests should preferably be a green message All Ok.

Minimal working setup which will allow your domain to survive 2019 DNS flag day must not have timeout result in any of plain DNS and EDNS version 0 tests implemented in ednscomp tool. Please note that this minimal setup is still not standards compliant and will cause other issues sooner or later. For this reason we strongly recommend you to get full EDNS compliance (all tests ok) instead of doing just minimal cleanup otherwise you will have to face new issues later on.

If there is a problem, the ednscomp tool displays an explanation for each failed test. Failures in these tests are typically caused by:

• broken DNS software
• broken firewall configuration

To remediate problems please upgrade your DNS software to the latest stable versions and test again. If the tests are still failing even after a DNS upgrade please check your firewall configuration.

Firewalls must not drop DNS packets with EDNS extensions, including unknown extensions. Modern DNS software may deploy new extensions (e.g. DNS cookies to protect from DoS attacks). Firewalls which drop DNS packets with such extensions are making the situation worse for everyone, including worsening DoS attacks and inducing higher latency for DNS traffic.

DNS software developers

The main change is that DNS software from vendors named above will interpret timeouts as sign of a network or server problem. Starting February 1st, 2019 there will be no attempt to disable EDNS as reaction to a DNS query timeout.

This effectivelly means that all DNS servers which do not respond at all to EDNS queries are going to be treated as dead.

Please test your implementations using the ednscomp tool to make sure that you handle EDNS properly. Source code of the tool is available as well.

It is important to note that EDNS is still not mandatory. If you decide not to support EDNS it is okay as long as your software replies according to EDNS standard section 7.

Researchers

Researches and other parties like TLD operators might be interested in:

• EDNS compliance statistics generated by EDNS compliance test suite by ISC
• EDNS zone scanner by CZ.NIC which aims to evaluate real-world impact of the DNS flag day

Please read respective methodologies before interpreting the data. In any case, do not hesitate to reach out to tool authors using Gitlab links above.

Presentations

• DNS-OARC 28: abstract, slides, video
• LOADAYS 2018: abstract, slides, video
• RIPE 76: slides, video
• DNS-OARC 29: abstract, slides

Tools

• ISC EDNS Compliance tester, source code
• DNSViz

Contacts

• Please file comments regarding this web in dnsflagday repo on Github
• Comments regarding test results generated by this web or directly by ednscomp test tool belong to DNS Compliance Testing project in ISC Gitlab

Supporters

Additional reading

• Minimal EDNS compliance requirements
• “The DNS Camel”, or, the rise in DNS complexity