why dnssec is not popular?

It would be easy to make the argument that DNS is perhaps one of the most critical protocols on the Internet. The service, which resolves unintelligible IP addresses to easily readable domain names, is in use by every single Internet user today. It’s the reason you can hit http://www.apnic.net/ rather than an IP address such as 104.20.59.194.

Unfortunately, DNS is inherently weak in its design. The early Internet never anticipated a hostile global network that also ran critical business operations. DNS is susceptible to a range of easy attacks, from simple denial of service to serious hijacking and cache-poisoning attacks.

Given how critical DNS is to the functioning of the Internet, it’s a mystery that the world is prepared to accept such a security-deficient protocol at the core of all its infrastructure. What’s even crazier is that there’s a secure solution that’s been in the pipeline for over a decade: DNS security extensions, or DNSSEC.

DNSSEC defines “security extensions” that can be used to validate any domain record right back to top-level name servers. Using DNSSEC, a user querying http://www.myawesomebankonline.co.au/ can be assured that the returned IP address will actually point to their bank, and not some malicious domain under the control of a hacker or scammer.

The case for security

In the mid 1990s, the first banks migrated from remote access via dedicated dial-up terminals to wide-scale access over the Internet. This roughly coincided with the introduction of a secure HTTP protocol (HTTPs) by Netscape Communications. It was clear that the changing capabilities of the Internet required security and protocols to evolve too.

Only the most sensitive data was initially secured. But, over time, everything from password data to the user’s personal information started to shift under the HTTPs umbrella. Today, no sane corporate or commercial Internet business would implement a new online solution (especially a financial one) without securing the connection between users and services.

The case for security is obvious — when you log in to your bank to enter secret passwords and financial data, you want to make absolutely sure that you’re really talking to your bank and not some imposter. HTTPs makes it impossible for a scammer to impersonate another site — well, almost.

When a user connects to a secure server, they’re presented with that server’s public key, and a signed certificate that authenticates the keys. But, what if I could redirect your request to my own server and never bother to send you any public keys at all? If I force you to talk over plain HTTP, then serve up a compromised website, would you fall for it?

Because you’re on an unsecured site, there’s no reason for your browser to check for certificates: no errors, no warnings, and no security. As an end-user, the onus is on you to check the ‘padlock’ on the URL to make sure everything is secure. A momentary lapse in concentration — and you’ve keyed in your password and become the victim of a phishing attack.

DNS Swiss Army Knife

The explosion of DNS record types further supports the case for DNS security. No longer does DNS simply return web server and mail exchange records for a domain — its flexibility has also seen it become the Swiss Army Knife of online directory services.

The flexible nature of DNS has seen it evolve to provide everything from address records to mail exchangers; IPSEC and TLS keys; SSH keys; SRV records, which point to specific servers and ports; and text records that can be crammed with email sender policies and other protocol and site specific data.

In fact, most domain-validation SSL certificates rely on DNS security to verify site ownership in the first place. The certificate authority might extract owner information from Whois data, but ultimately most of them ping a site or send an email to servers listed in that domain’s DNS record.

Attacking the DNS

Redirecting traffic to malicious sites is surprisingly easy to do. DNS works by sending a record request for a domain or host and then listening for a reply. Because the system is distributed, most likely the initial query will need to be sent to another server to be fulfilled. DNS queries chain together until a server can be located that explicitly declares “I am the authority for the domain you requested!”.

See also: YouTube Animation: How the DNS works

Unfortunately, these DNS interactions don’t happen over controlled connections, but over stateless UDP. The query is broadcast into the void, and the response is blindly sent back with no authentication or verification.

This opens the door to a range of hijack and cache poisoning attacks that can occur. An attacker inserted in a local network can simply intercept and alter DNS requests, while a remote attacker could spray a continuous stream of bogus data at a DNS server hoping to confuse legitimate replies with malicious ones. Admittedly, some of these attacks are more difficult and can be militated against, but these defences all lack the cryptographic certainty of signing and verifying records.

