State of DNSSEC Deployment 2016

This report provides a snapshot of the state of deployment of DNSSEC as of the end of 2016.

Please download the full report to view all of the information, charts and conclusions.

Highlights:

Signing of domains with DNSSEC:

o 89% of top-level domains (TLDs) zones signed.

• ~47% of country-code TLDs (ccTLDs) signed.

o Second-level domains (SLDs) vary widely:

• Over 2.5 million .nl domains signed (~45%) (Netherlands). [1]
• ~88% of measured zones in .gov are signed.
• Over 50% of .cz (Czech Republic) domains signed.
• ~24% of .br domains signed (Brazil). [2]
• While only about 0.5% of zones in .com are signed, that percentage represents ~600,000 zones.

o The major DNS authoritative server software and libraries support DNSSEC and have several years of deployment experience.
o Management tools have started to come online to assist deployment, e.g., key deployment and rollover.
o Encryption algorithms and key lengths

• The overwhelming majority of TLDs utilize RSA/SHA-256 with 2048 bit keys for the Key Signing Key (KSK) and 1024 bit keys for the Zone Signing Key (ZSK).
• A significant number of zones measured still utilize SHA-1.
• Utilization of ECDSA is at 5% and growing.

o In 2016, the Zone Signing Key (ZSK) for the Root Zone was successfully migrated to a 2048-bit RSA key.
o 2017 will be an important year for DNSSEC with the planned rollover of the Key Signing Key (KSK) in the Root Zone of DNS.

Validation

o All major DNS recursive resolvers support DNSSEC validation.
o ~80% of clients request DNSSEC digital signature records in their DNS queries (per APNIC research).
o 26% of end user environments use DNSSEC-validating resolvers, but also pass queries to non-validating resolvers if validation results in a validation failure.
o Although only ~14% of clients globally exclusively use DNSSEC-validating DNS resolvers, the numbers vary greatly between regions and countries.

• Over 50% of clients in most Scandinavian countries exclusively use DNSSEC-validating DNS resolvers.

o A large ISP enabling DNSSEC validation on its recursive resolvers can have a big impact on a country’s utilization numbers (e.g. Comcast in USA, Claro in Brazil).
o Google Public DNS (PDNS) service support for DNSSEC validation makes validation available globally (where allowed by law).

Applications/Services

o Libraries, APIs and tools are becoming available to enable DNSSEC use by application developers.
o DANE

• Utilization of DANE is relatively low, but growing.
• Libraries, APIs and tools are becoming available.
• Most prominent utilization of DANE is securing email transfers between email servers, led by German email providers.

In summary, deployment of DNSSEC has made substantial progress since the root was signed in 2010. Most of the Top Level Domains (TLDs) have now been signed (with some challenges in ccTLDs, especially in developing countries). The major DNS servers and resolvers now ship with DNSSEC capability, and tools assisting DNSSEC operation are improving. New applications for DNSSEC, such as the use of DANE for securing email transfers, are gaining traction. While there are still challenges in deploying and supporting DNSSEC, the above factors point to continued growth.

1 Introduction

In the almost 20 years since the publication of RFC 2065, “Domain Name System Security Extensions” [ RFC2065 ] in January of 1997, the DNS security extensions (DNSSEC) have been implemented, tested, deployed and updated [ RFC4033 ][ RFC4034 ][ RFC4035 ]. New capabilities have been defined, such as the DNS-Based Authentication of Named Entities (DANE)[ RFC6394 ]. Like IPv6, DNSSEC deployment has faced challenges due to technology issues and lack of motivation. Operational deployment was very slow until Dan Kaminsky’s disclosure of a serious cache poisoning attack in 2008 [ KAMINSKYBUG ] stimulated renewed interest in DNSSEC. The signing of the root zone in 2010 provided a firm basis for DNSSEC deployment by enabling a chain of trust up to the DNS root. Since 2010, deployment of DNSSEC in the Top Level Domain (TLD) zones and Second Level Domains [SLD] has progressed.

The Internet Society (ISOC) launched its Deploy360 Programme in 2011 including its web portal supporting deployment of DNSSEC [3]. The Deploy360 Programme provides information on and links to training, tools, case studies and deployment statistics to assist and track the deployment of DNSSEC.

There are two main aspects of deployment of DNSSEC addressed in this report:

DNSSEC signing

o How many zones are signed using DNSSEC and have a chain of trust back to the DNS root?
o What algorithms and key sizes are supported?

DNSSEC validation

o What recursive resolvers support DNSSEC?
o How many clients are using DNSSEC-validating DNS resolvers?

With DANE, the Internet Engineering Task Force (IETF) has defined a way to use the chain of trust provided by DNSSEC in authenticating certificates used in Transport Layer Security (TLS, more commonly known by the historic name of Secure Socket Layer or “SSL”) [ RFC6698 ][RFC7671]. Section 4 looks at the state of deployment of DANE on the Internet. Similar to DNSSEC, deployment is viewed from two angles:

• Signing – how many sites provide TLSA records in DNS.
• Utilization – How many and what types of applications/services use TLSA records in establishing TLS Sessions.

Given the impact that the root Key Signing Key rollover has on the DNS, Section 5 provides a short discussion of the status of the current KSK rollover process.

