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 DNSSEC (Domain Name System Security Extensions): 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 admins need to consider?
Unlike TLS-secured protocols, DNSSEC does not encrypt data over the wire; responses are authenticated via cryptographic signatures. A zone's records are grouped by name and resource record type (e.g. A, AAAA, NS, SOA, etc.) into a Resource Record Set (RRSet). RRSets are signed using the "Zone Signing Keys", a public/private key pair belonging to the zone. Each resulting digital signature is published as an "RRSIG" record within the zone file, and RRSIG records cover a specific resource record type. For example, www.example.com might have an A record 192.0.2.1 the AAAA record 2001:DB8::1. When the zone is signed, there will be two RRSIG records at www.dnssecexample.com: one for the A record, one for the AAAA record. Validating resolvers can verify these RRSIGs with the public "Zone Signing Key" or ZSK, which is advertised via a "DNSKEY" record -- a record type specifically developed to support DNSSEC. Successful verification indicates that the records were not forged/manipulated in transit, since only the zone owner or operator would have access to the private Zone Signing Key
"DNSKEY" records themselves are typically signed by another key pair within the organization, called a "Key Signing Key" (KSK). As you may expect, the resulting value is published as an RRSIG DNSKEY record. Validating resolvers can similarly authenticate this digital signature with the corresponding plaintext DNSKEY record that broadcasts the public Key Signing Key.
But why add the complexity of two key pairs? The reasoning becomes apparent once we understand how DNSSEC establishes a chain of trust. While ZSKs sign the RRSets, we need a way to sign the DNSKEYs themselves.. Otherwise, malicious actors could spoof DNS responses, returning their own DNSKEY records. To solve this problem, DNSSEC established the Delegation Signing (DS) record, which publishes a fingerprint of the public Key Signing Key in the parent zone. 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 model is maintained all the way to the root zone, which has corresponding 'Trust Anchors' built into most recursive resolvers.
Thus, two key pairs are used to ease the burden of management for the organization: 'Rolling-over' keys is a recommended security best practice to reduce the window for potential compromise, but updating the DS record with the Registrar can be a time-consuming and tricky process (more on this later). The ideal architecture from a security and operational perspective is to self-sign a frequently-rotated key pair with a more enduring, computationally expensive key pair. Consequently, zone admins rotate Zone Signing Keys frequently, while Key Signing Keys and their corresponding DS records are only updated periodically. This nimble implementation protects the zone against potential threats while ensuring the amount of required DNSSEC maintenance is sustainable.
While the techniques above describe how signatures of records can be validated, there's another important consideration: records that don't exist. If an attacker can forge an NXDOMAIN response for the name www.example.com, they can render the site unusable. DNSSEC protects against this through a new record type, the Next Secure (NSEC) record.
When a query is received for a nonexistent name, the NXDOMAIN response includes an NSEC record, indicating the "next" (in a canonical sorted order) record in the zone that does exist. 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". Like RRSIG records, NSEC records indicate the type of the next record in the zone. And like all records in a signed zone, NSEC records themselves are signed, and the signature is placed in an RRSIG NSEC record, where they can be validated using the ZSK.
Since NSEC records potentially expose all names in a zone, a variant called NSEC3 was developed, where the names of the next records are hashed in a way that is computationally infeasible to reverse.
Zone Administration Considerations
Unlike 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 resolvers will fail to return DNS responses if DNSSEC is setup incorrectly anywhere along the chain of trust. Consequently, executing a successful key rollover is essential to avoid a potential denial of service (DoS) event.
As mentioned, DNS admins can rollover Zone Signing Keys frequently since all required tasks reside within the organization. However, updating Key Signing Keys 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:
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 TTL is fully expired, the zone admin can delete the old KSK.
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.
If the extension is ultimately invisible to the end user, why enable DNSSEC? For one, today's treacherous 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.
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, Fast DNS offers unparalleled DDOS resilience and guarantees a 100% uptime SLA. Built on a distributed anycast network, Fast DNS retains sufficient capacity to absorb the largest attacks without sacrificing performance. Thus, enabling DNSSEC with Fast DNS simply adds a layer of integrity to an already performant and resilient DNS platform.
Explore Akamai's Diverse DNS Oriented Solutions
If you find 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:
New White Paper - Designing DNS for Availability and Resilience against DDoS Attacks is a white paper that explains how Akamai deploys Fast DNS with multiple vectors of global resilience.
Achieve domain stability and resilience with Akamai Fast DNS service.
Load balance your data centers, cloud deployments, and CDNs with Akamai's Cloud Based Global Server Load Balancing (GSLB) solution - GTM.
Massively scale your application with layer 7 load balancing with Akamai's Application Load Balancing (ALB) Cloudlet.
Ensure every device in your network checks a DNS security tool - ensuring the domain name resolved NOT malware, phishing, or a botnet. Akamai's Enterprise Threat Protection (ETP) and DNSi/SPS solutions turn your DNS resolver into a security tool.
Sign-up and Search Akamai's Community. This provides you access to a range of Akamai resources.
Use this form to ask for Akamai help. We can have someone contact you to help with your DNS questions.
 The private Zone Signing Key encrypts the hashed record set, generating the digital signature/RRSIG records
 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
 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.
 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
 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
 It is recommended to rotate Zone Signing Keys monthly, while Key Signing Keys are often rotated only once or twice a year