After reading the interesting post by Stéphane Bortzmeyer on RIPE Labs (How Many RIPE Atlas Probes Can Resolve IPv6-only Domain Names?) I wondered how many RIPE Atlas probes used DNSSEC aware resolvers, so I tried to setup some measures and some comparisons.
As also expressed in the aforementioned post, it should be noted that RIPE Atlas probes can’t be used to represent general behaviors of Internet users; they are excellent “toys” in the hands of network engineers but nobody can ensure that their configuration reflects the one used in production environments by users or by servers or by applications.
Measurements
- 6 measurements requested (all with a 1300 bytes size for reply buffer):
- simple query (#1421265);
- simple query over TCP (#1421266);
- DNSSEC OK (DO flag) query against a signed zone (#1421267);
- DNSSEC OK (DO flag) query against a signed zone over TCP (#1421268);
- simple query against a broken zone (#1421269);
- simple query of non-existent record on a signed zone (#1421270);
- 500 probes requested for the measurements, always the same;
For the signed zone I used ripe.net, while the choice for the broken zone fell on dnssec-failed.org. Parsing of DNS replies is done using the dnspython library (http://www.dnspython.org/).
498 probes are allocated to the first measure: 65 don’t reply at all or return a SERVFAIL/REFUSED error code, 11 are discarded because of parsing problems in the response while 422 of them return a valid response for the simple DNS query; these 422 probes are then used as the basis for all the comparisons that follow.
DNSSEC OK queries against a signed zone
Almost all the responding probes (415 over 422) return a valid answer when queried using the DNSSEC OK (DO) flag (6 don’t reply and 1 is discarded due to parsing problems): of these, 137 perform validation (AD flag), 153 only include RRSIG records in the answer (acting like a proxy) and 125 simply ignore any DNSSEC related information and strip any RRSIG from the answer.
Broken zone behavior
From the 137 probes whose resolvers perform validation, only 115 return the expected SERVFAIL error code when queried against the broken zone; 11 return FORMERR, 10 don’t reply at all while 1 returns a NOERROR, including the IP address of the broken record too (but, as we will see later, it also resolves an inexistent record)!
131 of the 153 proxies return NOERROR along with the IP address of the invalid record while 20 return SERVFAIL or FORMERR error codes: are their resolvers using validating forwarders which block their queries? Two don’t reply at all.
Nonexistent record behavior
134 of the 137 validating resolvers also authenticate the denial of existence of not existent record (doesnotexist.ripe.net), by providing AD answers and NSEC records.
From the proxy group of 153 probes, 148 return the NSEC records, confirming their proxy-like function.
100 of the 125 DNSSEC-unaware resolvers return a NXDOMAIN error code, 4 of them also include an NSEC record (even if they didn’t include RRSIG in the correct query); from the 25 resolvers which don’t answer with NXDOMAIN, 18 return a NOERROR: half of them are from the OpenDNS project while the other half use a private IP address (maybe also pointed to OpenDNS servers?). OpenDNS is known to implement a domain typo correction service that resolves invalid hosts and redirects users to a web search page. The remaining 7 probes don’t answer or encounter parsing problems.
TCP
Only 359 probes over the 422 total seem to use resolvers with TCP support; 349 of them also support DNSSEC OK queries: 126 validate data, 126 just proxy RRSIG records and 97 ignore or strip any DNSSEC related information.
Validating resolvers vs proxies
When probes with validating resolvers are compared with those whose resolver blocks broken zones and those that provide denial of existence authentication the result is 114 probes using fully DNSSEC compliant and validating resolvers, 107 of which also supporting TCP.
For what concerns the remaining probes, 145 seem to use resolvers which act like a proxy, providing RRSIG/NSEC records but avoiding validation; 123 of them also support TCP.
Who are they?
12 of the 114 validating resolvers are on private IP addresses; from the remaining pool of 102 public resolvers, 64 are from the Google Public DNS project, 10 are from the Comcast DNS and 28 are “privately managed” server.
Conclusions?
Almost two-thirds of the involved probes use DNS resolvers which allow them to perform validation (proxies) or which perform validation on their own (validating resolvers), largely thanks to local configurations based on open public projects implementing DNSSEC.
If we exclude from the computation the number of probes using resolvers from “big DNS projects”, the number of probes that use “private” validating resolvers represents only a small subset of the total.
Moreover, 15% of probes can’t use their resolvers on TCP connection but only via UDP.
Latest posts by Pier Carlo Chiodi (see all)
- Good MANRS for IXPs route servers made easier - 11 December 2020
- Route server feature-rich and automatic configuration - 13 February 2017
- Large BGP Communities playground - 15 September 2016
Leave a Reply