You are here: Home > Publications > RIPE Labs > Maciej Andzinski > Support for Elliptic Curve Cryptography (ECC) in DNS Resolvers as Seen by RIPE Atlas

Support for Elliptic Curve Cryptography (ECC) in DNS Resolvers as Seen by RIPE Atlas

Maciej Andzinski — 21 Mar 2016
The Elliptic Curve Cryptography (ECC) is becoming increasingly popular in DNSSEC. While it is sometimes considered to be a remedy for the low DNSSEC adoption rate, there is also a lot of controversy around it. One of the main concerns is that DNSSEC-validating resolvers don't always make use of ECC. We used RIPE Atlas to measure the support for ECC in DNS resolvers.

Methodology

Each RIPE Atlas probe with system-ipv4-works and system-resolves-a-correctly tags was used to query its local resolver(s) for specifically prepared DNSSEC-signed domain names secured using various DS and DNSSEC algorithms. The following algorithms were taken into consideration:

For DNSKEY RR * :  

  • 8 (RSA/SHA-256)
  • 12 (ECC GOST R 34.10-2001)
  • 13 (ECDSA-P256/SHA-256)
  • 14  (ECDSA-P256/SHA-384)

For DS RR * :

  • 2 (SHA-256)
  • 3 (GOST R 34.11-94)
  • 4 (SHA-384)

A DNS zone was created f or each combination of considered DS and DNSKEY algorithms. It was signed using the appropriate DNSKEY algorithm and a specific DS record was generated and placed in the parent zone. Moreover, for each combination above, a zone with bogus DNSSEC delegation was forged (the key digest in DS record was malformed). For instance, there was a pair of zones  for DNSKEY algorithm number 13 and DS digest algorithm number 2:

  • key13-ds2-nsec3.lab.dnssec.pl.
  • key13-ds2-nsec3-bogus.lab.dnssec.pl.

Such a pair of zones existed for each of the twelve combinations above, thus there were 24 unique domain names.

A properly functioning DNSSEC-validating resolver was expected to answer with the AD bit set for a query for a domain name with a correct DNSSEC delegation and with a SERVFAIL RCODE in case of a bogus DNSSEC delegation. We then investigated the behaviour of resolvers in these two scenarios.

Due to the daily expense limit of 1M credits, the measurements were carried out over several days. Each day the following actions were performed:

  1. Get the list of RIPE Atlas probes
  2. From that list, select 2,000 "unused" (see 6.), online probes with system-ipv4-works  and system-resolves-a-correctly  tags
  3. Split the set of those selected 2,000 probes into the subsets of 500 probes
  4. For each subset of 500 probes:
    1. Create the "initial measurement " (1)
    2. Wait 120 seconds
    3.  Create the "actual measurements" (2)
  5. Wait for the completion of these measurements and get the results
  6. Mark the probes selected in 2. as "used"

(Of course, as 500 and 2,000 didn't divide into the total number of eligible probes, the size of "last set" was actually smaller.)

Results

The data we analysed was collected at the end of December 2015 and in January 2016. RIPE Atlas yielded results from 8,316 probes distributed over 3,085 autonomous systems in 175 countries (see Figure 1 below).

"Distribution of RIPE Atlas probes involved in the measurements.

Figure 1: Number of RIPE Atlas probes involved in the measurement

It was observed that elliptic curve cryptography was not as widely supported as RSA. However, the differences between the RSA and ECDSA support rates were not very big. In contrast, resolvers making use of the Russian ECC GOST algorithm were not very common. Similar findings were noted for DS digest algorithms. SHA-384 was, unlike GOST R 34.11-94, almost as frequently supported as SHA-256.  The percentage of answers in relation to the zone's DNSSEC delegation for various combinations of DS and DNSSEC algorithms are shown in Figure 2 below.  

Answer statistics in relation to zone's DNSSEC delegation for various combinations of DS and DNSKEY algorithms.

Figure 2: Percentage of answers received

The study also showed that DNSSEC was more popular in the IPv6 Internet and that the less common algorithms were more frequently supported by IPv6 resolvers.  The percentages of answers with the AD bit set for various combinations of DS and DNSSEC algorithms are shown in Figure 3 below.  

Answers with AD bit set in relation to resolver address family for various combinations of DS and DNSKEY algorithms.

Figure 3: Percentage of answers with the AD bit set

The JSON file with measurements' IDs can be downloaded   here .

Footnotes:

1. "initial measurement" - a one-off DNS measurement with use_probe_resolver=TRUE ; the DNS query was for "test.lab.dnssec.pl. IN TXT". Such a query was issued in order to diminish the overhead of the domain name resolution process in a DNS resolver with no data about the parent   zones  (i.e.: ., pl., dnssec.pl., lab.dnssec.pl.)  in the cache (however, it could have had no effect on load-balanced resolvers)
2. "actual measurements" - one-off DNS measurements with use_probe_resolver=TRUE ; there was a separate measurement for each of 24 considered domain names (i.e.: DNS queries for "test.key13-ds2-nsec3.lab.dnssec.pl" IN TXT., "test.key14-ds2-nsec3.lab.dnssec.pl IN TXT"., ...).  The JSON template used to create the measurements can be downloaded  here .


This is the summary of the "ECC support in DNS resolvers as seen by RIPE Atlas" paper by Maciej Andziński, NASK (.pl registry). To find out more about the study, please read the full article available on the dns.pl website: https://www.dns.pl/dnssec/ecc_support_in_dns_resolvers.pdf


0 Comments

Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.