Hot Topics
Security Bloggers Network 
SBN

DNSSEC: How It Works & Key Considerations

by Sam Preston on June 12, 2019

From its beginnings as a replacement for a centralized database, the Domain Name System (DNS) has evolved into a dynamic, highly distributed, question-answer protocol. The proverbial “phone book of the internet” has increased in complexity and scale alongside the rapid growth of the World Wide Web. One primary example is Domain Name System Security Extensions (DNSSEC). The founding architects of DNS did not include any inherent security protections for the protocol, an omission that eventually proved untenable as attackers discovered opportunities to forge records and direct users to fraudulent websites. DNSSEC was thus introduced to add a layer of authenticity and integrity to DNS responses. But how does it work? And what technical realities do zone administrators need to consider? 

 

DNSSEC Basics

Unlike TLS-secured protocols, DNSSEC does not encrypt data over the wire. Instead, responses are authenticated via cryptographic signatures. Records in a DNS zone are grouped by name and record type (e.g., A, AAAA, NS, etc.) into Resource Record Sets (RRSets), which are signed by a public/private key pair called the zone signing key (ZSK). The resulting signature is published as an RRSIG record in the zone file itself. For example, if the hostname www.dsnsecexample.com includes both an A and AAAA record, the zone file will advertise a corresponding RRSIG record for each IP version. A DNSSEC-enabled zone will also announce the public ZSK[1] as a DNSKEY record so resolvers can authenticate RRSIG values. Successful verification indicates that DNS records were not forged/manipulated in transit since only the zone administrator will have access to the private ZSK. To further improve the security posture, DNSKEY records are signed by another, more computationally expensive, key pair, called the key signing key (KSK). Resolvers will authenticate this digital signature with the pertinent plaintext DNSKEY record[2] that announces the public KSK.

 

DNS Image One.PNG

However, without an established “chain of trust” model with public resolvers, malicious actors could theoretically spoof DNS responses and return a forged DNSKEY record to compromise the integrity of the zone. To solve this problem, DNSSEC established the delegation signer (DS) record, which publishes a fingerprint of the public KSK in the parent zone (e.g., .com or .net).[3] During validation, the resolver will ensure the DS record of the parent zone matches the corresponding DNSKEY record of the child zone to authenticate the legitimacy of the child’s key pair. This chain of trust is maintained all the way to the root zone,[4] which includes trust anchors built into most recursive resolvers. 

Why sign the DNSKEY record with a separate key pair? The aforementioned KSK was introduced to ease the burden of management for the zone admin. “Rolling over” keys is a recommended security best practice to reduce the window for potential compromise. However, updating the DS record with the Registrar can be a cumbersome undertaking. Thus, the ideal architecture from a security and operational perspective is to self-sign a frequently rotated key pair (ZSK) with a separate, more enduring key pair (KSK). Consequently, zone admins rotate ZSKs frequently, while KSKs and their corresponding DS records are only updated periodically.[5] This shrewd implementation protects the zone against potential threats while minimizing the amount of ongoing DNSSEC maintenance.

DNS Image Two.PNG

Finally, while the techniques above describe signature validation, there’s another important consideration: records that don’t exist. Simply put, an attacker can render a site unusable by forging an NXDOMAIN response for the website’s hostname. DNSSEC protects against this attack vector by introducing the Next Secure (NSEC) record. When a query is received for a nonexistent name, the NXDOMAIN response will include an NSEC record indicating the “next” (in a canonical sorted order) record in the zone that does exist, as well as the type of records appearing at that name. For example, if the “example.com” zone were sorted, and “beta.example.com” was the first record, a query for “alpha.example.com” would result in an NXDOMAIN and an NSEC record pointing to “beta.example.com.” NSEC records, like any other records, are signed by the ZSK and have a corresponding RRSIG. As a result, an NXDOMAIN response requires an authenticated RRSIG NSEC record to be valid.

Because NSEC records can potentially be used to “walk” a zone, and list all valid records in it, an alternative version called NSEC3 was developed. NSEC3 behaves identically to NSEC, except the next secure name in the zone is hashed, instead of being displayed in cleartext.

Zone Administration Considerations

