EDNS Compliance Report: 2015-06-04T03:29:28Z

EDNS has been a defined standards track protocol extension to the DNS for 15 years. EDNS support is a node requirement for IPv6 and is a requirement for DNSSEC.

We look at the level of nominal EDNS support and at the level of compliance to the various EDNS features. We use a number of sample sets in generating this report.

We also looked at the level of compliance to individual EDNS features as that impacts on which extension method should be chosen when extending EDNS on a global basis rather than on a consensual basis between co-operating servers and client.

We looked at adding a unknown EDNS option, using a unknown EDNS version and sending a unknown EDNS flags. The expected behaviour for all of these actions are well defined but not all EDNS aware servers were well behaved when presented with EDNS extensions.

We also looked at basic EDNS version zero compliance.

Lack of EDNS compliance causes resolver vendors to have to develop workarounds. As more extensions get deployed this becomes a harder and harder jobs as it becomes trial and error to discover what works with a given authoritative server.

Testing Methodology

The level of EDNS compliance of a authoritative server is relatively easy to determine with a few simple DNS queries.

EDNS faults detected

What we expect to see:

The above expectations are based on the following preconditions.

When EDNS version 1 is defined we expect to see:

OPT record with version set to 0 or 1

When sending a EDNS versions other than zero, you expect to see BADVERS or a EDNS version greater than or equal to the version you send in the response. If the version is less than version you send and the status is NOERROR, NXDOMAIN or YXDOMAIN the server is non compliant.

Nominal EDNS Support

EDNS is nominally well supported.

While EDNS is nominally well supported lots of implementations fail to handle more than a basic EDNS version 0 query.

Firewalls impact the response rates with queries with unknown EDNS versions being the most impacted.

What extension mechanism should I choose?

If it wasn't for firewalls blocking queries with unknown EDNS flags, they have the cleanest authoritative server behaviour with only the echoing of unknown flags being the other issue.

For unknown EDNS options and unknown EDNS versions there are variety of invalid responses to deal with but the major issue is firewalls blocking "unknown" EDNS version thereby preventing EDNS version negotiation from occuring.

Until the bad firewall behaviour can be addressed, I would say that just sending a new EDNS option is the best choice. Timeouts take too long to just use trail-and-error to find a working combination of options and versions.

What to do to address the numbers of broken system?

Up-to-date results can be found at http://users.isc.org/~marka/

[1] +ednsopt and +ednsflags require BIND 9.11.0 or later. Pre-alpha versions of BIND 9.11.0 (master branch) are available through the BIND 9 git repository at https://source.isc.org/

Other EDNS Compliance Reports

CH and LI Report

EDNS Compliance over Time

A EDNS aware server is one which returns a EDNS response to at least one of the test queries. A active server is one which returns a response to one of the test queries. Inactive servers are discarded when calculating the EDNS aware percentages.

2014-09-11: Cloudflare replaced server software which only returned a EDNS response when DO was set to one in the request to a server which ignores EDNS in the request.

2014-10-10: Stopped setting AD=1 in test queries.

2014-10-29: Cloudflare restored EDNS support.

"Percentage of responding servers that are EDNS aware" only

"Percentage of EDNS aware servers that passed all EDNS compliance tests" only

(dig +edns +norec soa $zone @$server)
expect: status: NOERROR
expect: SOA record to be present
expect: OPT record to be present
expect: EDNS Version 0 in response

"Percentage of EDNS aware servers that passed plain EDNS(0) check" only

(dig +dnssec +norec soa $zone @$server)
expect: status: NOERROR
expect: SOA record to be present
expect: OPT record to be present
expect: EDNS Version 0 in response
expect: DO flag in response if RRSIG is present in response
See RFC3225

"Percentage of EDNS aware servers that passed EDNS(0) + DO=1 check" only

(dig +edns=1 +norec soa $zone @$server)
expect: status: BADVERS
expect: SOA record to NOT be present
expect: OPT record to be present
expect: EDNS Version 0 in response
See RFC6891, 6.1.3. OPT Record TTL Field Use

"Percentage of EDNS aware servers that passed plain EDNS(1) check" only

(dig +edns +dnssec +bufsize=512 +norec +ignore dnskey $zone @$server)
expect: status: NOERROR
expect: OPT record to be present
See RFC6891, 7. Transport Considerations

"Percentage of EDNS aware servers that returned OPT record in truncated EDNS(0) response" only

(dig +ednsopt=100 +norec soa $zone @$server)
expect: status: NOERROR
expect: SOA record to be present
expect: OPT record to be present
expect: OPT=100 to not be present
See RFC6891, 6.1.2 Wire Format

"Percentage of EDNS aware servers that handled unknown EDNS(0) options correctly" only

