View on GitHub

DNS flag day

DNS flag day 2019

What is happening?

The current DNS is unnecessarily slow and inefficient because of efforts to accommodate a few DNS systems that are not in compliance with DNS standards established two decades ago.

To ensure further sustainability of the system it is time to end these accommodations and remediate the non-compliant systems. This change will make most DNS operations slightly more efficient, and also allow operators to deploy new functionality, including new mechanisms to protect against DDoS attacks.

DNS software and service providers listed on this site have agreed to coordinate removing accommodations for non-compliant DNS implementations from their software or services, on or around February 1st 2019. This change will affect only sites operating non-compliant software.

For more information select the group you belong to:

I’m an Internet user

There is no reason to worry if you are an Internet user without your own domain name. This change is affecting you only indirectly and you do not need to take any other steps. Thank you for your interest in DNS!

I’m a domain holder

If you are a domain holder, please use the form below to check if your domain is ready for the planned change. Your test result will include advice on any further steps that may be necessary.

Test your domain

Please note it is only necessary to validate one zone if you have multiple zones on the same server or cluster of servers. See technical details of tests for more information.

I’m a DNS administrator

The impact of the scheduled change to the client side of DNS is described in the section for DNS resolver operators. A small percentage of authoritative servers might require changes described below. Further down we list technical details of tests and tools for experts.

DNS resolver operators

On or around Feb 1st, 2019, major open source resolver vendors will release updates that will stop accommodating non-standard responses. This change will affect authoritative servers which do not comply either with the original DNS standard from 1987 (RFC1035) or the newer EDNS standards from 1999 (RFC2671 and RFC6891). Major public DNS resolver operators listed below are also removing accommodations so this change will also impact Internet users and providers who use these public DNS services.

Sites hosted on incompatible authoritative servers may become unreachable through updated resolvers. The web form above diagnostic tool may be helpful while investigating problems with a particular domain. Domains which repeatedly fail the test above have problems with either their DNS software or their firewall configuration and cannot be fixed by DNS resolver operators.

The following versions of DNS resolvers will not accommodate EDNS non-compliant responses:

DNS server operators

After February 1st 2019 major public DNS resolver operators listed below will disable work arounds for standards non-compliance. This change will affect domains hosted on authoritative servers which do not comply either with original DNS standard from 1987 (RFC1035) or the newer EDNS standards from 1999 (RFC2671 and RFC6891). Non-compliant domains may become unreachable through these services.

We advise you to take the following preparatory steps to avoid operational problems:

  1. Test your authoritative servers using test form above. It is sufficient to test a single DNS zone hosted on a particular set of authoritative servers. (If any single zone on the server passes the test, that is sufficient, because the test is not dependant on the content of the zone.)
  2. Random network instability can affect test results. Part of the problem is in interpreting timeouts, which can be caused by unresponsive DNS software, a firewall blocking the response, or packet loss on the Internet. If a problem is reported please retry the test.
  3. If the tested domain fails the test, please update your DNS software to the latest stable version and repeat the test. If the tests are failing even after the DNS software update please check your firewall configuration.
  4. Firewalls must not drop DNS packets with EDNS extensions, including unknown extensions which follow the standards.

Relevant information from vendors can be found here:

If the problem persists after DNS software and firewall updates please contact your firewall vendor and request fixes.

Test details

Your domain name may include www, e.g.; or it may not, e.g. If you are not sure, we suggest that you test both. Names that are not DNS zones will report that this was the most likely reason for the test failure; this is not a cause for concern.

Mass scanning

The test form above uses hosted ednscomp, which is a low-capacity service for ad-hoc checks only. If you need to send bulk queries, you must use tools linked below to run your own test instances. Please do not attempt to automate queries using this web site, an excessive use will be rate-limited or blocked.

Obtaining detailed test results

The test form above uses ednscomp for individual technical tests, and these partial results are summarized into an aggregate result by the web application.

It is also possible to test your DNS servers directly using the tool ednscomp which displays a more 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 ideally be a green message All Ok.

Minimal working configuration

The minimal working setup which will allow your domain to survive 2019 DNS flag day must not have a timeout result in any of the plain DNS and EDNS version 0 tests implemented in the ednscomp tool. Failures of the EDNS(1) tests will not cause any immediate problem.

Please note that this minimal compliance is still not full compliance and will cause other issues sooner or later. For this reason we strongly recommend you to work towards full EDNS compliance (all tests ok) instead of doing just the minimum.

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

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.

I’m a DNS expert

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 in reaction to a DNS query timeout.

This effectively 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 for 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.

In other words, software which correctly implements the original DNS standard RFC1035 from 1987 does not require any changes. Only non-compliant software has to be fixed.


Researchers and other parties such as TLD operators might be interested in:


General audience



Researchers and other parties such as large DNS operators might be interested in:

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



Additional reading