Unlike with HTTPS, the end user has no visibility into whether a DNS response was verified by DNSSEC, nor is there a means of forcing all queries to leverage the extension in the browser. DNSSEC enablement is completely dependent on zone enforcement and resolver compatibility. That said, proper implementation is paramount, as strict validating resolvers will fail to return DNS responses if DNSSEC is implemented incorrectly anywhere along the chain of trust. Consequently, executing a successful key rollover is essential to avoid a potential denial of service (DoS) event.

DNS admins can rollover ZSKs frequently since all required tasks reside within the organization. However, updating KSKs requires modifying the DS record of the parent zone, a more complicated process involving an external party (typically the Registrar). There are two recommended approaches to successfully execute this:

  1. Dual Signing: The zone admin can sign the ZSK with both old and new KSK key pairs. From there, the zone owner needs to work with the registrar to update the DS record. Once this is complete and the old DS record time to live (TTL) is fully expired, the zone admin can delete the old KSK.
  2. Dual DS: In this scenario, the parent zone will actually advertise a DS record for the old KSK and the new KSK. After this is in place, the zone admin can replace the old KSK key pair with the new version. Finally, once the TTL fully expires for both the old DS and the old KSK DNSKEY record, the old records can be removed.

In both cases, the caching realities of the DNS protocol need to be considered, as ignoring the TTLs of the applicable DNS records can result in a corruption of the chain of trust — an unfortunate miscue that will render a website inaccessible to the public.

Why DNSSEC?

If the extension is ultimately invisible to the end user, why enable DNSSEC? For one, today’s digital climate demands that a website owner’s architecture is protected end to end; DNS resolution occurs before a user ever interacts with a website’s application, and if DNS is hijacked, the user may end up interacting with an imposter site instead of the intended endpoint. Thus, even if your website is fortified by the strongest web firewalls, your end user’s data is at risk if your DNS architecture is not protected. Successful attacks can be extremely harmful to brand reputation, and the protocol’s aggressive caching architecture makes it difficult to quickly rectify poisoned records. In addition, while DNSSEC validation may be invisible to the end user today, browsers may develop transparent means of indicating the extensions’ availability in the near future. Some top-level domains (such as “.bank”) require the use of DNSSEC. Just like TLS, DNSSEC may become an implicit requirement, expected by end users and digital services alike.

Edge DNS

While DNSSEC prevents DNS forgery via public key encryption, the extension increases the size of the zone file. Consequently, nameservers may exhaust more bandwidth responding to queries, leaving DNSSEC-enabled zones more susceptible to DNS flood attacks. Fortunately, Akamai Edge DNS offers unparalleled DDoS resilience and guarantees a 100% uptime SLA. Built on a distributed anycast network, Edge DNS retains sufficient capacity to absorb the largest attacks without sacrificing performance. Thus, enabling DNSSEC with Edge DNS simply adds a layer of integrity to an already performant and resilient DNS platform.

Explore Akamai’s Diverse DNS Oriented Solutions

If you found this blog useful, continue your exploration with these references. Everything Akamai deploys depends on our Intelligent Edge DNS Platform. Akamai expands our platform to enable a range of services for domain owners:

______________________________________________

[1] The private Zone Signing Key encrypts the hashed record set, generating the digital signature/RRSIG records

[2] All DNS records are also available in plaintext (eg. not signed) in the zone file, alongside the RRSIG records. This ensures non-DNSSEC enabled resolvers can retrieve answers

[3] The RRSIG DNSKEY  includes this DNSKEY record as well. i.e both DNSKEY records, pubZSK and pubKSK, are signed by the privateKSK to create the RRSIG DNSKEY.

[4] In other words, the DS record for akamai.com (child) is published in the .com namespace (parent); similarly, the DS record for .com is published at the root

[5] Along with every other record in the zone, the DS record itself is signed by the privZSK; for example, the DS record for akamai.com is published in the .com zone and is signed by .com’s privZSK; Thus, .com has an RRSIG DS Record, which is validated via the same process outlined above (hence the chain of trust); the same process exists at the root, where the DS record for .com is signed by the root’s privZSK

[6] It is recommended to rotate Zone Signing Keys monthly, while Key Signing Keys are often rotated only once or twice a year


Recent Articles By Author
More from Sam Preston

*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Sam Preston. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/k3Be8bNwE0I/dnssec-how-it-works-key-considerations.html

Sam Preston