Section 6 describes some of the main challenges to deployment including an overview of those facing migration to a new crypto algorithm (e.g., Elliptic Curve Digital Signature Algorithm (ECDSA)).

While deployment of DNSSEC has historically been slow, the signing of the root zone and most of the TLD zones, widespread support in DNS server and recursive resolver software, increasing availability of tools for deployment and new applications and services (e.g., DANE) have driven increased growth over the last 5 years.

2 State of DNSSEC Validation

Once a zone is cryptographically signed with a chain of trust to the root zone, including the requisite RRSIG, DNSKEY, NSEC/NSEC3 and DS records, DNS resolvers can use these records and public key cryptography to validate information returned in response to a DNS query. Because of the increased response size due to these additional records, the resolver also must be able to support the Extension Mechanisms for DNS (EDNS0)[ RFC6891 ].

Measuring the state of DNSSEC validation is qualitatively and quantitatively different than measuring the signed zones (e.g., TLDs). For signed zones, the relevant Resource Records are relatively static (modulo dynamic DNS), is in a relatively well-known location (authoritative name server) and the cases tend to be limited. For validation, there are multiple points of measurement (e.g., at DNS server, multiple levels of recursive resolvers, at client) with many failure modes. As examples, a recursive resolver might request DNSSEC RRs but not actually validate the response or a client might receive a SERVFAIL response from a validating recursive resolver and fall back to a non-validating secondary resolver. In addition, there can be multiple levels of recursive resolvers and forwarders, which can obscure where validation is being done.

2.1 Observed usage of DNSSEC validation

The best publicly available ongoing measurements on DNSSEC validation are currently being collected by APNIC. The APNIC statistics measure clients that exclusively use DNSSEC validating name resolution (either directly or via a validating recursive resolver)[ APNICM ]. Figure 1 illustrates the state of DNSSEC validation as measured by APNIC as of 18 December, 2016.

Figure 1 – Global State of DNSSEC Validation [4]

APNIC also keeps track of the percentage of clients that query Google’s Public DNS service (PDNS) [5]. Since Google PDNS supports DNSSEC validation, any client that uses the service will have access to DNSSEC validation. In some cases, ISPs point their customers to Google PDNS to use as DNS recursive resolvers instead of providing their own. As described in the DNSSEC Workshop in ICANN56, the effect can be seen in the relatively high usage of DNSSEC in central Africa which uses Google’s PDN services (e.g., 77% of clients in the Democratic Republic of the Congo utilize Google PDNS). [6]

As shown in Figure 1 and Table 1, support for DNSSEC validation is not distributed evenly across the regions. Deployment in Asia is only half that in Europe, Americas and Oceania (but makes up over half the samples taken). Within Europe, Scandinavian countries stand out in their native (non-Google PDNS) support for DNSSEC validation.

Figure 2 illustrates the global growth in DNSSEC validation since 2014, when APNIC started its measurements. These measurements indicate that ~14% of DNS queries currently support DNSSEC validation up from 8-9% support in 2014. As can be seen, growth in DNSSEC validation started to level off globally in 2016.

Growth in validation is not necessarily gradual on a per-country basis. The numbers can jump substantially based on a large ISP turning on DNSSEC validation in its customer-facing resolvers. For example, Figure 3 illustrates how DNSSEC validation in Brazil jumped approximately 10% when Claro turned on DNSSEC validation in its customer-facing resolvers in April-May 2015 [7]. Although occurring before APNIC started its measurements, Comcast in the US effected a similar jump in validation when it turned on DNSSEC validation for its ~18 million customers.

Figure 2 – Growth of DNSSEC Validation Globally [8] [9]

Table 1 – Regional DNSSEC Validation

Figure 3 – Use of DNSSEC Validation for Brazil [10]

In Figures 2 and 3, the y-axis represents the percentage of clients exclusively using validating resolvers. APNIC’s experiment also show a difference in numbers in how DNSSEC is deployed. While APNIC’s measurements found that ~80% of queries requested DNSSEC credentials, only 26% perform DNSSEC validation on the returned credentials and ~11% of the clients fall back to a non-validating resolver on receipt of a SERVFAIL response. This leaves the ~15% of clients that fully utilize DNSSEC validation (fail on SERVFAIL). [11]

2.2 Availability of DNSSEC validation in DNS resolver software

One of the complaints against DNSSEC has been the lack of availability of DNSSEC-capable resolvers. While this might have been true several years ago, there are currently many options for DNSSEC validation support. Table 2 provides a partial list of DNS resolvers or resolution services that support DNSSEC and Table 3 lists the availability of software libraries for developers needing to use DNSSEC queries.”

Table 2 – DNSSEC capable resolvers and resolution services

Table 3 – DNS Developer Libraries

3 State of DNSSEC Signing

The signing of DNS zones and associated chain of trust to the root is the heart of DNSSEC, enabling validation. This section does not address all corner cases (e.g., having a subset of RRsets signed, chain of trust not rooted in the DNS root zone). The hierarchical nature of the DNS carries over to DNSSEC where the chain of trust requires valid signing of zones from the target zone all the way up to the root. If a higher-level zone is not signed, then its child zones will not be able to establish a chain of trust even if they are signed.

