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.

• Root and TLD servers
• DNS servers for Alexa Top 1000 sites
• DNS servers for Alexa Bottom 1000 of the top 1M sites
• GOV servers in the Alexa Top 1M sites
• AU servers in the Alexa Top 1M sites

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.

• dig +norec +noedns soa zone @server
• dig +norec +edns=0 soa zone @server
• dig +norec +edns=100 +noednsneg soa zone @server
• dig +norec +ednsopt=100 soa zone @server
• dig +norec +ednsflags=0x80 soa zone @server
• dig +norec +dnssec soa zone @server
• dig +norec +dnssec +bufsize=512 +ignore dnskey zone @server
• dig +norec +edns=100 +noednsneg +ednsopt=100 soa zone @server

EDNS faults detected

• OPT only returned when DO=1 is present in the request
• BADVER not returned to EDNS (1)
• NOTIMP returned when a EDNS option is present
• FORMERR returned when a EDNS option is present
• BADVERS returned when a EDNS option is present
• NOTIMP returned when a EDNS Z flag is present
• FORMERR returned when a EDNS Z flag is present
• BADVERS returned when a EDNS Z flag is present
• EDNS option echoed back
• OPT not returned in truncated response
• EDNS (1) queries being dropped
• EDNS queries with a Z bit being dropped
• EDNS Z bits in queries echoed back
• TCP response size limited to EDNS UPD response size
• Truncated UDP response when send when response will not fit
• Fragmented responses being blocked
• DO=1 not returned by DNSSEC aware servers

What we expect to see:

• Plain DNS

  dig +norec +noedns soa zone @server
  expect: SOA
  expect: NOERROR

• Plain EDNS

  dig +norec +edns=0 soa zone @server
  expect: SOA
  expect: NOERROR
  expect: OPT record with version set to 0
  See RFC6891

• EDNS - Unknown Version

  dig +norec +edns=100 +noednsneg soa zone @server
  expect: BADVERS
  expect: OPT record with version set to 0
  expect: not to see SOA
  See RFC6891, 6.1.3. OPT Record TTL Field Use

• EDNS - Unknown Option

  dig +norec +ednsopt=100 soa zone @server [1]
  expect: SOA
  expect: NOERROR
  expect: OPT record with version set to 0
  expect: that the option will not be present in response
  See RFC6891, 6.1.2 Wire Format

• EDNS - Unknown Flag

  dig +norec +ednsflags=0x80 soa zone @server [1]
  expect: SOA
  expect: NOERROR
  expect: OPT record with version set to 0
  expect: Z bits to be clear in response
  See RFC6891, 6.1.4 Flags

• EDNS - DO=1 (DNSSEC)

  dig +norec +dnssec soa zone @server
  expect: SOA
  expect: NOERROR
  expect: OPT record with version set to 0
  expect: DO flag in response if RRSIG is present in response
  See RFC3225

• EDNS - Truncated Response

  dig +norec +dnssec +bufsize=512 +ignore dnskey zone @server
  expect: NOERROR
  expect: OPT record with version set to 0
  See RFC6891, 7. Transport Considerations

• EDNS - Unknown Version with Unknown Option

  dig +norec +edns=100 +noednsneg +ednsopt=100 soa zone @server
  expect: BADVERS
  expect: OPT record with version set to 0
  expect: not to see SOA
  expect: that the option will not be present in response
  See RFC6891

The above expectations are based on the following preconditions.

• Only EDNS version 0 is defined.
• EDNS option 100 is not defined.
• the only EDNS flag defined in DNSSEC OK (DO).

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?

• We need to identify servers that are broken.
• From this we get the products that are broken.
• The vendors of the products need to be informed and get the products fixed.
• We then need to get the fixed products deployed.

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

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.