So it seems obvious that every website owner should switch on DNSSEC for their domains ASAP. If users can be assured they’re connecting to validated IP addresses, a whole range of cyber-attacks become much more difficult to orchestrate.

See also:  DNSSEC – Protecting Your Good Internet Name

Problem solved

So, it’s settled. You’ll enable DNSSEC for your domain records, right? Well, even that’s not so easy.

Unfortunately, the uptake of DNSSEC is less than stellar. In a quick scan of my local Australian financial institutions, I found zero uptake of DNSSEC. A look at the ICANN report on domain name registrars that support DNSSEC for .com.au and .net.au is similarly depressing.

For DNSSEC to work, the top-level domains need to be signed, and the registrars also need to support signing of DNSSEC keys. The security must flow down from the root keys in an unbroken chain to the record sets and hosts listed for a domain; any break in continuity and the DNS records cannot be validated.

So, while ICANN mandates that “Registrar must allow its customers to use DNSSEC upon request…” nearly all registrars (while technically compliant), offer no support for creating, maintaining and signing DNSSEC keys and records.

So now what?

Unfortunately, the DNSSEC rollout is creeping along at glacial pace. The case for DNSSEC doesn’t appear to be strong enough to force corporate users to demand their registrars take the issue seriously.

For the time being, the best we can hope for is to increase awareness of DNS security problems. We also need more corporate and commercial end-users to implement DNSSEC where possible, and put pressure on their domain registrars to improve support. Without awareness and demand, we will never reach the critical mass required to make secure DNS a reality.

Until users, software developers and domain administrators are conditioned to expect DNSSEC to be present, the hit-and-miss nature of half-baked implementations will mean that returning no records to a DNSKEY request will confuse matters — is the site’s domain really unsecured, or has the cache already been poisoned?

Nikolai Hampton holds a Master’s Degree in Cyber Security and is a director of Impression Research. He consults on matters of privacy, security, digital forensics, and incident response. His focus is on the correct application of cryptography and he is passionate about educating business on complex security issues.

DNS is the foundational component of the internet yet it has no strong security mechanism to assure data integrity and authentication. Domain Name System Security Extensions (DNSSEC) provide these services to security-aware resolvers or applications using cryptographic signatures. DNSSEC is designed to thwart the most common attacks on DNS, such as DNS hijacking, DNS amplification, and DNS poisoning.

Despite being introduced two decades ago, the adoption of DNSSEC is very slow, especially in the second-level domains where the adoption rate remains steady at roughly 5%. The primary reasons for slow adoptions are complexities in the initial setup and ongoing maintenance.

The Domain Name System (DNS)[1], [2] is a crucial component of the Internet. It enables communication using domain names that are easier to remember than numerical IP addresses. In essence, DNS is a distributed database for looking up data, based on domain name and query type, that maps human-readable hostnames to IP addresses.

Modern DNS is not only useful to end-users but also essential to other core network technologies, including telephone number mapping, SIP, email, spam filtering, and directory services. The beginnings of the DNS were a lot more modest. Its original design from 1983 focused on scalability and did not include any security considerations. As it originally did, DNS continues to rely on plain text files and unencrypted UDP-based communication.

Flaws in DNS were identified and discussed in the early 1990s[3]. The Domain Name System Security Extensions (DNSSEC) was published in 1997 and further refined in 2005.[4] The Domain Name System (DNS) security extensions provide origin authentication and integrity assurance services for DNS data, including mechanisms for authenticated denial of the existence of DNS data[4]. To ensure authentic replies, DNSSEC relies on cryptographic keys. Private keys are used for digital signatures generated for resources and can be verified by their public counterparts.

Initially, DNSSEC adoption was very slow. It picked up around 2011 and reached its peak in 2014. Ever since then, DNSSEC adoption has been going down. In this paper, we will attempt to understand why.

DNS, DNSSEC, Datagram, DNS Zone, RRSIG, DNSKEY