(dig +ednsopt=100 +edns=1 +norec soa $zone @$server)
expect: status: BADVERS
expect: SOA record to NOT be present
expect: OPT record to be present
expect: OPT=100 to not be present
expect: EDNS Version 0 in response
See RFC6891

"Percentage of EDNS aware servers that handled unknown EDNS(1) options correctly" only

(dig +ednsflags=0x80 +norec soa $zone @$server)
expect: status: NOERROR
expect: SOA record to be present
expect: OPT record to be present
expect: MBZ not to be present
expect: EDNS Version 0 in response
See RFC6891, 6.1.4 Flags

"Percentage of EDNS aware servers that handled unknown EDNS(0) flags correctly" only

"Percentage of responding servers that responded to a plain EDNS(0) request" only

"Percentage of responding servers that responded to a EDNS(0) + DO=1 request" only

2014-10-12 - 2014-10-15: Domaincontrol removed the firewall blocking EDNS version 1 and EDNS flags.

"Percentage of responding servers that responded to a plain EDNS(1) request" only

Response failures in the above test are sometime due to the query type being DNSKEY.

"Percentage of responding servers that responded to a plain EDNS(0) request requiring truncation" only

"Percentage of responding servers that responded to a EDNS(0) request with a unknown option" only

2014-10-12 - 2014-10-15: Domaincontrol removed the firewall blocking EDNS version 1 and EDNS flags.

"Percentage of responding servers that responded to a EDNS(1) request with a unknown option" only

2014-10-12 - 2014-10-15: Domaincontrol removed the firewall blocking EDNS version 1 and EDNS flags.

"Percentage of responding servers that responded to a EDNS(0) request with a unknown flags" only

"EDNS Aware Root and TLD Servers" only

"EDNS Aware Root and TLD Servers by IP Family" only

"Root and TLD Servers Response Rates" only

"Root and TLD Servers Response Rates by IP Family" only

"Root and TLD EDNS(0) Failure Reasons" only

"Root and TLD EDNS(1) Failure Reasons" only

"Root and TLD EDNS(0) Unknown Option Failure Reasons" only

"Root and TLD EDNS(1) Unknown Option Failure Reasons" only

2014-09-14: operators returning unknown flags informed.

"Root and TLD EDNS(0) Unknown Flags Failure Reasons" only

Timeouts in the above test can be due to fragmented IP packets being filtered.

2014-09-16: all tld operators with timeouts from what appear to be fragmentation issues informed.

"Root and TLD EDNS(0) DO=1 Failure Reasons" only

The timeout and notimp failures above are most likely due to mishandling of DNSKEY requests rather than EDNS.

"Root and TLD EDNS(0) Truncated Respone Failure Reasons" only

EDNS(0) all EDNS queries have timeout and there was a response to the plain DNS query
EDNS(1) only the two EDNS version 1 queries timeout
EDNS(1) + FLAGS the two EDNS version 1 queries timeout as well as the unknown EDNS flags query

"Root and TLD Firewalls by Type" only

"EDNS Aware Alexa .GOV Servers" only

"EDNS Aware Alexa .GOV Servers by IP Family" only

"Alexa .GOV Servers Response Rates" only

"Alexa .GOV Servers Response Rates by IP Family" only

"Alexa .GOV Servers EDNS(0) Failure Reasons" only

"Alexa .GOV Servers EDNS(1) Failure Reasons" only

"Alexa .GOV Servers EDNS(0) Unknown Option Failure Reasons" only

"Alexa .GOV Servers EDNS(1) Unknown Option Failure Reasons" only

"Alexa .GOV Servers EDNS(0) Unknown Flags Failure Reasons" only

Timeouts in the above test can be due to fragmented IP packets being filtered.

"Alexa .GOV Servers EDNS(0) DO=1 Failure Reasons" only

The timeout and notimp failures above are most likely due to mishandling of DNSKEY requests rather than EDNS.

"Alexa .GOV Servers EDNS(0) Truncated Respone Failure Reasons" only

EDNS(0) all EDNS queries have timeout and there was a response to the plain DNS query
EDNS(1) only the two EDNS version 1 queries timeout
EDNS(1) + FLAGS the two EDNS version 1 queries timeout as well as the unknown EDNS flags query

"Alexa .GOV Servers Firewalls by Type" only

"EDNS Aware Alexa .AU Servers" only

"EDNS Aware Alexa .AU Servers by IP Family" only

2014-10-12 - 2014-10-15: Domaincontrol removed the firewall blocking EDNS version 1 and EDNS flags.

"Alexa .AU Servers Response Rates" only