For the purposes of this document, a zone is considered to be signed by DNSSEC if the following are true:

• In the zone:

o Existence of at least one DNSKEY RR for a ZSK and a KSK [12] for the zone.
o Existence of RRSIG RRs for the RRsets in the zone signed by one of the ZSKs.
o Existence of RRSIG Records for the DNSKEY RRset signed by the KSK if different keys are used for the ZSK and KSK function.

• In the parent zone:

o Existence of a DS Record for the zone’s KSK.
o Existence of an RRSIG for the DS Record for the zone signed by the ZSK of the parent zone.

• Chain of trust (DS RRs) to the DNS root signing key

In 2010, the DNS root zone was signed enabling a chain of trust anchored in the DNS root. This allowed TLD operators to start signing their zones and placing their DS Records in the root. This, in turn, enabled Second Level Domain operators to start signing their zones, and so on down the chain.

Starting in 2012, ICANN required applications for new generic TLDs (gTLDs) [13] to support DNSSEC from the start. ICANN also updated its Registrar Accreditation Agreement in 2013 to require registrars to allow customers to use DNSSEC (if supported by the underlying Registry). These actions enabled an increased number of zone operators to sign their zones with a chain of trust to the DNS root. Note that the 2012 requirement on new gTLDs to support DNSSEC does not apply to ccTLDs. Neither the 2012 nor the 2013 requirement apply to previous gTLDs or registrars operating under earlier agreements. This helps explain the jump in TLD zone signing in 2013 and the disparity between the gTLDs and ccTLDs in signing their zones. Although not required by the above agreements, the gTLDs created prior to 2012 have almost all signed their zones (two exceptions being .tel and .aero).

Signing of Second Level Domain (SLD) zones (and their child zones) is generally left up to the zone operator(s).

Section 3.1 provides the current status of signing TLDs including ccTLDs and gTLDs. Section 3.2 provides information on the status of Second Level Domains (SLDs).

3.1 Top-Level Domains

According to ICANN’s statistics, as of November, 2016 (see Table 4 ) 89% of all TLDs have signed their zones and have a Delegation Signer (DS) resource record (RR) in the DNS root. Another 1% have signed their zones but have not added a DS RR to the root, and 10% of TLDs have not signed their zones.

Breaking these numbers down further we can see that 100% of the current gTLDs are signed with a DS RR in the root, including all internationalized gTLDs. Based on the 2012 ICANN requirement on new gTLDs all future gTLDs should also be signed from the start.

The country-code TLDs (ccTLD) have the most room for improvement. As of November 2016 only 47% of ccTLDs are signed with a DS RR in the root zone. ICANN does not have any requirement on ccTLDs to sign their zones and due to national sovereignty concerns it is doubtful there will ever be such a requirement. Thus it is up to each ccTLD operator to determine if it will sign the zone for its country. The map in Figure 4 illustrates the status of DNSSEC signing of ccTLDs globally.

Table 4 – DNSSEC signed TLDs

Figure 4 – ccTLD DNSSEC Status on 2016-12-19 [15]

Figure 5 through Figure 7 show the growth in signing of TLDs since 2010 (ICANN statistics). They illustrate the rapid growth in gTLDs starting in 2013. The growth of signing of ccTLDs has been slow but steady.

Figure 5 – Growth of Signed TLDs

Figure 6 – Growth of Signed ccTLDs

Figure 7 – Growth in Signed gTLDs

3.2 Second-level domains (SLDs)

Statistics for signing of SLDs (and below) are more difficult to track with the same accuracy and consistency as TLDs, due to the large number of zones and their dynamics. The different efforts to measure the status of signing of zones below the TLD level can show different numbers based on what criteria they are using, where they are polling from, the polling interval and time, etc.

Verisign Labs’ SecSpider effort measures a set of approximately 2 – 2.5 million zones collected from different sources (e.g., volunteered data, zones crawled via polling systems, walking zones via NSEC). Table 5 shows the current numbers. [16]

Table 5 – DNSSEC Signed Zones

The SecSpider effort considers a zone secure if it meets the following criteria:

• Must support EDNS0
• Must have RRSIG records attached to resource record sets (RRsets)
• Must not have a CNAME for the zone’s domain name
• Must provide NSEC records for denial of existence

Figure 8 illustrates the growth in DNSSEC zones since 2005 as measured by the SecSpider effort.

Figure 8 – SecSpider Measured Growth of DNSSEC Deployment [17]

It is useful to view the deployment of DNSSEC in .com and .net TLDs given their popularity and size as shown in Figure 9 and Figure 10. [18]

Figure 9 – Count of Domains with DS Records in .com and .net

Figure 10 – Percentage of Domains with DS Records for .com and .net

NTLDstats [19] measures the deployment of new gTLDs, including deployment of DNSSEC in zones under those gTLDs. Figure 11 illustrates the growth in signed zones under the gTLDs. Although the gTLDs were required to support DNSSEC by ICANN as a condition for creation, deployment of DNSSEC in the zones under the gTLDs is voluntary by the zone owners.

Figure 11 – Growth in signed zones in the new gTLDs [20]

At this time, NTLDstats shows that out of 26,803,748 domains, only 114,196 zones are signed (0.42%). Their numbers indicate that approximately 29% of the signed zones have DNSSEC errors. Note that NTLDstats also show that ~69% of the domains under the gTLDs are parked, though they don’t break out their signed zone numbers into parked and unparked domains.

