DNSSEC metrics: the state of the art and recommendations for the future

The purpose of DNSSEC metrics

DNSSEC metrics help us to identify where qualitative and quantitative improvements can be made. Measured data also enables us to see how effective the measures taken by the community have been, and to identify obstacles to further progress.

On behalf of ICANN and in partnership with NLnet Labs, we investigated how the DNS community measures the implementation and deployment of DNSSEC. The resulting end report has now been published, identifying more than 60 different attributes and techniques previously used by the community.

Our report also makes a number of recommendations to ICANN, registries and the metrics community, aimed at increasing the focus on 3 key aspects of DNSSEC deployment: the impact of DNSSEC, the quality of DNSSEC implementations, and the preparedness of the DNS ecosystem for the challenges of the future.

Those 3 aspects are considered in turn below. We also describe the challenges associated with measuring DNSSEC deployment, and explain their influence on our measurements.

Recommendation 1: Focus on impact

Discussions with the DNS community led us to conclude that, while the number of signed domain names and the number of validating resolvers are very important, the number of DNSSEC-secured DNS transactions is more important still.

Our first recommendation is therefore that greater emphasis should be placed on the global volume of DNS queries for signed domain names, and the number of such queries that are actually validated. For example, while it is important that more than 50 per cent of all .nl domain names are signed, a high proportion of transactions will remain insecure if the signed domain names generate little traffic, or if most end users are not using validating resolvers.

Measuring secured transactions is not straightforward, because it requires direct insight into the traffic handled by resolvers. Nevertheless, we believe that an initiative such as Identifier Technology Health Indicators (ITHI) may offer a solution. ITHI is an ICANN initiative and software product, which enables resolvers to conveniently share information about DNS traffic with a wider audience, without compromising privacy.

We therefore propose that the ITHI program is upgraded to support the sharing of DNSSEC data, and that its rollout by resolver operators is encouraged.

Recommendation 2: Quality not quantity

Our second recommendation is that insight into how operators implement DNSSEC should be improved. Flawed implementation of DNSSEC implies reduced security benefit, thus undermining general trust in DNSSEC.

One example of flawed implementation is enabling DNSSEC for a domain name, but configuring it to use an insecure algorithm such as RSA SHA-1. Focusing entirely on how many domain names are signed (quantitative data) means disregarding important considerations such as the level of security actually provided (qualitative data). A domain name with a signature based on the insecure RSA-SHA-1 algorithm remains potentially vulnerable.

Another relevant example is key rollovers, where domain names switch their cryptographic signing key. Various researchers have previously observed that key rollovers are often not performed correctly. In the worst cases, the domain names involved are briefly rendered unreachable. That creates issues for resolver operators whose users are unhappy about being unable to reach the domains in question.

We therefore recommend placing more emphasis on the algorithms used, on how recursive resolvers and authoritative name servers are configured (see also the DNS Flag Days), and on support for DNS extensions such as DNS cookies, which can mitigate the abuse of DNSSEC in DDoS attacks. At SIDN, for example, we've made the financial incentives offered to .nl registrars payable only in respect of .nl domain names signed using secure, modern algorithms.

Recommendation 3: Think ahead

The DNS landscape is constantly changing. As a result, DNSSEC algorithms that are secure today may not afford adequate security in the future. For example, quantum computers may be able to easily crack some present-day algorithms. While numerous scientific challenges remain to be overcome before quantum computers are widely available, we believe that the community should already be considering how flexible and future-proof DNSSEC is.

Against that backdrop, we recommend measuring how many domain names have already switched algorithms. That information would be instructive, because such domain names are likely to be more capable of quickly switching again in the future, e.g. to a quantum-secure algorithm.

It is also important to ensure that the DNS is able to handle large DNS messages, because many quantum-secure algorithms currently undergoing evaluation use very large keys and/or signatures. We accordingly recommend continuously monitoring how reliably large DNS messages can be exchanged. TCP and newer transport protocols such as QUIC can play an important role in that context.

DNSSEC metrics: harder than you might think

Unfortunately, measuring the recommended variables isn't as straightforward as you might think. The reason being that DNSSEC is used on '2 sides' of the DNS: with the domain name and on the recursive resolvers that look up domain names. The most obvious and common approach is therefore to test whether domain names have DNSSEC signatures and whether recursive resolvers validate those signatures.

However, not all domain names are known to everyone. While the root zone is publicly available, the zones of some top-level domains and all lower-level domains are not. Consequently, researchers who want to find out how many domain names are DNSSEC-enabled have to ask the operators of the domains in question for access to their zones. Without such access, it's impossible to obtain a complete picture of the extent of DNSSEC deployment.

Measuring DNSSEC validation by resolvers involves even greater challenges. For security reasons, many resolvers are accessible only from certain networks, such as the network of the relevant internet service provider or the relevant company network. Any researcher without a vantage point on a permitted network will find it hard to establish whether such a resolver performs validation. The reason being that the best way to test for DNSSEC validation support is by sending active DNS queries, where a machine seeks to resolve a DNSSEC-enabled domain name with the aid of the investigated resolver.

A further complication is that, even if the researcher has a vantage point on a permitted network, the research findings may not reflect reality. For example, the investigated resolver may not perform validation itself, but forward queries to another resolver that does. An external researcher will normally find it hard to distinguish such resolvers from those that don't provide for validation at all.

Our report therefore considers which techniques are best for measuring certain metrics. However, there is no perfect solution. A researcher must always weigh up the number of DNS components measured, the cost and the reproducibility, with a view to striking the best possible balance.

For example, the RIPE Atlas platform supports reproducible resolver testing, but covers only certain networks. On the other hand, measurement by means of online advertising, as performed by APNIC and others, yields information about a much greater number of resolvers, but is expensive and lacks transparency.

Our work in the field of DNSSEC metrics

SIDN Labs and NLnet Labs have considerable experience with DNSSEC metrics. For example, we have previously investigated the time required to roll out new DNSSEC algorithms, and which quantum-secure algorithms may make suitable replacements for current DNSSEC algorithms.

We also support other researchers who are studying the DNS and DNSSEC. For example, we work closely with the University of Twente and the OpenINTEL project, as well as sharing information with dnssec-tools.org.

Finally, as a service to everyone interested in the latest developments involving DNSSEC in the .nl domain, we publish live and daily statistics on stats.sidnlabs.nl.

Give us your feedback!

We would like to hear what you think of our report. What do you believe the community should focus on in the future? Do you agree with our recommendations? Have we overlooked anything? And how and where should DNSSEC metrics be collected? Please send your feedback to moritz.muller@sidn.nl.