Testing EDNS Compatibility with dig
- 24 Jan 2019
- 4 Minutes to read
-
Contributors
-
Print
-
DarkLight
-
PDF
Testing EDNS Compatibility with dig
- Updated on 24 Jan 2019
- 4 Minutes to read
-
Contributors
-
Print
-
DarkLight
-
PDF
Article Summary
Share feedback
Thanks for sharing your feedback!
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.