One interesting development with the new gTLDs was the requirement by two new gTLDs (.bank and .insurance) for all domains registered under those TLDs to be signed with DNSSEC. This results in 100% of those SLDs being signed. While the numbers are small right now, it will be interesting to see if this requirement catches on with any other new gTLDs.

The US Government (USG) has frequently provided the view that an appropriate role for governments to encourage deployment of new technologies in their countries by deploying the new technology in their own networks. Therefore, it is useful to look at the deployment of DNSSEC on zones within .gov. Figure 12 shows that 88% of the tested domains had enabled DNSSEC [21].

Figure 12 – Current State of USG DNSSEC enabled Domains [22]

Figure 13 illustrates the trend in enabling DNSSEC in USG domains since 2011. While this trend shows the number of domains supporting DNSSEC has levelled off or declined slightly since 2013 it also shows that the number of unsigned or domains with errors has declined.

Figure 13 – Trend of USG DNSSEC Enabled Domains over Time [23]

3.3 Algorithms and key sizes

DNSSEC depends on cryptographic algorithms for the following operations:

• Generating keys for signing (DNSKEY)
• DNSSEC signatures (RRSIG)
• Chain of trust (DS Record)
• Generation of NSEC/NSEC3 responses by authoritative DNS servers
• Validation of DNSSEC records by resolvers.

The security and reliability of DNSSEC depends on the algorithm and key length used. Over time, as techniques to compromise algorithms have become more sophisticated and more powerful, newer algorithms have been defined and key lengths have been increased (where applicable). Given the highly distributed nature of the DNS, new algorithms are deployed into different zones at different times as operators upgrade their systems at different rates. Table 6 provides the latest recommendations from the IETF [ RFC6944 ], though the IETF DNS Operations (DNSOP) working group is currently developing new recommendations. [I-D.wouters-sury-dnsop-algorithm-update]. In addition, newer algorithms are being developed (e.g., [I-D.ietf-curdle-dnskey-eddsa]).

Since algorithm 6 is an alias for 3 and algorithm 7 is an alias for 5 these numbers are combined in the following tables.

Table 6 – Algorithm recommendations from RFC6944

Root Zone:

• From the first signing of the root zone (2010) until 2016, the root zone was signed using RSA/SHA-256 (8) with a Zone Signing Key length of 1024 bits.
• In September 2016, Verisign introduced 2048 bit Zone Signing Keys as part of its quarterly ZSK rollover process (not to be confused with the root KSK rollover). By the end of December 2016, this process should be complete.
• The root zone Key Signing Key is 2048 bits in length and RSA/SHA-256 is used for signing. [26]

TLD:

Table 7 illustrates the distribution of algorithms and key lengths for the TLD Key Signing Keys. The overwhelming majority (~99%) of TLDs use 2048 bit keys. ~75% of TLDs use RSA/SHA-256 for signing followed by RSA/SHA-1.

Table 7 – Distribution of Algorithms & Lengths in TLD Key Signing Keys (5 December, 2016)

Table 8 illustrates the distribution of algorithms and key lengths for the TLD Zone Signing Keys. The algorithms used roughly tracks the Key Signing Keys; however, the dominant key length for the ZSKs is 1024 bits followed by 1280 bits. Since ZSKs are rolled over more frequently, the general practice is to use a shorter key length than for the KSK.

Table 8 – Distribution of Algorithms and Lengths for Zone Signing Keys (5 December 2016)

General

As part of its SecSpider effort, Verisign Labs publishes statistics on the key signing algorithms that they see on the zones they monitor, summarized in Table 9.

Table 9 – SecSpider Distribution of key algorithms (23 December 2016) [27]

Similar to the TLD numbers [28], RSA/SHA256 is the algorithm used in the majority of zones followed by RSA/SHA-1. Elliptic Curve Digital Signature Algorithm (ECDSA) is the newest algorithm defined for DNSSEC and is used in ~5% of zones monitored (note that none of the TLDs use ECDSA). SecSpider doesn’t break out KSKs and ZSKs and doesn’t provide the key lengths used.

4 State of Deployment of DNS-based Authentication of Named Entities (DANE)

The requirements for DNS-Based Authentication of Named Entities (DANE) were published in 2011 [RFC6394] with TLSA records defined in 2012 [RFC6698] and operational guidance in 2015 [RFC7671]. DANE defines a way “to use the DNSSEC infrastructure to store and sign keys and certificates that are used by TLS” as well as binding public key data to DNS names. While DANE deployment has been slow, it has picked up recent support, especially in securing transfers between email servers [RFC7672]. This recent growth is reflected in the recent growth in number of zones deploying TLSA as measured by Verisign Labs (see Figure 14 ).

Figure 14 – TLSA Deployment [29]

Verisign Labs also provides a breakdown of the services for which there is a TLSA record:

Table 10 – Services with TLSA Records [30]

DANE (similar to DNSSEC) requires support from DNS Servers to hold the TLSA records and clients (including resolvers) to utilize the TLSA records.

DNS Servers supporting DANE (TLSA records) include [31]:

