A measurement study of DNSSEC misconfigurations
© van Adrichem et al. 2015
Received: 13 March 2015
Accepted: 7 October 2015
Published: 19 October 2015
DNSSEC offers protection against spoofing of DNS data by providing origin authentication, ensuring data integrity and authentication of non-existence by using public-key cryptography. Although the relevance of securing a technology as crucial to the Internet as DNS is obvious, the DNSSEC implementation increases the complexity of the deployed DNS infrastructure, which may result in misconfiguration. In this article, we measure and analyze the misconfigurations for domains in six zones (.bg, .br, .co, .com, .nl and .se). Furthermore, we categorize these misconfigurations and provide an explanation for their possible causes. Finally, we evaluate the effects of misconfigurations on the reachability of a zone’s network. Our results show that, although progress has been made in the implementation of DNSSEC, over 4 % of evaluated domains show misconfigurations. The domains with the most frequently appearing misconfiguration are often hosted at a very limited set of hosting providers. Of these misconfigured domains, almost 75 % were unreachable from a DNSSEC-aware resolver. This illustrates that although the authorities of a domain may think their DNS is secured, it is in fact not. Worse still, misconfigured domains are at risk of being unreachable from the clients who care about and implement DNSSEC verification, while the publisher may remain unaware of the error and its consequences.
The Domain Name System (DNS)  is a crucial technology for the functioning of the Internet as it enables communication using domain names that are easier to remember than numerical IP addresses. Among others, DNS maps human-readable hostnames to IP addresses and provides a distributed database from which users can request these mappings. The popularity of this mapping system is explained by the use of Fully Qualified Domain Names (FQDNs) as the primary component of URLs with which all Internet users identify websites.
The importance of DNS lies in the fact that it is not only useful to end users, but that it is also essential to several other core network technologies , such as telephone number mapping (ENUM), SIP, email, spam filtering and Microsoft’s Active Directory for Windows. However, even though DNS is one of the fundamental building blocks of the Internet, its original design from 1983 focused on scalability and did not include security considerations. Even as early as 1990, the first flaws in the DNS were detected and the need for protection was discussed . The Domain Name System Security Extensions (DNSSEC) were published in 1997 and their refinement in 2005 .
DNSSEC, in a broad sense, offers protection against illegitimately falsifying data stored in the DNS by providing origin authentication, ensuring integrity and authentication of non-existence. To make sure that the user receives authentic replies, DNSSEC deploys cryptographic keys. With private keys, digital signatures are generated for resources which can be verified by their public counterparts.
Motivation and problem definition
the implementation of DNSSEC increases the complexity for the management of the deployed DNS infrastructure,
a misconfiguration might result in Internet users being unable to reach the protected network .
The effects of misconfiguration were very recently made apparent, when a new service from a major television network was unreachable by a significant number of end users due to DNSSEC misconfiguration. Furthermore, the television network resolved the problem by completely disabling DNSSEC authentication for their zone . These types of failures and resulting unreachability of services are not rare incidents, but appear quite often . In fact, there is an IETF Internet-Draft working on clarifying the authoritative domain’s responsibility towards a correct DNSSEC configuration .
Besides authoritative domains, DNSSEC validation failures have also been reported for complete TLDs . Such problems may occur more frequently when a new group of TLDs (up to 1400)  start rolling out within the next few years, since all of them must implement DNSSEC and misconfigurations of their zone files could potentially hide them from the Internet.
Despite the importance of the stated problem, there does not exist sufficient information on the current status of DNSSEC deployed zones. Therefore, in this article, we measure the status of several DNSSEC-enabled operational zones measuring both the level of DNSSEC implementation and the correctness of DNSSEC configuration. We believe that conducting experimental research on DNSSEC is of great value but, in order to get deeper insights, it should also be complemented with an analysis of the most common problems DNSSEC is experiencing in day-to-day production environments. Performing an analysis on real production data from operational zones brings a better understanding on the current status of DNSSEC deployment. Moreover, it also helps to define the biggest challenges that need to be overcome for this technology to succeed.
The article is organized as follows. “DNS and DNSSEC” summarizes the internal workings of DNS. “Related work” presents related work to misconfigurations, measurements and highlights proposed methods and shortcomings in DNSSEC. In “Measurement tools” the used measurement tools are presented, while “Measurement scenarios” discusses the performed “top-down” and “bottom-up” measurement scenarios.
First, “Results and evaluation: bottom-up approach” presents and analyzes the results of the top-down measurement scenario containing .bg, .br, .co and .se domains. The domains are, among others, chosen as they are browsable through zone walking.1 Furthermore, the .se zone draws importance for analysis as it was the first DNSSEC signed zone  in 2005, 5 years prior to the root domain, hence a high implementation is expected. Similarly, .co is also popular for commercial host names, the zone .br has one of the largest DNS registries in South America, while the .bg domain has signed its zone more recently.
Afterwards, “Results and evaluation: top-down approach” presents and analyzes the results from the bottom-up verification approach on a larger dataset containing .bg, .br, .co, .com, .nl and .se domains. Where the former 4 domains are included for means of comparison, .nl and .com are added for respectively having the highest implementation of DNSSEC-enabled domains  and being the largest TLD available. A conclusion is drawn in “Conclusion”.
DNS and DNSSEC
In this section, we summarize the functions and internal organization of the Domain Name System (DNS) and its Security Extensions (DNSSEC). In “DNS” we discuss how DNS implements a distributed lookup directory. “DNSSEC” discusses the most relevant extensions and possible errors in configuring DNSSEC.
The name of the record.
The type of the record. Popular records include, the A-, AAAA-, MX-, CNAME- and SPF-records, respectively storing an IPv4 address, IPv6 address, the responsible mail exchange hostname for that domain, an alias referring to another hostname and domain-specific rules regarding spam policies according to the Sender Policy Framework protocol.
The class code, specifying a name space scope. Although multiple codes exist, usage of values different from IN for Internet are uncommon.
The time-to-live, specifying in seconds how long intermediate or recursive DNS servers may cache that specific record, often defaulting to a zone’s TTL.
The length of the RDATA field, used for communication protocol implementation.
The RDATA field, containing the record’s actual stored data.
Most often, DNS is used to request mappings from computer hostnames to IP addresses. In order to support such a high frequency of requests, DNS employs a tree-wise hierarchy in both name and database structure. A so-called Fully Qualified Domain Name (FQDN) consists of multiple name components specifying the location of its records in a tree of databases. Clients, such as home and business PCs, connect to a local recursive (often caching) DNS server that traverses the tree to receive the requested information. In general, the traversed tree-wise structure of DNS consists of 3 layers: (1) The root-layer, a set of name servers named [a-m].root-servers.net. (2) The Top-Level-Domain (TLD) layer. (3) The authoritative layer.
Although DNS has proven to be very scalable, the architecture shows many possibilities for both un- and intended malicious behavior and attacks. It is fairly easy to tune-in and mangle with DNS requests and replies by executing a so-called man-in-the-middle attack, hence secretly redirecting the client to obscure locations, for means of hijacking personal authentication details, or falsely denying existence of resources. This, for example, could occur at open WiFi hotspots, where providers often offer their own, potentially malicious, DNS service. Hence, DNSSEC has been introduced to authenticate the validity of both returned RRs and non-existent records through cryptographic signing of resources.
In order to support the cryptographic signing process, each domain has multiple associated keys containing at least 1 public-private key pair. For each record set (RRset) of distinct name and type, a signature is generated using the private key and stored in an RRSIG-record, which can be verified using the domain’s public key stored in a DNSKEY-record, both placed in the zone of the domain.
The recursive chain from Trust Anchor, to intermediate DNSKEY-, DS- and RRSIG-records authenticates each RRset of a properly configured DNSSEC domain. Part of managing public-private key pairs is refreshing them regularly to prevent malicious parties from deriving the private key. Hence public-private key pairs are equipped with an expiration date and therefore need to be renewed at regular intervals. Replacing a DNS record, however, is non-trivial due to possibly long periods of caching in clients and intermediate resolvers. Furthermore, changing one’s public-key does not only involve updating one’s DNSKEY-record, but also implies updating the parent DS-record whose replacement needs to be performed by the TLD, a third party, again keeping cache synchronization in mind. Therefore, key rollover can be a tedious process .
In order to ease the process, a zone is equipped with two types of public-private key pairs, Key Signing Keys (KSKs) and Zone Signing Keys (ZSKs), both stored in DNSKEY-records and distinguished by a flag. KSKs concern the keys whose DNSKEY-record is confirmed by the parent’s DS-record and are exclusively used to sign other DNSKEY-records in the zone, the ZSKs. ZSKs are hence used to sign all other types of resources in the zone. As ZSKs are signed by a local KSK, those public-private key pairs can rollover independent of the parent-zone. The KSK often is a longer, cryptographically more complex, key pair that changes less often. Besides a decreased need of replacing the key due to its greater complexity, KSKs only sign a limited number of resources (ZSKs) making them less prone to attacks as less in- and output of the key pair is available. The ZSK changes more often and may be cryptographically less complex if sufficiently often replaced with new keys.
Authentication of non-existing resources
When a DNS server is queried for a non-existent record, i.e. there is no record for that requested name, it will respond with a NXDOMAIN message indicating its absence. Where DNSSEC so far authenticates existing resources, it is difficult to authenticate non-existing resources as non-existent records (1) have no corresponding signature, and (2) if for every NXDOMAIN response a signature would be computed online, key pairs would be more vulnerable to attacks. Since an authenticed response for an existing resource may be hijacked and replaced with an NXDOMAIN message, hence falsely denying existence of the resource, it is important to authenticate non-existing resources.
The first NSEC-record named example.com refers to mail.example.com indicating that mail.example.com is alphabetically the first subname of example.com, hence actively denying the existence of any subnames that would be ordered prior to it, such as ftp.example.com.
The second NSEC-record named mail.example.com refers to www.example.com indicating there are alphabetically no subdomain names between them, hence actively denying the existence of subsequently ordered subnames, such as news.example.com.
The final NSEC-record named www.example.com refers back to the zone name example.com, indicating it is alphabetically the last record.
An NSEC-enabled server will reply with the appropriate NSEC-record to requests for non-existing resources. Each existing NSEC-record, of whom as many exist as names exist for a domain, is ultimately signed by an RRSIG-record to confirm authenticity of the claimed non-existence. A property of the NSEC-records is that they can be iterated to gather a complete list of valid subnames for a domain or TLD, a process called zone-walking. We have extensively used this method to extract the lists of domain names from our selected TLDs.
However useful to our research, publishing the complete list of available resources does not relate to the occasional request of non-existent resources and may even raise concerns on privacy. Therefore, the improved NSEC3 additions hash the zone-specific name-component (i.e., mail. and www.) prior to ordering, and generate a recursive linked-list of NSEC3-records containing hashed values . In order to authenticate non-existence of a resource, the DNS server will hash the requested zone-specific name component and return the NSEC3-record indicating the non-existent range to which it belongs. Hence, proving non-existence without giving away existing names.
In this section, we discuss previous work on DNSSEC. We found that most studies focus on the performance of DNSSEC, such as latency, delay, or resource load on the server, rather than on misconfigurations . In , the authors analyze the availability of DNSSEC resolution and service, but omit configuration correctness. Lian et al.  present a quantitative measurement study towards the capability of resolvers and end-users to perform DNSSEC authentication, which represent the client side of DNSSEC. The authors of  present additional security vulnerabilities to DNSSEC itself, while in  the security benefits of the NSEC3 hashed authenticated denial of existence2 are evaluated.
Zone (missing/expired/invalid RRSIGs covering zone data, or missing DNSKEY RRs required to verify RRSIGs).
Delegation (bogus delegations because of lack of appropriate DNSKEYs in the child zone corresponding to DS RRs in the parent zone, or insufficient NSEC RRs to prove an insecure delegation to a resolver).
Anchor (stale trust anchors in a resolver, which no longer match appropriate DNSKEYs in the corresponding zone).
They analyze 1456 signed zones out of which 194 show to be misconfigured . Out of these, most of the misconfigurations are related to zone data that correspond to the first class of misconfigurations. However, the authors do not explain why this was the case and what were the main technical causes for such misconfigurations. The class 1 misconfigurations arise due to missing or outdated RRSIGs or DNSKEYs and, as explained in “Introduction”, the deployment of those records in the zone file is the responsibility of the zone administrator. Technically, the administrator should always ensure the correctness and validity of RRSIGs and DNSKEY deployment. Hence, the previous work does not give insight in the causes of misconfiguration, nor its effects in authenticity confirmation and reachability by a DNSSEC-aware resolver. Furthermore, the analysis was done in 2010, 5 years ago when DNSSEC was in an earlier stage of deployment compared to now in 2015 when DNSSEC is more widely implemented. In this paper, we analyze over 122,779 signed domains from .bg, .br, .co, .com, .nl and .se domains.
There exist several different tools to work with DNSSEC. However, most of them are intended to be used by zone administrators in order to verify their own zone file before publishing it and require the user to have the complete zone file in order to perform their tests. Examples of such tools include Verisign’s jDNSSEC  or NLnetLabs’ LDNS . We selected a set of tools that are able to perform tests over a list of several domains without possession of their zone files, that is to say, from the point of view of an external user. Furthermore, we selected these tools based on execution time and ease of automation to ease the process of checking a large amount of domains. We have used the following measurement tools to perform our measurements:
A DNS enumeration program, written in Python, that allows to discover relevant information from the content of a zone. It performs several types of enumeration including zone transfer, reverse lookup, a Google lookup and, most importantly, zone walking using NSEC-records as discussed in “Authentication of non-existing resources”. After testing the tool, we found its usage straightforward and effective since it provided us with the necessary means to easily and effectively retrieve all the authoritative name servers from a zone.
In the process of retrieving the domain lists for the domain, we enhanced the program with the following 3 functions: (1) To decrease the chance and impact of getting blocked by a DNS server due to excessive usage, we added support for multiple DNS servers. (2) We added the possibility to save the current state of iteration, so in case we were blocked by all DNS servers of a zone we were able to continue iteration from a different source IP-address. (3) Initially, Dnsrecon verified a domain’s intent to deploy DNSSEC capability by checking whether the authoritative name server returned a DNSKEY-record for its hostname. Instead, we verified the intent to check whether a domain registered a DS-record at its parent.
A web-based tool developed by Verisign Labs that inspects the chain of trust for a particular DNSSEC-enabled domain. It shows the step-by-step validation of a given domain and indicates any error or warning found in its DNSSEC configuration. We found DNSSEC-Debugger to be fast (analysis consumes approximately 3 s per domain) and ideal for automation as any domain can be inspected by executing a HTTP-request to http://dnssec-debugger.verisignlabs.com/<domain name>, where <domain name> is replaced with the domain name to be analysed. We use DNSSEC-Debugger to perform the top-down validation approach used in our first measurement scenario in “Top-down measurement scenario” and “Results and evaluation: top-down approach”.
Google’s public DNS service 
Found at IP-addresses 220.127.116.11 and 18.104.22.168, Google offers a free and globally accessible DNSSEC-enabled DNS resolution service, which can be used as an alternative to one’s in-house or ISP-provided DNS resolution server. In order to evaluate the effects of DNSSEC misconfiguration on the reachability of a domain, we assume a misconfigured DNSSEC domain to be unavailable when it does not pass Google’s Public DNS Service.
Dig (domain information groper), part of the popular DNS server BIND, is a command-line tool that can be used to query DNS servers. It is DNSSEC capable and can be used to verify the DNSSEC chain of trust from a top-down and a bottom-up perspective. However, we found that the current version queries all possible name servers for a TLD or authoritative zone for their A-record, even when glue records are known, when using the top-down approach, resulting in an infeasible amount of lookups. Hence, we only used Dig in a bottom-up approach using a DNSSEC-capable resolver as performed in our second measurement scenario in “Bottom-up measurement scenario”.
A top-down approach, where first the root zone is verified against the previously known root trust anchor, followed by the TLD zone against its corresponding DS in the root zone, finished by the authoritative zone against its corresponding DS in the TLD zone.
A bottom-up approach, where—in reverse order—first the authoritative zone is verified against the TLD zone, which is verified against the root zone, which in turn is verified against the root trust anchor.
In terms of authenticity verification, denoting a record to be either authentic or not, both methods are correct. However, in terms of finding the exact misconfiguration both are incomplete. For example, a top-down approach will assume an authoritative zone to be DNSSEC incapable when it finds no corresponding DS in the TLD zone, while the authoritative zone may serve private-public key pairs and signatures. In such a case, one could argue the domain intends to employ DNSSEC but fails to do so as it did not properly communicate the DS record to be published by the TLD. This specific misconfiguration cannot be found by a top-down approach. The bottom-up approach will find the previously described misconfiguration.
The bottom-up approach, however, assumes an authoritative zone to be DNSSEC incapable when it finds no RRSIG for the record it tries to authenticate. This implies that misconfigurations where the intention to apply DNSSEC by the existence of possible authoritative DNSKEYs or corresponding DSes in the TLD are omitted. To partially solve this problem and get insight in both misconfiguration errors, we have performed two different measurement scenarios on distinct datasets described in “Top-down measurement scenario” and “Bottom-up measurement scenario”.
Top-down measurement scenario
The measurement of the different domains in our first measurement scenario consists of 4 different phases, followed by an additional 5th phase in which we evaluate the effects of misconfiguration in everyday use. The first phase consists of gathering a comprehensive list of domain names. To do this, we use Dnsrecon to perform zone-walking of the 4 NSEC-enabled TLDs .bg, .br, .co and .se, hence retrieving extensive lists of domain names from these domains.
The second phase consists of filtering the list of domain names by the intent of them being DNSSEC enabled. We assume a domain name to intend to be DNSSEC enabled when a DS-record for that domain is registered at its TLD-zone. Filtering is performed by iterating the list of domain names and performing DS-record lookups using the internal functions of Dnsrecon.
Having retrieved a list with a sufficient number of DNSSEC-enabled domains, we verify their configuration using the DNSSEC-Debugger online tool from Verisign Labs. To do so, we iterate through the list, performing a HTTP-request to the appropriate URL and parse the response for further analysis. To verify the correctness of the DNSSEC-Debugger, we took a sample from the results and compared them with results from Dig. Normally, it takes approximately 3 s to receive the verification result for one domain name. In order to overcome this time limitation and to speed up the process, we perform up to 10 lookups in parallel by employing multithreading.
Top-down measured misconfiguration statistics for the ccTLD .se and respective reachability by Google’s public, DNSSEC-aware, DNS resolution service
Invalidated by DS
KSK invalidated by ZSK
Valid but expired
Invalidated by ZSK(s)
Valid but expired
General DNS failure
SOA serial differs
DNSKEY RR Failure
After performing the initial measurements, we verified the effects of misconfiguration by requesting the A-records associated with misconfigured domains from Google’s Public DNS Service which performs DNSSEC authentication verification.
Bottom-up measurement scenario
In our second measurement scenario, we use a publicly available dataset of domain names known as the DNS Census 2013 . The census is published anonymously and contains over 2.6 billion DNS records gathered from over 106 million domain names in 2013. Although the dataset is incomplete and it does not contain official sources, the census can be considered significantly large to be representative. From the list of all available domain names we have selected the .bg, .br, .co., .com, .nl and .se TLDs to perform our measurements on. We have chosen the .bg, .br, .co and .se TLDs as those have also been used in our initial measurement scenario, .nl since it has the highest number of DNSSEC implemented domains and .com since it has the largest number of domains in general. The high number of domains in the .com TLD, over 64 million, implies it is difficult to verify all chains of trust within a feasible timespan. To guarantee that the verified subset will be representable, we have randomized the order of the list up front.
Alike to the latter four steps of the previous scenario, we iterate the list of domains and perform DNSSEC validation using Dig and a DNSSEC-capable resolver. Due to the bottom-up approach, authoritative zones are considered DNSSEC capable if they publish RRSIGs for the A-records of their domain name. From the DNSSEC-capable domains, the chain of trust is analyzed and categorized. Finally, the reachability of misconfigured domains is also verified using Google’s Public DNS Service.
Results and evaluation: top-down approach
In this section, we discuss and evaluate the results from the experimental measurements described in “Top-down measurement scenario”. “DNSSEC implementation” shows the results from the first and second measurement phase, gathering domain names and measuring the integration of DNSSEC in the different zones. “DNSSEC misconfigurations” categorizes the misconfigurations of the zone .se into the type of misconfiguration. Finally, “Effects on availability” analyzes the result of the misconfigurations on the availability of the domain.
Top-down measurement on DNSSEC implementation per ccTLD
Stunningly, a third of the misconfigurations seem to revolve around general DNS misconfigurations or errors that could also occur in non-DNSSEC environments. Especially the number of reported server failures and time-outs are surprisingly high. We were unable to confirm whether these errors are strictly related to non-DNSSEC configuration, and thus unrelated to DNSSEC, or are caused by a server malfunction due to incompatibility with the DNSSEC-extended query. We did however find two occurrences with a more specific error, where the server indicated incompatibility with the DNSKEY resource record type, showing that DNSSEC-incompatibility with DNS servers once intended to perform DNSSEC is a problem. Finally, we found 14 occurrences in which the authoritative administration retracted its intention to implement DNSSEC before we were able to scan its zone for misconfiguration. In Fig. 5, we show the distribution among the most significant configuration errors.
Effects on availability
After performing the measurements, we proceeded to verify the reachability of the misconfigured domains using a DNSSEC validating resolver. For that purpose, we used Google’s Public DNS Service, which has implemented DNSSEC validation by default since May 2013 .
Results and evaluation: bottom-up approach
In this section, we discuss and evaluate the results from the experimental measurements described in “Bottom-up measurement scenario”. “DNSSEC implementation” shows the results from the first measurement phase, measuring the integration and initial validation of DNSSEC in the different domains. “DNSSEC implementation” further discusses the different categories of found misconfigurations and their implications. In “Analysis of domains without a DS”, we perform further experiments on the root cause of the most common misconfiguration mistake. Finally, “Signature validity” discusses additional results we collected on the validity of signatures.
Bottom-up measurement on DNSSEC implementation per TLD
Due to the difference in measuring the intent to employ DNSSEC compared to the previous measurement strategy, we find different numbers for the implementation of DNSSEC. Particularly, .bg, .co and .se show much higher numbers of domains implementing DNSSEC due to the inverse direction of detection. Where previously a DS record in the TLD denoted a zone DNSSEC capable, now an existing RRSIG for the domain does. The TLD .br, on the other hand, shows a lower number of implemented number of DNSSEC-capable domains, which may be explained by the small dataset of verified domains in the previous measurement scenario.
Finally, .nl and .com are added to the list of traversed domains. Where .nl shows a high implementation of DNSSEC, the implementation of DNSSEC in .com, the largest TLD, remains excruciatingly low. Furthermore, .com’s level of misconfiguration is very high due to a specific misconfiguration explained in the following two subsections.
Bottom-up measured misconfiguration statistics per TLD
No DS found
The increase in misconfiguration is explained by the fact that where a DNSSEC-capable domain without a DS record would be considered DNSSEC incapable in the top-down scenario, in the bottom-up scenario it is considered a distinct misconfiguration categorized as “No DS Found”. In fact, the results show that the main misconfiguration error concerns domains that have no valid DS published in their respective TLD. Since the bottom-up approach first verifies local RRSIG and DNSKEYs before requesting a DS, it implies that further configuration of the zone is correct and the chain of trust is merely broken by this one absent record. Hence, in total over 68 % of the misconfigurations is due to this relatively small error of not communicating one’s DS to the TLD.
Furthermore, we find that where the top-down approach showed many different categories of misconfigurations, in the bottom-up approach further errors are reduced to an expired RRSIG or time-out. The high occurrence of expired RRSIGs and absence of errors in DNSKEY validation (and exactly vice versa in the top-down approach) implies that domains that have DNSKEY validation problems (either due to DS- or KSK/ZSK- invalidation) also let their signatures expire. Hence, there was once a valid chain of trust which becomes outdated and invalid due to administrative neglection.
Finally, we had few occurrences in which Dig would crash with unclear errors. For means of completeness, we have added these occurrences as measurement error to our dataset.
Analysis of domains without a DS
As explained in the previous two subsections, many more misconfigurations have been found due to the detection of DNSSEC-capable domains implementing signatures and private-public key pairs that omit communicating their delegate signer to their TLD. Whereas implementing DNSSEC locally may be a matter of configuration and key computation, uploading the DS is a process that is TLD specific and may require periodic renewal. Hence, we find many domains that show this specific error.
Most owners of a domain do not run their own DNS and web servers, but instead use a web hosting service to arrange those technicalities for them. Therefore, it is interesting to find whether the source of these many misconfigurations share a common cause. Hence, for each domain we have performed a whois lookup for the IP address stored in its A-record. A whois lookup is an information request about the owner of an IP address or domain name. For this, we have used the whois host server of Team Cymru , which contains mappings from IP address to Autonomous System (AS). We use the AS to identify the web hosting party that serves that particular domain.
Having analyzed the DNSSEC misconfigurations of four zones (.bg, .br., co. and .se), our measurements show that implementing DNSSEC is not trivial and that misconfigurations exist in large numbers. From the 282,766 gathered domain names, only 7.93 % show the intent to implement DNSSEC. Furthermore, over 4 % of DNSSEC-enabled domains show a form of misconfiguration, emphasizing the configuration complexity. Where one might expect expiration of keys to be a significant means of misconfiguration, categorization of the errors found in the .se domains shows its impact to be neglectable. Instead, most DNSSEC-related misconfigurations are caused by an inconsistency concerning the DNSKEY, the main public key of a domain. In more than 99 % of the cases of a missing DNSKEY or an error in the two-stage ZSK and KSK DNSKEY signing process, the error led to an unreachable domain and thus unreachable website or other network service. User availability shows to vary per type of misconfiguration. On average, 73.86 % of the misconfigured domains appeared unreachable from a DNSSEC-aware resolver. Hence, organizations implementing DNSSEC need to frequently verify the correct configuration of DNSSEC parameters and perhaps implement mechanisms to guarantee continuous correctness of configuration and authentic availability of their resources.
Measurements on a second dataset, including domains from .bg, .br, .co, .com, .nl and .se, show that many more domains have the intent of implementing DNSSEC (over 20 % excluding .com) but fail to communicate an essential part to their respective TLD. We show that a limited number of faulty configured web hosting parties cause most of the misconfigurations. Furthermore, we observe that where signature expirations were initially practically absent, now we exclusively find expired signatures. This implies that key invalidation almost always coincides with signature expiration, both results of a neglected zone. Furthermore, mapping the misconfigured domains to their respective web hosting provider shows that only 5 providers are responsible for 60.6 % of the found misconfigurations. Finally, we show that a 3 and 2 week validity period between inception and expiration are most popular, followed by half-year and 1 month renewal periods.
The authors thank Christian Doerr for his valuable feedback and participation in insightful discussions. Furthermore, we thank Verisign Labs for providing us with detailed information on the verification tests performed by the Verisign DNSSEC Debugger. This research has been partly supported by the EU FP7 Network of Excellence in Internet Science EINS (project no. 288021). This article is an extended version of van Adrichem et al. .
The authors declare that they have no competing interests.
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
- van Adrichem NLM, Lúa AR, Wang X, Wasif M, Fatturrahman F, Kuipers FA (2014) DNSSEC Misconfigurations: how incorrectly configured security leads to unreachability. In: Intelligence and Security Informatics Conference (JISIC), 2014 IEEE Joint, pp 9–16Google Scholar
- Mockapetris PV (1987) Domain Names—Implementation and Specification. IETF. RFC 1035 (INTERNET STANDARD). http://www.ietf.org/rfc/rfc1035.txt
- Migault D, Girard C, Laurent M (2010) A Performance view on DNSSEC migration. In: 2010 International Conference on Network and Service Management (CNSM), IEEE, pp 469–474Google Scholar
- Bellovin SM (1995) Using the Domain Name System for System Break-ins. In: Proceedings of 5th USENIX UNIX Security Symposium, USENIX Association, BerkeleyGoogle Scholar
- Arends R, Austein R, Larson M, Massey D, Rose S (2005) DNS Security - Introduction and Requirements. IETF. RFC 4033 (Proposed Standard). http://www.ietf.org/rfc/rfc4033.txt
- Cambus F StatDNS—DNS and Domain Name statistics. http://www.statdns.com. Accessed 02 Mar 2015
- ICANN and VeriSign Inc.: Root DNSSEC. http://www.root-dnssec.org/. Accessed 02 Mar 2015
- ICANN: DNSSEC Securing the Internet: benefits to Companies and Consumers. http://www.icann.org/en/news/in-focus/dnssec/dnssec-card-03dec12-en.pdf. Accessed 02 Mar 2015
- Deccio C, Sedayao J, Kant K, Mohapatra P (2011) Quantifying and Improving DNSSEC Availability. In: Proceedings of 20th International Conference On Computer Communications and Networks (ICCCN), 2011, pp 1–7Google Scholar
- York D. HBO NOW DNSSEC Misconfiguration Makes Site Unavailable From Comcast Networks (Fixed Now) Deploy360 Programme. http://www.internetsociety.org/deploy360/blog/2015/03/hbo-now-dnssec-misconfiguration-makes-site-unavailable-from-comcast-networks-fixed-now/. Accessed 12 May 2015
- Comcast: DNSSEC News. http://dns.comcast.net/index.php/categories/listings/dnssec-news. Accessed 22 Jul 2015Google Scholar
- Livingood J (2015) Responsibility for Authoritative DNSSEC Mistakes. Working Draft. http://www.ietf.org/internet-drafts/draft-livingood-dnsop-auth-dnssec-mistakes-02.txt
- Comcast: gov Failing DNSSEC Validation. http://dns.comcast.net/index.php/entry/gov-failing-dnssec-validation-1. Accessed 22 Jul 2015
- ICANN: Applicant Guidebook | ICANN New gTLDs. http://newgtlds.icann.org/en/applicants/agb. Accessed 02 Mar 2015
- Internet Infrastructure Foundation: DNSSEC—The Path to a Secure Domain. https://www.iis.se/english/domains/tech/dnssec/. Accessed 02 Mar 2015
- SIDN: SIDN Annual Report 2013. https://www.sidn.nl/annualreport/dot-nl. Accessed 04 Mar 2015
- IANA: Root Zone DNSSEC Trust Anchors. http://data.iana.org/root-anchors/. Accessed 02 Mar 2015
- Schaeffer Y, Overeinder B, Mekking M (2012) Flexible and Robust Key Rollover in DNSSEC. In: Proceedings of the Workshop on Securing and Trusting Internet Names (SATIN 2012). NPLGoogle Scholar
- Schlyter J (2004) DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format. IETF. RFC 3845 (Proposed Standard). http://www.ietf.org/rfc/rfc3845.txt
- Laurie B, Sisson G, Arends R, Blacka D (2008) DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. IETF. RFC 5155 (Proposed Standard). http://www.ietf.org/rfc/rfc5155.txt
- Huston G, Michaelson G. Measuring DNSSEC Performance. http://impossible.rand.apnic.net/ispcol/2013-05/dnssec-performance.pdf. Accessed 22 Jul 2015
- Lian W, Rescorla E, Shacham H, Savage S (2013) Measuring the Practical Impact of DNSSEC Deployment. In: USENIX Security, pp 573–588Google Scholar
- Ariyapperuma S, Mitchell CJ (2007) Security vulnerabilities in DNS and DNSSEC. In: The Second International Conference On Availability, Reliability and Security, 2007. ARES 2007. pp 335–342Google Scholar
- Bau J, Mitchell JC (2010) A Security Evaluation of DNSSEC with NSEC3. IACR Cryptol ePrint Archiv 2010:115Google Scholar
- Deccio C (2010) Quantifying the Impact of DNSSEC Misconfiguration. In: DNS-OARC Workshop (2). https://www.dns-oarc.net/files/workshop-201010/Casey-2010-10-14-dns-oarc-orig.pdfGoogle Scholar
- Verisign Labs and Internet Innovations: DNSSEC Analyzer—jdnssec-tools. http://www.verisignlabs.com/jdnssec-tools/. Accessed 02 Mar 2015
- NLnet Labs: ldns. http://www.nlnetlabs.nl/projects/ldns/. Accessed 02 Mar 2015
- Perez C Dnsrecon. https://github.com/darkoperator/dnsrecon. Accessed Jan 2014
- Verisign Labs and Internet Innovations: DNSSEC Analyzer. http://Dnssec-debugger.verisignlabs.com. Accessed 02 Mar 2015
- Google: Public DNS—Google Developers. https://developers.google.com/speed/public-dns/. Accessed 02 Mar 2015
- BIND: dig (domain information groper). ftp://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/man.dig.html. Accessed 04 Mar 2015
- Anonymous: DNS Census 2013. https://dnscensus2013.neocities.org/. Accessed 10 Mar 2015
- Team Cymru. IP to ASN Mapping. https://www.team-cymru.org/IP-ASN-mapping.html. Accessed 10 Mar 2015
- Elz R, Bush R (1996) Serial Number Arithmetic. IETF. RFC 1982 (Proposed Standard) (1996). http://www.ietf.org/rfc/rfc1982.txt
- Kalchev D DNSSEC Implementation in .BG. http://www.cctld.ru/files/pdf/Presentations_09-09/17-45_dnssec%20Bulgaria.pdf. Accessed Jan 2014
- Home-Dominios-Estatisticas. http://registro.br/estatisticas.html. Accessed Jan 2014
- Romero G (2013) DNSSEC Deployment in .CO. In: ICANN48 DNSSEC WorkshopGoogle Scholar
- Internet Infrastructure Foundation: Growth .se | .SE. https://www.iis.se/english/domains/domain-statistics/growth/. Accessed 01 2014