Contents x
Testing EDNS Compatibility with dig
  • 24 Jan 2019
  • 4 Minutes to read
  • Contributors
  • Print
  • Dark
    Light
  • PDF
Contents

Testing EDNS Compatibility with dig

  • Updated on 24 Jan 2019
  • 4 Minutes to read
  • Contributors
  • Print
  • Dark
    Light
  • PDF
Article summary

Checking EDNS Compatibility with DIG

The ednscomp.isc.org site uses a modified version of DiG to run multiple tests in series. This is available for download from https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing.
You can also use the dig included in the BIND distribution and run multiple queries yourself to check a suspicious domain.

Ideally you need to install dig from BIND 9.11.0 or newer
+ednsopt and +ednsflags require dig from BIND 9.11.0 or later. Current versions of BIND can be downloaded from isc.org/downloads/ . It is possible to build BIND without installing it on the host machine (use only make (not make install) and then extract the dig executable from the build directory: ~/bin/dig/dig
Why you might prefer to use dig or a local copy of the EDNS compliance tester
When using the tool at 'ednscomp.isc.org' to test your domain, all queries are being sent from the site hosting this tool. We have observed some false positives due to timeouts that are caused, not by non-compliance but by authoritative server rate limiting. This is most likely to happen where zones are hosted and where many of their customers are testing for EDNS compliance at the same time. Directly testing your zone's EDNS compatibility using dig or your own local copy of the tool means that you will be sending queries from your own local IP addresses which should avoid your test queries being rate-limited
Make sure that you test your zones as your external consumers will see them
When you are using dig or a local copy of the EDNS compliance tester, the location from which you are testing may influence the result - for example if you are testing from within your own company infrastructure, you may be testing an internal-only version of your zone and also your test queries may not be traversing the same firewalls or load balancers as those sent by external clients

Testing Methodology

The level of EDNS compliance of a authoritative server is relatively easy to determine with a few simple DNS queries. In the example queries below, replace "zone" with the name of the zone to be tested. Replace "server" with the name or IP address of the server the query is directed to.

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

A compliant system will give you the expected responses shown below:

Plain DNS

dig +norec +noedns soa zone @server

expect: SOA record in the ANSWER section of the query response
expect: status is NOERROR

Plain EDNS

dig +norec +edns=0 soa zone @server

expect: SOA record in the ANSWER section of the query response
expect: status is NOERROR
expect: OPT record with EDNS version set to 0
See RFC6891

EDNS - Unknown Version

dig +norec +edns=100 +noednsneg soa zone @server

expect: status is BADVERS
expect: OPT record with EDNS version set to 0
expect: not to see SOA record in the ANSWER section of the query response
See RFC6891, 6.1.3. OPT Record TTL Field Use

EDNS - Unknown Option

dig +norec +ednsopt=100 soa zone @server

expect: SOA record in the ANSWER section of the query response
expect: status is NOERROR
expect: OPT record with EDNS version set to 0
expect: that the EDNS option will not be present in response
See RFC6891, 6.1.2 Wire Format
+ednsopt and +ednsflags require BIND 9.11.0 or later.

EDNS - Unknown Flag

dig +norec +ednsflags=0x80 soa zone @server

expect: SOA record in the ANSWER section of the query response
expect: status is NOERROR
expect: OPT record with EDNS version set to 0
expect: Z bits to be clear in response
See RFC6891, 6.1.4 Flags
_+ednsopt and +ednsflags require BIND 9.11.0 or later. _

EDNS - DO=1 (DNSSEC)

dig +norec +dnssec soa zone @server

expect: SOA record in the ANSWER section of the query response
expect: status is NOERROR
expect: OPT record with EDNS version set to 0
expect: DO flag set in response if RRSIG is present in response
See RFC3225

EDNS - Truncated Response

dig +norec +dnssec +bufsize=512 +ignore dnskey zone @server

expect: status is NOERROR
expect: OPT record with EDNS version set to 0

This is an opportunistic test only
We can't test a zone for the ability to indicate that an answer was truncated (setting the TC flag in a response) unless we know which query to send it that will definitely result in a large response. If you are testing your own zone, you know what RRsets you have in it, so may be able to create a better test query. The reason our test uses DNSKEY and +dnssec is that there is a very good chance that the query response for a DNSSEC-signed zone will exceed 512 bytes

See RFC6891, 7. Transport Considerations

EDNS - Unknown Version with Unknown Option

dig +norec +edns=100 +noednsneg +ednsopt=100 soa zone @server

expect: status is BADVERS
expect: OPT record with EDNS version set to 0
expect: not to see SOA in the ANSWER section of the query response
expect: that the EDNS option will not be present in response
See RFC6891

The above expectations are based on the following preconditions:

  • Only EDNS version 0 is defined currently.
  • EDNS option 100 is not yet defined.
  • The only EDNS flag defined is DNSSEC OK (DO).
  • When EDNS version 1 is defined we expect to see:
    OPT record with version set to 0 or 1 (this is because EDNS compliance includes indicating which version the server supports in a server response).

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

What's Next

Cookie consent

We use our own and third-party cookies to understand how you interact with our Knowledgebase. This helps us show you more relevant content and ads based on your browsing and navigation history.