• BIND (from version 9.9.x)
• NSD (from version 3.2.11)
• PowerDNS (from version 3.0)
• Microsoft DNS (from Windows Server 2016)
• Knot DNS (from version 1.0.4)
• YADIFA (from version 2)

Mail servers supporting DANE include:

• Postfix support since 2014 (3.1 or later recommended)
• Halon support since 2015
• Exim 4.85 (experimental)
• Sendmail – no support (patch available [32] )
• Exchange Server – no support (3rd party solution: XWall/CryptoFilter [33] )

Web browsers: No major web browser supports DANE, though cz.nic has developed a DNSSEC/TLSA Validator browser add-in.

Libraries:

• OpenSSL (DANE from 1.1.0) (ECDSA from 0.9.8)
• gnutls (from 3.1.3)

Over the past few years, DANE deployment has picked up steam securing transport of email between servers, driven by German email providers. DANE alleviates one of the major burdens of running TLS between servers by making it easier to acquire the keys for a remote server as needed and allows a mail provider to signal the enforcement of TLS use (preventing downgrade-STARTTLS attacks). In May, 2016 two of the largest email providers in Germany (web.de and GMX) enabled support for DANE as part of the “Email made in Germany” effort [34]. These two providers represent over 50% of the German email market.

Victor Dukhovni has been tracking domains with TLSA records for MX hosts and has found that the number exceeds 103,000 as of 4 December 2016. He has also found that the hosting providers with the top 5 counts of DANE SMTP domains are:

Table 11 – Top 5 Hosting Providers with DANE SMTP domains [35]

National governments have started including use of DANE to secure email in their requirements and recommendations. In September 2016, the National Institute of Standards and Technology (NIST) published Special Publication 800-177 [SP800177] on trustworthy email that includes DANE as one of its methods [36] . In May 2016, Germany’s Bundesamt für Sicherheit published TR-03108 containing its technical guidelines for secure email transport [37] . The Netherlands also added DANE (with STARTTLS) to its “use or explain” list. [38] [39]

Work is underway in both the IETF and in the field to further define usage of DNSSEC to secure email, e.g., SMIMEA [SP1800-6][SMIMEA] and OPENPGPKEY [RFC7929].

5 Root Key Signing Key (KSK) Rollover

While the root ZSK rollover is a regularly scheduled quarterly event, ICANN’s practice for the root KSK rollover is every 5 years, or as required. [40] Due to its potential for disruption, KSK Rollover plans are carefully developed by Root Zone Management Partners:

• ICANN (as IANA Functions Operator)
• Verisign (as Root Zone Maintainer)
• NTIA (as Root Zone Administrator. Note that this role ended as of 1 October 2016.)

The first-ever root KSK rollover process began on October 27, 2016 when ICANN generated the new KSK [41] . The rollover process will continue through 2018, when the old KSK and backups should be deleted from all systems. The draft timeline for the remaining steps in the rollover are:

• February 2017: New KSK published in Trust Anchor XML file at http://data.iana.org/root-anchors/
• July 2017: New KSK published in root zone as part of DNSKEY RRset signed by the old KSK.
• September 2017: Size increase for DNSKEY response from root name servers.

o Root name servers include both old and new KSK DNSKEY in responses

• October 2017: Begin signing the root zone DNSKEY RRset with new KSK (Actual rollover event).
• January 2018: Old KSK is published in root zone DNSKEY RRset with revoked bit set. DNSKEY RRset includes new KSK.
• March 2018: Remove old KSK from the root zone.
• May/August 2018: Old KSK and all backups deleted

The new KSK will maintain the same algorithm (RSA/SHA-256) and key length (2048 bits) as the previous KSK. For more information, see ICANN’s Root Zone KSK Rollover web site [42].

6 Challenges to Deployment

In the signing of the root zone in 2010, one of the largest impediments to deployment of DNSSEC was removed, providing a chain of trust to the root. During this time, the DNSSEC Deployment Initiative [43] was active in promoting the deployment of DNSSEC. In 2012, ISOC published a white paper examining the challenges to deployment of DNSSEC on the Internet. [44] The Internet Society instituted their Deploy360 Programme providing information, tutorials and other resources to help with the deployment of DNSSEC [45]. The DNSSEC Deployment Initiative, the ISOC Deploy360 Programme and ICANN’s Security and Stability Advisory Committee (SSAC) continue to jointly organize a full day workshop on DNSSEC deployment at ICANN meetings.

Great strides have been made since 2012 in addressing the challenges identified, as can be seen by the growth in number of TLDs signed, general availability of validating resolvers and wider availability of tools; however, many of the challenges still need to be addressed, such as availability of DNSSEC-aware applications.

6.1 Challenges with changing cryptographic algorithms

As attacks on cryptography improve and as research into new cryptographic (often simply called “crypto”) algorithms progresses, new crypto algorithms will need to be deployed in DNS. As can be seen in Section 4.3, different crypto algorithms and key lengths are deployed in different zones and can be supported in the Internet at present (e.g., .com uses RSA/SHA-256 and cloudflare.com uses ECDSA Curve P-256). The challenge occurs when a zone is migrated from one crypto algorithm to another. The impact of the migration will generally depend on how large the zone is and the criticality of operation of the sub-zones.