2014-10-12 - 2014-10-15: Domaincontrol removed the firewall blocking EDNS version 1 and EDNS flags.

"Alexa .AU Servers Response Rates by IP Family" only

"Alexa .AU Servers EDNS(0) Failure Reasons" only

"Alexa .AU Servers EDNS(1) Failure Reasons" only

"Alexa .AU Servers EDNS(0) Unknown Option Failure Reasons" only

"Alexa .AU Servers EDNS(1) Unknown Option Failure Reasons" only

2014-10-12 - 2014-10-15: Domaincontrol removed the firewall blocking EDNS version 1 and EDNS flags.

"Alexa .AU Servers EDNS(0) Unknown Flags Failure Reasons" only

Timeouts in the above test can be due to fragmented IP packets being filtered.

"Alexa .AU Servers EDNS(0) DO=1 Failure Reasons" only

The timeout and notimp failures above are most likely due to mishandling of DNSKEY requests rather than EDNS.

"Alexa .AU Servers EDNS(0) Truncated Respone Failure Reasons" only

EDNS(0) all EDNS queries have timeout and there was a response to the plain DNS query
EDNS(1) only the two EDNS version 1 queries timeout
EDNS(1) + FLAGS the two EDNS version 1 queries timeout as well as the unknown EDNS flags query

"Alexa .AU Servers Firewalls by Type" only

"EDNS Aware Alexa Top 1000 Servers" only

"EDNS Aware Alexa Top 1000 Servers by IP Family" only

"Alexa Top 1000 Servers Response Rates" only

"Alexa Top 1000 Servers Response Rates by IP Family" only

"Alexa Top 1000 Servers EDNS(0) Failure Reasons" only

"Alexa Top 1000 Servers EDNS(1) Failure Reasons" only

"Alexa Top 1000 Servers EDNS(0) Unknown Option Failure Reasons" only

"Alexa Top 1000 Servers EDNS(1) Unknown Option Failure Reasons" only

"Alexa Top 1000 Servers EDNS(0) Unknown Flags Failure Reasons" only

Timeouts in the above test can be due to fragmented IP packets being filtered.

"Alexa Top 1000 Servers EDNS(0) DO=1 Failure Reasons" only

The timeout and notimp failures above are most likely due to mishandling of DNSKEY requests rather than EDNS.

"Alexa Top 1000 Servers EDNS(0) Truncated Respone Failure Reasons" only

EDNS(0) all EDNS queries have timeout and there was a response to the plain DNS query
EDNS(1) only the two EDNS version 1 queries timeout
EDNS(1) + FLAGS the two EDNS version 1 queries timeout as well as the unknown EDNS flags query

"Alexa Top 1000 Servers Firewalls by Type" only

"EDNS Aware Alexa Bottom 1000 Servers" only

"EDNS Aware Alexa Bottom 1000 Servers by IP Family" only

2014-10-12 - 2014-10-15: Domaincontrol removed the firewall blocking EDNS version 1 and EDNS flags.

"Alexa Bottom 1000 Servers Response Rates" only

2014-10-12 - 2014-10-15: Domaincontrol removed the firewall blocking EDNS version 1 and EDNS flags.

"Alexa Bottom 1000 Servers Response Rates by IP Family" only

"Alexa Bottom 1000 Servers EDNS(0) Failure Reasons" only

2014-10-12 - 2014-10-15: Domaincontrol removed the firewall blocking EDNS version 1 and EDNS flags.

"Alexa Bottom 1000 Servers EDNS(1) Failure Reasons" only

"Alexa Bottom 1000 Servers EDNS(0) Unknown Option Failure Reasons" only

"Alexa Bottom 1000 Servers EDNS(1) Unknown Option Failure Reasons" only

2014-10-12 - 2014-10-15: Domaincontrol removed the firewall blocking EDNS version 1 and EDNS flags.

"Alexa Bottom 1000 Servers EDNS(0) Unknown Flags Failure Reasons" only

Timeouts in the above test can be due to fragmented IP packets being filtered.

"Alexa Bottom 1000 Servers EDNS(0) DO=1 Failure Reasons" only

The timeout and notimp failures above are most likely due to mishandling of DNSKEY requests rather than EDNS.

"Alexa Bottom 1000 Servers EDNS(0) Truncated Respone Failure Reasons" only

EDNS(0) all EDNS queries have timeout and there was a response to the plain DNS query
EDNS(1) only the two EDNS version 1 queries timeout
EDNS(1) + FLAGS the two EDNS version 1 queries timeout as well as the unknown EDNS flags query

2014-10-12 - 2014-10-15: Domaincontrol removed the firewall blocking EDNS version 1 and EDNS flags.

"Alexa Bottom 1000 Servers Firewalls by Type" only