Skip to content

Latest commit

 

History

History
179 lines (119 loc) · 13 KB

index.md

File metadata and controls

179 lines (119 loc) · 13 KB
Raw
title lang
2019
en-US

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 more than a decade 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. DDoS attack.

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 software which does not comply to the main DNS standard, (RFC1035) or the newer standards for Extensions to DNS EDNS, (RFC2671, RFC6891). These sites are either using outdated or unmaintained DNS software, or have excessively restrictive firewall settings that block important DNS signals.

For more information select the group you belong to:

vendors of DNS software and also big public DNS providers are going to remove certain workarounds on February 1st, 2019.

This change affects only sites which operate software which is not following published standards. Are you affected?

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. It is only necessary to validate one zone if you have multiple zones on the same server or cluster of servers. Your test result will include advice on any further steps that may be necessary.

{% include checker.html lang=site.data.checker.en %}

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). Incompatible sites may become unreachable through updated resolvers. Major public DNS resolver operators listed below are also removing accommodations.

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.

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

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

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:
  • Akamai
  • BlueCat
  • F5 BIG-IP
  • Older versions of the Juniper SRX will drop EDNS packets by default. The workaround is to disable DNS doctoring via # set security alg dns doctoring none. Upgrade to latest versions for EDNS support.

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

Test details

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

This hosted tool is a low-capacity service for ad-hoc checks only. Do not attempt to automate queries. Excessive use will be rate-limited or blocked. If you need to send bulk queries, you must download and build the tools to run your own test instance - see https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing and https://gitlab.labs.nic.cz/knot/edns-zone-scanner/.

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.

Your domain name may include "www", e.g. "www.domainname.com"; or it may not, e.g. "domainname.com". 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.

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

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, for example, 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:

  • broken DNS software
  • broken 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.

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

Researchers and other parties such as TLD 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.

Presentations

General audience

Technical

Tools

Contacts

Supporters

{% include supporters.html %}

Additional reading