An Internet-Draft under development [ CRYPTOALG ] discusses the challenges in deploying new crypto algorithms. This I-D identifies challenges in the following areas when deploying new algorithms.

• DNS resolvers performing validation

o New algorithms will generally require updating resolver software
o New algorithms could trigger undetected bugs and non-updated software must handle unknown algorithms correctly.
o Potential increased CPU load and memory requirements.
o See [RFC8027] for more information on problems validators might see with noncompliant infrastructure.

• Authoritative DNS servers

o Zone updates need to be capable of using new algorithms in creation of NSEC or NSEC3 records in the zone.
o Servers that use some form of dynamic response to provide NSEC or NSEC3 records need to incorporate new algorithms into their response function.

• Signing software (including user interfaces)

o Update needed to support the new algorithm.
o Update might be needed to support rollover.

• Registries

o Registries must be able to support the codepoint for the new algorithm in DS Records for lower level zones, even if the registry doesn’t use the new algorithm.

• Registrars

o Software and systems must be able to support new algorithm codepoints in its verification process for creation of DS Records.
o Communication with registries and DNS hosting operators may need to be updated to support the new algorithm.

• DNS Hosting Operators

o Must update authoritative DNS servers and associated provisioning software to support the new algorithm
o A new algorithm could also affect the CPU load and memory requirements.

• Applications

o Applications that perform DNSSEC validation would need to be updated to support the new algorithm.

6.2 Case study – Elliptic Curve Digital Signature Algorithm (ECDSA) rollout

An example of the migration to a new crypto algorithm is the deployment of the Elliptical Curve Digital Signature Algorithm [ RFC6605 ] published in 2012. This algorithm is reported to provide shorter key lengths while providing the same level of cryptographic protection as longer keys used by RSA.[EDCSAIMP] While Unbound and BIND have supported ECDSA for several years it can take time to integrate the new software release into products. There can also be delays in turning on the new capability in the field. Discussions have also indicated that at least one registrar did not support ECDSA simply because the user interface in their provisioning systems didn’t allow the algorithm to be selected.

Studies done by APNIC Labs illustrate the support of ECDSA P-256 in validating resolvers, see Figure 15 and Table 12 [46]. These studies indicate that, except for a few countries, support for ECDSA in resolvers is roughly equivalent (slightly less) to support for RSA.

The SecSpider results summarized in Table 9 indicate that approximately 5% of zones studied are signed by ECDSA. While the majority of this usage can be attributed to Cloudflare’s support for ECDSA, [ ECDSACASE ] indicates that other DNS providers are starting to support ECDSA. [ ECDSACASE ] provides a good case study of the deployment of ECDSA and some of the difficulties it faces.

While an advantage given for migrating to ECDSA is the reduction in the size of signatures (compared to RSA) with a resulting reduction in fragmentation of responses and reduction of potential amplification factor, one of the concerns expressed about the use of ECDSA is the increased CPU load in resolvers. A recent study by researchers at the University of Twente indicate that, while ECDSA validation does increase the load on resolvers as compared to RSA, it does not do so beyond the capacity of modern CPU cores. The study addresses a potential denial of service attack on a resolver due to CPU attack and suggests a countermeasure utilizing rate-limiting in resolvers. [ ECCRESOLVE ]

Figure 15 – APNIC DNSSEC ECDSA Validation Rate by country (%)

Table 12 – Resolver Support for ECDSA by Region

6.3 Automation of secure delegations

Another DNSSEC deployment challenge that received significant attention during 2016 was the area of automating the updates of DNS records related to the global “chain of trust” used in validation.

To create a chain of trust from the root of DNS down to a second level domain, Delegation Signer (DS) resource records [RFC3658] are used to connect the child zone to the parent zone (typically, but not always, a TLD). The registry operating the parent zone requires that the operator of the child zone upload a DS record (or in a few cases a DNSKEY record) through typically a web interface or some form of application programming interface (API).

The challenge is that the current operation model requires that the registrar for a given domain name be the one to provide the update to the registry. This works fine if the registrar is also the operator of the authoritative DNS servers for the domain. However, if the domain registrant is using a different entity to operate the authoritative DNS servers, or are operating their own authoritative DNS servers, the registrar must still be involved. Given that current best practices for DNSSEC involve annually rolling the KSK, this requires at least an annual update of the DS or DNSKEY records via the registrar.

Unfortunately this is not easily automated, given the wide range of different systems used by registrars and registries. [RFC7344] offered one approach and a new Internet draft in 2016, [I-D.ietf-dnsop-maintain-ds], provided updates to improve this process.

Another proposal has been submitted to the IETF Registry Extensions (REGEXT) working group, [I-D.ietf-regext-dnsoperator-to-rrr-protocol] [47] and active implementations are underway by both CIRA [48] and Gandi [49] . Signers such as CloudFlare and Gandi are working with registries behind TLDs including .CA (Canada) and .CL (Chile) to test these implementations.

7 Conclusion

Since the DNS root zone was signed in 2010, the deployment of DNSSEC has made steady progress. Almost all of the gTLDs are now signed and approximately half of the ccTLDs, including over 90% of the ccTLDs from OECD countries. Progress among Second Level Domains has been slower globally, but with areas of greater deployment depending on the TLD and region (e.g., .nl, .cz, .se, .gov). Most major authoritative server software now supports DNSSEC with increasingly better tools for managing deployment and operation.