DNS was born out of an observation, made in 1982, that the ‘HOSTS.TXT’ text file-based system for mapping between hostnames and IP addresses was not scalable. As the number of computers connected to the Internet was rapidly growing this issue became very apparent. On the modern *nix systems, the file is still present and is located at /etc/hosts. The file structure is fairly straightforward as shown in Fig. 1

Fig.1 Structure of /etc/hosts used for local DNS resolution

As Fig.1 demonstrates, to set up a translation for the small number of places that were available at the beginning of the Internet, a network address followed by a space and followed by the name entry was all that was needed.

The HOSTS.TXT was centrally maintained on a computer at the Stanford Research Institute Network Information Center (SRI-NIC) and distributed to all computers on the Internet via file transfers[1]. That model did not fit the trend towards more of the distributed management of the Internet. At the time, the internet was transforming rapidly, moving away from the original ARPANET to the TCP/IP-based network. The net result of this transition was that the number of hosts, which originally was roughly equal to the number of the connected organization, grew rapidly and became roughly equal to the number of workstations (users).

That increase directly affected the size of the HOSTS.TXT and the number of transfers. As a result, the costs associated with managing the system grew exponentially and organizations were forced to invest significant resources into managing network addresses, names, etc. It became apparent and quite logical that some sort of a partitioning system was needed to allow local control of the local names and address space.

RFC 882 and RFC 883 specify the original design of the DNS. [5], [6]. Although DNS went through several transformations, the current specifications and usage are quite similar to the original design. [7], [8]. DNS design base assumptions were and are:

As one can notice, no security assumptions were made in any shape or form. [1]

There are three major components used for DNS: the namespace, Name Servers (NS), and Resolvers.

-The namespace is a tree-structured entity, where each branch of the tree is called a domain. Each domain is a collection of resource records (RRs) that maps hostnames to IP addresses and other information. DNS queries are attempts to retrieve specific resource records from a particular domain.

-Name Servers(NS) are repositories of information and answer DNS queries based on the information they possess. Name Servers host the namespace.

-Resolvers interface with client programs and implement routines needed to find the correct NS that holds the information needed by the client.

Note: Name servers and resolvers can be combined into a single entity.

DNS RRs are organized into what is known as the zone file. Like the original HOSTS.TXT, the zone file is also just a specially formatted plain text file. Name Servers for the same domain have the same copy of the zone file distributed to them. Changes to the zone file are typically what triggers zone transfers, i.e zone file distributions.

Every zone file has what is called an SOA record, also known as the Start of Authority. There could be only one SOA record per zone. However, there are multiple Resource Records (RRs) of various types per zone. Fig. 2 provides an example of the complete zone file for the fictional example.com domain.

Fig. 2 example.com very basic zone file

To speed up the name resolution process and reduce congestion, DNS uses UDP protocol as its transport by default, with TCP being used as a failback. Failback to TCP occurs when the request or the response is greater than a single packet.

The iPv4 standard specifies that every host must be prepared to reassemble packets of 576 bytes or less [9]. IPv4 header, when using options might be as large as 60 bytes. UDP header is 8 bytes. Total DNS UDP packet size is normally 512 bytes[10],[8]. Once IPv6 adoption completes globally, the minimum size of the UDP payload for DNS messages would become 1232 bytes[10].

DNS namespace is a very hierarchical tree-structured system as illustrated in Fig. 3

Fig. 3 DNS Namespace hierarchy.

At the very top of the tree sits the root domain “.”. The first level below is referred to as Top-Level Domains, with their subdomains known as Second-level domains. The deeper into the tree, the more partitions the DNS database splits into. Overall, 13 Name Servers are serving the root zone[11]. The Root Zone file provides delegation information for top-level domains. Fig. 4 illustrates the section of the root zone file responsible for the microsoft.com domain delegation.

