What Is DNSSEC, and How Does It Work?

Should I enable DNSSEC on my domain?

DNSSEC helps protect your domain against cache poisoning and answer forgery. It’s a crucial addition to your domain, because today’s digital climate demands that a website owner's architecture is protected from end to end — and a successful DNS attack can greatly damage a brand’s reputation. DNS resolution occurs before a user ever interacts with a website's application. If the DNS is intercepted by an attacker, a user looking to visit a website may interface with a fake site (intended to deceive the user) instead of the intended site. The protocol's aggressive caching architecture makes it difficult to quickly rectify poisoned records. 

Thus, even if a website is fortified by strong firewalls, an end user's data and technology will be at risk if a site’s DNS architecture isn't sufficiently protected with the usage of DNSSEC. 

Grouping DNS records into RRSets

Integrating DNSSEC with your domain begins with grouping DNS records by name and record type into resource record sets (RRSets). The DNS itself is split into DNS zones. A zone is a portion of the overall DNS namespace that gets overseen by the DNS owner’s overall organization or a network administrator. This zone allows for in-depth maintenance of DNS components, such as authoritative nameservers. 

Each zone is signed by a pairing of the public and private keys known as 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, then the zone file will advertise a corresponding RRSIG record for each IP version.

By isolating the DNS zones from one another, adjacent zones are protected in the off-chance that one zone becomes infected by an attacker.

Resource record signatures

An RRSIG record holds a digital DNSSEC signature of a RRSet. These digital signatures are used for authenticating any data that is located in the signed RRSets. Resolvers can verify the signature with a public key stored in a DNSKEY record.

These RRSets for record types and owned domain names are stored within a signed DNS zone. When a domain name server uses a ZSK pair’s private key to sign RRSets within a given zone, an RRSIG record is used to store the digital signatures of each RRSet. As such, a signed zone contains an RRSIG record for each RRSet.

An RRSIG record consists of these components:

• Type covered: the DNS record type covered by the RRSIG

• Algorithm: a cryptographic algorithm that generates the final signature

• Label count: the number of labels in the original RRSIG record name (used to validate wildcards)

• Original TTL: TTL value of the covered record set

• Signature expiration: the time at which the signature expires

• Signature inception: the time when the signature was initially created

• Key tag: a numeric value to identify the DNSKEY record used to validate this RRSIG signature

• Signer name: the name of the DNSKEY record used to validate this signature

• Signature: the cryptographic signature used to verify the transmission

Zone signing keys

A ZSK is a key for authenticating transmitted data. The ZSK is an aspect of the same RRSet as the key signing key (KSK), which has a corresponding private key to sign this DNSKEY RRSet. Each zone has a pair of ZSKs, and a DNSSEC-enabled zone will announce the public ZSK as a DNSKEY record so that resolvers can authenticate RRSIG values. 

DNSSEC validation does not distinguish between ZSKs and other DNSSEC authentication keys, making it possible to use one key as both a key signing key and ZSK. Successful verification indicates that DNS records were neither forged nor manipulated in transit, since only the zone administrator will have access to the private ZSK.

The ZSK corresponds to the private key used to sign a zone, and is usually part of the same RRSet as the signing public key that corresponds to the private key that signs this RRSet. 

Key signing keys

The KSK is a more computationally expensive key pair implemented to further improve the security posture of DNSKEY records. It was introduced to ease the burden of management for the zone administrator. The KSK corresponds to a private key, and is used to sign other authentication keys for a given zone. Typically, the private key corresponding to a KSK will sign a ZSK, which itself has a corresponding private key for signing other data found within the DNS zone. Resolvers will authenticate this digital signature with the pertinent plaintext DNSKEY record that announces the public KSK. 

KSKs and their corresponding delegation signer records are only updated periodically, as opposed to ZSKs, which update more frequently. Thus, the ideal architecture from a security and operational perspective is to self-sign a frequently rotated ZSK with a separate, more enduring KSK. This implementation would do more to protect the DNS zone against potential threats, while also minimizing the amount of ongoing DNSSEC maintenance.

Delegation signer records

DNSSEC established the delegation signer (DS) record to create a "chain of trust" model with public DNS resolvers. In these scenarios, malicious actors could theoretically spoof DNS responses and return a forged DNSKEY record that compromises the integrity of the zone. DS records publish a fingerprint of the public KSK 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 is maintained all the way to the root zone, which includes trust anchors built into most recursive resolvers. 

NSEC and NSEC3

The Next Secure (NSEC) record can be used to determine whether a name exists within a given zone. It was introduced to solve the problem of cases where records don't exist in a zone — often known as the ”denial of existence” authentication problem. Attackers could exploit this vulnerability and render a site unusable by forging an NXDOMAIN response for the website's hostname. 

The NXDOMAIN addresses this flaw by including an NSEC record that indicates the next canonical record in the zone that does exist when a query is received for a nonexistent name, 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, as 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.

NSEC3 was developed to address the problem of NSEC records being used to list all valid records in a zone. NSEC3 behaves identically to NSEC, except the next secure name in the zone is hashed, instead of being displayed in cleartext. This helps secure information and prevent zone walking.

DNSSEC modes of operation

Offline signing of static zones

There are many DNSSEC modes of operation, each with its own unique approach to how data in the DNS zone gets signed. Of these modes, one of the most common is offline signing of static zones, which enables strong protection for the signing system from external threats. This operating model retains any private keys found on a machine that isn’t currently connected to the network, and is effective in cases where information found in the DNS zone isn’t frequently being altered.

Centralized online signing