On the resolver side, all the major resolver software supports DNSSEC validation. APNIC’s studies have shown that resolvers used by over 80% of clients in their study already query for DNSSEC records even if they haven’t currently enabled validation. As illustrated by Claro and Comcast, a single large provider turning on validation for its customers can substantially change the complexion of validation in in a country.

An example of a service driving deployment in a particular community is the use of DANE to secure email between servers. The German email community has taken the lead in utilizing DANE to secure communication between email providers and support is spreading to other European providers.

Development continues to evolve as DNSSEC is more widely deployed and gains more operational experience and as DNS-based attacks continue to be a concern (e.g., amplification attacks, DNSChanger). As an example, ECDSA has been proposed as a way to reduce amplification attacks and using DNSSEC’s built-in functionality to identify non-existent domains via NSEC records to terminate certain attack traffic at the resolver.[AGGNSEC] In addition, work is ongoing to protect the link between the client and the validating resolver.

We encourage all readers of this report to, at a minimum, deploy DNSSEC validation to begin checking signatures and then to understand their options for signing their domains. Together we can create a stronger and more trusted DNS.

8 References

[ECCRESOLVE] van Rijswijk-Deij, R., Hageman, K., Sperotto, A., and A. Pras, “The Performance Impact of Elliptic Curve Cryptography on DNSSEC Validation,” in IEEE/ACM Transactions on Networking , vol.PP, no.99, pp.1-13, 22 September 2016.

[ ECDSACASE] van Rijswijk-Deij, R., Sperotto, A., and A. Pras, “Making the Case for Elliptic Curves in DNSSEC.” in ACM SIGCOMM Computer Communication Review 45(5):13-19 · September 2015