Fig. 4 Microsoft.com delegation information from the root zone file (http://www.internic.net/domain/root.zone)

As original DNS design assumptions did not include any security considerations, DNS is inherently not secure. In the early 1990s, Steve Bellovin of AT&T Bell Laboratories wrote a paper titled “Using Domain Name System for System Break-ins”. However, he did not publish it until 1995. In his paper, he described several attacks that relied on DNS. His work only underscored DNS’s susceptibility to attacks like hijacking and cache poisoning. However, the formal Threat Analysis of the Domain Name System (DNS) was only published 9 years later in RFC 3833 [12].

According to RFC3833, members of the DNS working group had a meeting in November of 1993 which is recognized as the earliest organized work on Domain Name System Security Extensions (DNSSEC). As a result of this meeting, outlines of the DNSSEC design considerations became apparent [12]:

In addition, during this meeting, the team made an explicit decision that DNS data is to remain publicly available and ruled out data disclosure threats explicitly out of scope for DNSSEC.

The first DNSSEC RFC, RFC2065, was published in 1997. In that document, DNSSEC was defined as a mechanism to assure data integrity, authentication, and storage of authenticated public keys. The stored keys enabled security-enabled resolvers to learn the authenticating keys of zones in addition to the zones that they are configured for. The keys associated with DNS names can be used for the support of other protocols as well.

There are 3 distinct services provided by DNSSEC:

DNSSEC is very explicitly designed to provide the same answers to all inquirers. Therefore, no attempts have been made to differentiate inquirers using access control lists or other means. DNSSEC does not provide any confidentiality for queries and responses as well.

DNSSEC relies on cryptographic mechanisms to verify the integrity and authenticity of DNS records. Each zone needs to provide three record types to achieve the said goals [13]:

A typical DNS query sequence is illustrated in Fig. 5

Fig. 5 Traditional DNS request sequence

A DNSSEC enabled DNS query sequence is illustrated in Fig. 6

Fig. 6 DNSSEC-enabled DNS query sequence

As seen in the illustrations, DNSSEC adds 14 additional steps compared to the traditional DNS request sequence. These extra steps are derived from the DNSSEC hierarchical public key infrastructure, which establishes a chain of trust to mirror the structure of the DNS hierarchy, where the root of trust is in the DNS root zone[13]. The overall process of trust verification is very similar to the x509 trust chaining.

DNSSEC is ultimately invisible to the end-user as DNS resolution occurs before a user ever interacts with an application. In cases of the hijacked DNS, the user may end up interacting with an impostor instead. Therefore, even if the endpoint is protected by the strongest firewall, end-users data is at risk if DNS architecture is not protected. In the future, DNSSEC may join TLS in becoming an implicit requirement, expected by the end-users and digital services.

Despite the importance, DNSSEC adoption is not yet at 100%. Fig. 7 illustrates the current trend of DNSSEC adoption [14]. As one can observe from the data, despite being introduced in 1997, adoption didn’t really start until the second half of 2010. It remained below 200 signed Top Level Domains (TLDs) up until 2014. In 2014 the adoption rate rapidly accelerated, peaking in 2017. Ever since the trend remained constant if not sloping downward slightly.

Fig.7 Current DNS adoption trend.

Internet Societies report on the state of DNSSEC deployment in 2016 [15] indicated that only 89% of top-level domain zones signed with only around 47% of country-code TLDs.

4 years later, as of January 2020, the % of TLDs signed in root is still at 90% and only 4% of second-level domains signed [14]. The current statistics are shown in Fig. 8 below.

Fig. 8 % of signed domains as of January 2020.

What makes DNSSEC adoption so challenging? Turns out, it almost has nothing to do with a query latency or performance. In our test comparing name resolution for DNSSEC-enabled domain vs. not-enabled one, the latency penalty was negligible compared to the overall length of the transaction. Fig. 9 shows DNS resolution time for the DNSSEC-enabled and properly-configured domain ‘internetsociety.com’ with DNSSEC (+dnssec flag) and without it. Although the real-time for the DNSSEC-enabled query is 2x of the not DNSSEC-enabled one, 254ms vs. 122ms, the overall perceived impact on a typical web transaction remains negligible.

Fig. 9 DNSSEC vs DNS name resolution times.

If performance is not a real factor, then challenges must be attributed to other aspects of the system like initial configuration complexity and ongoing maintenance and support.

To begin, 512 bytes afforded by the default DNS specified maximum UDP message size is no longer enough due to the added burden of added digital signatures in each response while performing trust validation [16]. In some extreme cases, the response could be so large that it gets fragmented. Many firewalls are configured to block fragments, effectively blocking name resolution. This issue is especially apparent when RSA-based signatures are used.

The complexity of DNSSEC implementation very often results in misconfigurations. A misconfiguration of DNSSEC deployment can result in a broken chain of trust. There are 6 most common misconfigurations [17]:

DS Mismatch: if the child zone DNSKEY does not match DS RRs in the parent zone, the chain of trust will be broken and RRs in the child zone and below are deemed bogus.

DNSKEY Missing: if a DNSKEY referenced in RRSIG or DS is needed to complete the chain of trust but it is missing, the chain of trust is broken.

RRSIG Missing: If an authoritative server is missing RRSIGs for a given RRset, the chain of trust is broken.

RRSIG Mismatch: results in a broken chain of trust.

RRSIG Validity Period Mismatch: If RRSIG is presented outside of its validity dates, the chain of trust is broken.

NSEC Missing: NSEC is needed to confirm the non-existent domain. It is critical to insecure delegations for proving that no DS RRs exist for the child zone, thus the chain of trust is broken and it will fail validation.

Uploading a DS record to the parent zone requires it to be passed to the registry. However, domain owners are not allowed to interact with the registry directly: only a registrar, an organization certified by ICANN to sell domains, has the authority to access the registry. The registrar must provide the NS and the DS record set. The situation becomes even more complicated for the organization that outsources DNS hosting to a third party.

In their paper, Van Andrichem et al performed a detailed analysis on DNSSEC misconfiguration [18].

The group analyzed 122,779 signed domains from .bg, .br, .co, .com, .nl and .se domains and their findings were quite revealing. Fig. 10 illustrates the data they’ve collected on misconfigurations found in those TLDs.

Fig.10 DNSSEC misconfiguration distribution.

As one can observe, almost 30% of the domains in those zones had their DNSKEY missing and 10% had failed DNSKEY validation by the DS. 25% had their Zone Signing Key (ZSK) invalidated by the Key Signing Key(KSK), indicating an unsuccessful key rollover attempt that has not been noticed by the domain owner yet.

Fig. 11 Shows the effect of these misconfigurations caused in the said domains' reachability where only 26% of domains were reachable [18].

Fig. 11 Availability of DNSSEC misconfigured domains.

RRSIGs have a limited time span and must be periodically updated. Updating RRSIG requires re-signing of RRsets they cover as RRSIG is added to the zone for each of the resource records that were present before zone signing.

DNSKEYs technically do not expire. However, it is a good security practice to periodically replace them. To ensure disruption-free service, it is recommended to maintain at least 2 DNSKEYs. Rolling over a DNSKEY involves coordination with the owners of the parent zone [19], [20].

Despite the shortcoming identified here in the DNSSEC CHALLENGES section, DNSSEC has the support needed to become the de facto mechanism to provide key distribution, data origin authentication, and transaction and request authentication. However, 23 years since its introduction, it faces the same set of challenges as it did on day one. Cryptographic bootstrapping and key rollover problems remain critical open questions.

The issues outlined here have been noticed by the DNSSEC community. The work to improve and accelerate DNSSEC adoption, especially for the second-level domains, is ongoing. Only real security in the internetworking environment can be achieved with cryptography [3]. DNSSEC directly addresses that by designing a hierarchical PKI. However, current complexities in deployment and ongoing maintenance are the primary factors affecting the widespread DNSSEC adoption.

The main focus of future work should be on reducing complexity and reducing maintenance costs. Adopting IPv6 should help with the issues caused by packet fragmentation [21].

[1] P. V. Mockapetris and K. J. Dunlap, “Development of the Domain Name System,” p. 11.

[2] P. V. Mockapetris, “Domain names - implementation and specification.” [Online]. Available: https://tools.ietf.org/html/rfc1035. [Accessed: 08-Mar-2020].

[3] S. M. Bellovin and T. B. Laboratories, “Using the Domain Name System for System Break-ins,” p. 11.

[4] M. Larson, D. Massey, S. Rose, R. Arends, and R. Austein, “DNS Security Introduction and Requirements.” [Online]. Available: https://tools.ietf.org/html/rfc4033. [Accessed: 08-Mar-2020].

[5] “RFC 882 - Domain names: Concepts and facilities.” [Online]. Available: https://tools.ietf.org/html/rfc882. [Accessed: 13-Mar-2020].

[6] “RFC 883 - Domain names: Implementation specification.” [Online]. Available: https://tools.ietf.org/html/rfc883. [Accessed: 13-Mar-2020].

[7] “RFC 1034 - Domain names - concepts and facilities.” [Online]. Available: https://tools.ietf.org/html/rfc1034. [Accessed: 13-Mar-2020].

[8] “RFC 1035 - Domain names - implementation and specification.” [Online]. Available: https://tools.ietf.org/html/rfc1035. [Accessed: 13-Mar-2020].

[9] “RFC 791 - Internet Protocol.” [Online]. Available: https://tools.ietf.org/html/rfc791#section-2.2. [Accessed: 13-Mar-2020].

[10] “UDP payload size for DNS messages.” [Online]. Available: https://tools.ietf.org/id/draft-madi-dnsop-udp4dns-00.html. [Accessed: 13-Mar-2020].

[11] “IANA — Root Servers.” [Online]. Available: https://www.iana.org/domains/root/servers. [Accessed: 13-Mar-2020].

[12] “RFC 3833 - Threat Analysis of the Domain Name System (DNS).” [Online]. Available: https://tools.ietf.org/html/rfc3833. [Accessed: 13-Mar-2020].

[13] T. Chung et al., “Understanding the role of registrars in DNSSEC deployment,” in Proceedings of the 2017 Internet Measurement Conference, London, United Kingdom, 2017, pp. 369–383, DOI: 10.1145/3131365.3131373.

[14] R. Lamb, “DNSSEC Deployment Report.” [Online]. Available: http://rick.eng.br/dnssecstat/. [Accessed: 15-Mar-2020].

[15] “State of DNSSEC Deployment 2016,” Internet Society. [Online]. Available: https://www.internetsociety.org/resources/doc/2016/state-of-dnssec-deployment-2016/. [Accessed: 15-Mar-2020].

[16] Gijs van den Broek, Roland van Rijswijk-Deij, Anna Sperotto, and Aiko Pras, “DNSSEC Meets Real World: Dealing with Unreachability Caused by Fragmentation.” [Online]. Available: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6828880. [Accessed: 22-Feb-2020].

[17] C. Deccio, “Maintenance, mishaps and mending in deployments of the domain name system security extensions (DNSSEC),” International Journal of Critical Infrastructure Protection, vol. 5, no. 2, pp. 98–103, Jul. 2012, DOI: 10.1016/j.ijcip.2012.05.002.

[18] N. L. M. van Adrichem et al., “A measurement study of DNSSEC misconfigurations,” Security Informatics, vol. 4, no. 1, p. 8, Oct. 2015, DOI: 10.1186/s13388-015-0023-y.

[19] J. Ihren, J. Dickinson, and S. Morris, “DNSSEC Key Rollover Timing Considerations.” [Online]. Available: https://tools.ietf.org/html/rfc7583. [Accessed: 15-Mar-2020].

[20] W. (Matthijs) Mekking and O. M. Kolkman, “DNSSEC Operational Practices, Version 2.” [Online]. Available: https://tools.ietf.org/html/rfc6781. [Accessed: 15-Mar-2020].

Confusion, complexity, and incompatibility are likely barriers to organizations adopting comprehensive DNSSEC deployment policies. DNSSEC was developed in the 1990s yet much of the internet infrastructure does not support it. Fewer than 20% of all DNS services support DNSSEC.