EDNS Compliance Report: 2024-03-28T00:17:52Z

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://ednscomp.isc.org/compliance/summary.html

[1] +ednsopt and +ednsflags require BIND 9.11.0 or later. BIND 9.11.0 can be found on the ISC.ORG web site.

Other EDNS Compliance Reports

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.
2015-05-20: Amazon removed the the firewall blocking EDNS version 1 queries to their *.CO.UK servers.

"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.
2015-05-20: Amazon removed the the firewall blocking EDNS version 1 queries to their *.CO.UK servers.

"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.
2015-05-20: Amazon removed the the firewall blocking EDNS version 1 queries to their *.CO.UK servers.

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

EDNS Compliance by dataset

EDNS Aware Root and TLD Servers

EDNS Aware Umbrella .GOV Servers

EDNS Aware Umbrella .AU Servers

EDNS Aware Umbrella Top 1000 Servers

EDNS Aware Umbrella Bottom 1000 Servers

EDNS Aware .GOV Servers


© 2024 Internet Systems Consortium