[ KAMINSKYBUG] Wright, Cory, “Understanding Kaminsky’s DNS Bug,” Linux Journal, July 2008 (http://www.linuxjournal.com/content/understanding-kaminskys-dns-bug)

[ RFC2065] Eastlake 3rd, D. and C. Kaufman, “Domain Name System Security Extensions”, RFC 2065, January 1997.

[RFC3658] Gudmundsson, O., “Delegation Signer (DS) Resource Record (RR)”, RFC 3658, December 2003.

[ RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements”, RFC 4033, March 2005.

[ RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions”, RFC 4034, March 2005.

[ RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions”, RFC 4035, March 2005.

[ RFC6394] Barnes, R., “Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)”, RFC 6394, October 2011.

[ RFC6605] Hoffman, P. and W. Wijngaards, “Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC”, RFC 6605, April 2012.

[ RFC6698] Hoffman, P. and J. Schlyter, “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA”, RFC 6698, August 2012.

[ RFC6944] Rose, S., “Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status”, RFC 6944, April 2013.

[ RFC6891] Damas, J. and P. Vixie, “Extension Mechanisms for DNS (EDNS(0)),” RFC 6891, April 2013.

[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, “Automating DNSSEC Delegation Trust Maintenance”, RFC 7344, September 2014.

[RFC7671] Dukhovni, V. and W. Hardaker, “The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance,’ RFC 7671, October 2015.

[RFC7672] Dukhovni, V. and W. Hardaker, “SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS),” RFC 7672, Oct. 2015.

[RFC7929] P. Wouters, “DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP,” RFC 7929, August 2016.

[ APNICM] Geoff Huston, “Measuring DNSSEC Performance”, APNIC Labs, 30 Apr 2013, ( https://labs.apnic.net/?p=341).

[ CRYPTOALG] York, D. , Sury, O., Wouters, P. and O. Gudmundsson, “Observations on Deploying New DNSSEC Cryptographic Algorithms,” draft-york-dnsop-deploying-dnssec-crypto-algs-04, November, 2016. (work in progress)

[SP800177] National Institute of Standards and Technology Special Publication 800-177, “Trustworthy Email,” September 2016.

[SP1800-6] National Institute of Standards and Technology Special Publication 1800-6, “Domain Name Systems-Based Electronic Mail Security”, November 2016, (DRAFT).

[SMIMEA] Hoffman, P and J. Schlyter, “Using Secure DNS to Associate Certificates with Domain Names For S/MIME,” draft-ietf-dane-smime-14, November 2016, work in progress.

[ECDSAIMP] Khalique, A., Singh, K., and S. Sood, ”Implementation of Elliptic Curve Digital Signature Algorithm”, May 2010. (Web. http://www.ijcaonline.org/volume2/number2/pxc387876.pdf)

[I-D.wouters-sury-dnsop-algorithm-update] Wouters, P. and O. Sury, “Algorithm Implementation Requirements and Usage Guidance for DNSSEC,” draft-wouters-sury-dnsop-algorithm-update-02 (work in progress), October 2016.

[I-D.ietf-curdle-dnskey-eddsa] Sury, O. and R. Edmonds, “EdDSA for DNSSEC”, draft-ietf-curdle-dnskey-eddsa-01 (work in progress), October 2016.

[I-D.ietf-dnsop-maintain-ds] Gudmundsson, O., and P. Wouters, “Managing DS records from parent via CDS/CDNSKEY”, draft-ietf-dnsop-maintain-ds-04, October 2016.

[I-D.ietf-regext-dnsoperator-to-rrr-protocol] Latour, J., Gudmundsson, O., Wouters, P., and M. Pounsett, “Third Party DNS operator to Registrars/Registries Protocol”, draft-ietf-regext-dnsoperator-to-rrr-protocol (work in progress), July 2016

[AGGNSEC] Fujiwara, K., Kato, A. and W. Kumari, “Aggressive use of NSEC/NSEC3,” draft-ietf-dnsop-nsec-aggressiveuse-03, October 2016, work in progress.

9 Appendix: Resources

• Deploy360 DNSSEC Programme: https://www.internetsociety.org/deploy360/
• DNSSEC Deployment Initiative: http://www.dnssec-deployment.org
• ICANN DNSSEC Resources: https://www.icann.org/resources/pages/dnssec-2012-02-25-en

10 Acknowledgements

This 2016 report was prepared by Chip Sharp with input from Dan York. We appreciate the proofreading and feedback of the following people: Steve Crocker, Paul Ebersman, Geoff Huston, Fabhia Kumari, Megan Kruse, Rick Lamb, Jacques Latour, Hugo Salgado-Hernández and Paul Wouters.

We thank all of the members of the DNSSEC community who share their data and are working each day to raise the level of trust in the DNS.

Please send any feedback on this report to Dan York at [email protected].

Notes

[1] https://www.dnssec.nl/home.html

[2] http://registro.br/estatisticas.html

[3] http://www.internetsociety.org/deploy360/dnssec/

[4] http://stats.labs.apnic.net/DNSSEC

[5] https://developers.google.com/speed/public-dns/

[6] Geoff Huston, DNSSEC Workshop, ICANN56, https://icann562016.sched.org/event/7NCj/dnssec-workshop-part-1.

[7] Ibid.

[8] http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=1&g=0 (12/13/2016) with 14 day interval

[9] The notches in the graph are artifacts from the measurement technique used.

[10] https://stats.labs.apnic.net/dnssec/BR?c=BR&x=1&g=0&r=1&w=14 (14 day interval)

[11] Geoff Huston, DNSSEC Workshop, ICANN56, https://icann562016.sched.org/event/7NCj/dnssec-workshop-part-1.

[12] Note: A single DNSKEY RR could contain a ZSK and KSK, but general practice is that they are separate.

[13] For the purpose of this document, we include “sponsored” and “restricted” TLDs as part of “generic TLDs”.

[14] Includes TLDs that are signed but don’t have a DS RR in the root zone.

[15] Deployment maps published weekly at http://www.internetsociety.org/deploy360/dnssec/maps/

[16] http://secspider.verisignlabs.com/stats.html (23 December 2016)

[17] http://secspider.verisignlabs.com/growth.html

[18] http://scoreboard.verisignlabs.com

[19] https://ntldstats.com/dnssec

[20] https://ntldstats.com/dnssec (12/18/2016)

[21] https://fedv6-deployment.antd.nist.gov/snap-all.html (12/18/2016)

[22] https://usgv6-deploymon.antd.nist.gov/snap-all.html (12/18/2016)

[23] https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov (12/18/2016)

[24] Alias for RSA/SHA1

[25] Alias for DSA/SHA1

[26] https://www.iana.org/dnssec/icann-dps.txt

[27] http://secspider.verisignlabs.com/stats.html

[28] Snapshot on 12/6/2016 from http://secspider.verisignlabs.com/stats.html (numbers updated daily)

[29] http://secspider.verisignlabs.com/pix/tlsa-growth.png (12/18/2016)

[30] http://secspider.verisignlabs.com/stats.html (12/18/2016)

[31] https://bsidesljubljana.si/wp-content/uploads/2016/03/P-DANE.pdf

[32] http://www.five-ten-sg.com/util/sendmail-8.16.0-dane.patch

[33] http://www.dataenter.com/doc/cryptofilter.htm

[34] https://de.wikipedia.org/wiki/E-Mail_made_in_Germany

[35] email from Viktor Dukhovni to the [email protected] mail list on 12/4/2016

[36] https://www.nist.gov/node/1099976

[37]https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03108/index_htm.html

[38] https://www.forumstandaardisatie.nl/standaard/starttls-en-dane

^[39] https://www.sidnlabs.nl/a/weblog/new-e-mail-security-protocols-mandatory-within-government?language_id=2&langcheck=true

[40] ICANN, “DNSSEC Practice Statement for the Root Zone KSK Operator,” 1 October, 2016, https://www.iana.org/dnssec/dps/ksk-operator/ksk-dps.txt

[41] https://www.icann.org/news/blog/ksk-rollover-operations-begin

[42] https://www.icann.org/resources/pages/ksk-rollover

[43] https://www.dnssec-deployment.org/

[44] http://www.internetsociety.org/deploy360/resources/whitepaper-challenges-and-opportunities-in-deploying-dnssec/

[45] http://www.internetsociety.org/deploy360/dnssec/

[46] http://stats.labs.apnic.net/ecdsa?s=ECDSA

[47] https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-to-rrr-protocol-01

[48] https://github.com/CIRALabs/DSAP/

[49] https://github.com/kalou/rrr