Centralized online signing is another recurring mode of DNSSEC operation. For cases where administrators are signing data in a dedicated, restricted-access DNS, centralized online signing enables DNS data to quickly be altered and published to the zone. As with offline signing of static zones, in centralized online signing, either a single or replicated central signer performs all the data signing. Then, the newly signed data circulates to the authoritative DNS servers.

On-the-fly signing

Signing data on the fly is a DNSSEC mode of operation that enables the authoritative DNS servers to sign data as needed. The problem with this approach is that it can create a situation in which the key exists on a variety of different machines, each with direct access to the internet — thereby introducing more avenues for outside access to the namespace by attackers. Key distribution — when a sender chooses a secret key value and then securely sends it to the receiver — is also made more complex by on-the-fly signing, and can unnecessarily increase computing requirements on each node.

Risks of incorporating DNSSEC

While DNSSEC is an invaluable way to increase network security, it can unintentionally introduce critical vulnerabilities. DNSSEC can increase the risk and amplify the effects of distributed denial-of-service (DDoS) attacks, where a server, service, or network is disrupted by traffic from multiple devices at once. DNSSEC increases the number of DNS query responses, because the technology requires additional fields and cryptographic information to properly verify records. This means that high-volume responses can afford malicious actors’ far greater attack volume against a zone than they could if DNSSEC was not in place.

Three-way handshake required

Since Transmission Control Protocol (TCP) is a connection-oriented protocol, it’s slow and requires a three-way handshake. As such, DNS (and, therefore, DNSSEC) relies on the User Datagram Protocol (UDP), a faster yet riskier protocol that neither has requirements for opening, maintaining, or terminating a connection, nor can guarantee delivery of signed data to its destination. UDP provides only the most basic error-checking functionality in the form of checksums, and since it requires no handshake, transmitted data can be easily intercepted by attackers.

UDP spoofing is when attackers craft a valid UDP request packet that lists their target’s IP address as the UDP source IP address. The attacker can then send the spoofed source IP to some intermediate server, which will send all its UDP response packets, thereby generating a response far larger than the request packet. This response is enough to elevate the level of attack traffic sent to the target’s IP address.

These circumstances also increase the length of DNS queries, which amplifies the severity of the attacks. The extent to which these attacks are amplified can be expressed as a ratio of the response size to the request size. For example, if an attacker sends a request of 64 bytes to a DNS server, they can generate more than 3,400 bytes of malicious traffic to be directed toward a chosen victim. 

Understanding the root-signing ceremony

A DNS root-signing ceremony is a rigorous procedure performed to sign the root DNS zone’s public keying information for the next few months. This process ensures that there will be less than a one-in-a-million  chance that a group of conspirators can compromise the root-signing key. It takes place at one of two locations that safeguard the root KSK. The private signing key used in this process is a key to unlocking the DNSSEC-secured internet.

Solving parentless root DNS zone issues

This ceremony solves the problem of parentless root DNS zones, meaning a zone that cannot be overseen for integrity by some parent zone. It requires a handful of participants, including a ceremony administrator, an internal witness, a credentials safe controller, a hardware safe controller, and three crypto officers. Each member is an Internet Corporation for Assigned Names and Numbers (ICANN) staff member, aside from the crypto officers who are volunteers from the internet community.

Accessing the credentials safe

There are two safes: the credentials safe and hardware safe. Both must be accessed to access the root key. The credentials safe controller opens the credentials safe, which contains safe deposit boxes — each of which requires two keys held by the ceremony administrator and a crypto officer. These boxes contain an operator card and security permissions card that are needed to open the hardware security module located in the hardware safe. The cards are stored inside plastic cases wrapped in tamper-evident bags, which are left in the credentials safe.

Opening the hardware safe

The hardware safe controller then enters the safe room and opens the hardware safe containing the hardware security module. The hardware safe also contains a laptop that has no battery or hard disk, and is designated for sending commands to the security module. This is what will be used to sign the root DNS keys in the ceremony, every aspect of which is meticulously recorded and live streamed out to the internet for the sake of posterity.

Engaging the crypto officers

Once the ceremony begins, the crypto officers must hand over their operator cards to the ceremony administrator, who boots the laptop from a DVD and initializes the USB that records the ceremony logs. This administrator then uses the three operator cards to activate the security module, which is then connected to the laptop via ethernet cable. The key-signing request is loaded into the laptop, and a PGP hash of the key-signing request is computed, which is then verified to ensure it’s identical to the provided hash. At this point, the ceremony administrator signs the key-signing request with the private KSK, which creates a collection of digital signatures: the RRSIG record. 

Implement DNSSEC today to bolster domain security 

All it takes is one successful DNS attack on your domain to permanently impact the integrity of your digital ecosystem, and the reputation of your brand as a whole. DNSSEC cryptographic signatures fortify the DNS resolution process to protect your domain from cyberthreats like cache poisoning and answer forgery. Ultimately, this enables end-to-end security for the data and technology of your organization and your end users. 

Explore Akamai's diverse DNS solutions

Akamai continues to expand our platform to enable a range of superior DNS services for domain owners:

• Achieve domain stability and resilience with Edge DNS service

• Load balance your data centers, cloud deployments, and CDNs with Global Traffic Management

• Massively scale your application with Application Load Balancing (ALB) Cloudlet

• Ensure that every device in your network checks a DNS security tool, and enable your DNS resolver to become a security tool with Secure Internet Access Enterprise

• Access a range of DNS resources by joining the Akamai community

• Are you a DevOps professional? Check out our developer community

• Need more help? Contact us today. 

Originally published March 19, 2021; updated June 2022.