What is DNSSEC? How does it work?

What is DNSSEC?

Domain Name System (DNS) is a hierarchical and decentralized naming system used to identify computers on networks. It translates domain names such as www.bunny.net into an IP address like198.51.100.1, and vice versa.

DNS was designed in the 1980s, when the Internet was much smaller and security was not a primary consideration. As a result, there is no way to verify the authenticity of a DNS response. Computers only check if the DNS response comes from the same IP address the DNS request was sent to, which is not a strong authentication mechanism. An attacker can easily masquerade as a DNS server and modify DNS packets. This issue is worsened by the use of DNS cache, which speeds up the DNS responses but can store forged data. This type of attack is called DNS cache poisoning.

The Domain Name System Security Extensions (DNSSEC) is a package of specifications defined by the Internet Engineering Task Force (IETF) to secure data exchanged via DNS. The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

In short, DNSSEC protects applications using DNS from accepting forged or manipulated DNS data. All responses from DNSSEC protected zones are digitally signed. A DNS resolver checks the digital signature and confirms whether the data is identical, meaning unmodified and complete, to what the zone owner published and what an authoritative DNS server provided. In addition to the IP address, DNSSEC also protects other types of DNS data, including text records and mail exchange records. It can also be used to bootstrap other security systems, such as certificate records, SSH fingerprints, and IPsec public keys.

However, DNSSEC doesn't provide data confidentiality. DNSSEC also does not directly protect against DoS attacks, although it provides some indirect benefits due to signature checking, which helps determine trustworthy parties. These two concerns require additional security measures.

How does DNSSEC work?

DNSSEC works by providing digitally signed records for DNS lookup using public-key cryptography. It stores digital signatures on DNS name servers alongside common record types such as A, AAAA, MX, and CNAME. The correct DNSKEY record, which presents a public key, is authenticated through a chain of trust starting with a set of verified public keys from a trusted third party. Domain owners generate key pairs and upload public keys to their domain-name registrar, which then pushes the keys through secDNS to the zone operator. The operator signs and publishes them in DNS.

DNS is implemented using several resource records. To support DNSSEC, several new DNS record types were created and adapted:

• RRSIG stores the DNSSEC signature for a record set. DNS resolvers verify the signature using a public key stored in a DNSKEY record.
• DNSKEY stores the public key that a DNS resolver uses to verify DNSSEC signatures in RRSIG records.
• DS (delegation signer) holds the name of a delegated zone that references a DNSKEY record in the sub-delegated zone, along with the delegating NS records. It also stores the algorithm of the referenced DNSKEY record and the cryptographic hash algorithm used to create the hash value.
• NSEC (next secure record) stores a link to the next record name in the zone and lists the record types that exist for the record names. DNS resolvers use NSEC records to verify the nonexistence of a record name and type during DNSSEC validation.
• NSEC3 (next secure record version 3) stores links to the next record name in the zone and lists the record types that exist for the record names. These records can be used by resolvers to verify the nonexistence of a record name and type during DNSSEC validation. NSEC3 records are similar to NSEC records, but use cryptographically hashed record names to prevent enumeration of the record names in a zone.
• NSEC3PARAM (next secure record version 3 parameters) are used by authoritative DNS servers to calculate and determine which NSEC3 records to include in responses to DNSSEC requests for nonexisting names or types.

When DNSSEC is used, each DNS response includes an RRSIG record in addition to the requested record type. The RRSIG record is a digital signature of the answer DNS resource record set. The digital signature is verified using the correct public key found in a DNSKEY record. NSEC and NSEC3 records provide cryptographic proof of the nonexistence of any Resource Record (RR). The DS record authenticates DNSKEYs during the lookup process using the chain of trust. NSEC and NSEC3 records also offer strong protection against spoofing.

DNSSEC was designed to be extensible. When attacks are discovered against existing cryptographic algorithms, new ones can be employed without breaking the backward compatibility. Currently, the specification requires support for:

• RSA/SHA-1
• RSASHA1-NSEC3-SHA1
• RSA/SHA-256
• RSA/SHA-512
• ECDSA/SHA-256

RRsets

In DNSSEC, all records of the same type are grouped into a record set (RRset), and the full RRset is digitally signed rather than individual DNS records. This means you cannot validate a single record, only the entire RRset.

DNSSEC lookup

A security-aware DNS resolver can determine from the results of a DNS lookup whether the authoritative name server for the domain being queried supports DNSSEC, whether the answer it receives is secure, and whether there is some sort of error. The lookup procedure differs for recursive name servers, such as those used by many ISPs (Internet Service Providers), and stub resolvers, such as those included by default in mainstream operating systems.

Recursive name servers

Using the chain of trust model, a Delegation Signer (DS) record in a parent domain (DNS Zone) can be used to verify a DNSKEY record in a subdomain. This subdomain can then contain its own DS records to verify further subdomains.

• The process starts when a security-aware resolver sets the DO (DNSSEC OK) flag in a DNS query. Since the DO bit is defined by Extension Mechanisms for DNS (EDNS), all DNSSEC transactions must support EDNS, which also allows the use of larger packet sizes that are required for DNSSEC transactions.
• When the resolver receives an answer via the normal DNS lookup process, it checks to make sure the answer is correct. The security-aware resolver starts verifying the DS and DNSKEY records at the DNS root. Then it uses DS records for the net top-level domain found at the root to verify the DNSKEY records in the net zone. From there, it checks if there is a DS record for the bunny.net subdomain in the net zone, and if there is, then it uses the DS record to verify a DNSKEY record found in the bunny.net zone. Finally, it verifies the RRSIG record found in the answer for the A records for www.bunny.net.

There are two main exceptions. First, if bunny.net does not support DNSSEC, there will be no RRSIG record in the answer, and there will be no DS record for bunny.net in the net zone. Second, if the www.bunny.net domain does not exist, then instead of the RRSIG record, we get an NSEC/NSEC3 record in the reply.

Stub resolvers

A stub resolver can simply forward a request to a recursive name server and use the Authenticated Data (AD) bit in the response as a way to determine whether the recursive name server was able to validate signatures for all the data in the Answer and Authority sections of the response.

A validating stub resolver uses the Checking Disabled (CD) bit to perform its recursive authentication which gives the client end-to-end DNS security for domains implementing DNSSEC, even if the Internet service provider or the connection to them is not trusted. Non-validating stub resolvers must rely on external DNSSEC validation services, provided by ISPs or public recursive name servers and communicate between themselves and those name servers using methods such as DNS over TLS.

Trust anchors and authentication chains

To validate a DNS answer, a resolver must have at least one trusted key or DS record obtained from outside the DNS itself. These trusted starting points are known as trust anchors, and they’re typically distributed with the operating system or provided by other secure sources. Ideally, DNSSEC would require only a single trust anchor: the DNS root. However, some subdomains began implementing DNSSEC before the root zone was signed.

Signatures and zone signing

To combat replay attacks, RRSIG records include additional timestamps alongside standard DNS TTL values to limit a signature’s validity. Unlike TTL values, which are relative to when the records are sent, these timestamps are absolute. Consequently, security-aware DNS resolvers must have accurately synchronized clocks. Because of the time-based nature of RRSIGs, a DNS zone must be regularly re-signed and redistributed to secondary servers to maintain valid signatures and avoid rejection by resolvers.

Key management

DNSSEC relies on various keys stored in DNSKEY and from other sources to form trust anchors. To allow for replacement keys, a key rollover scheme is required. It first rolls out new keys in new DNSKEY records alongside the existing old keys. Then, once caches holding the old keys have expired, the new keys can be used. Finally, after all cached data using the old keys has expired, the old DNSKEY records can be deleted. This process is more complex for trust anchor keys, such as those at the root, since they may require operating system updates.

DNSKEY records generally use two types of keys. First, there are key signing keys (KSKs), which are used to sign other DNSKEY records. Second, there are zone signing keys (ZSKs), which are used to sign all other records. Particular DNS zones control specific ZSKs and consequently, they can be switched more easily and more often. As a result, ZSKs can be much shorter than KSKs and still offer the same level of protection while reducing the size of the RRSIG and DNSKEY records.

Each zone has a ZSK, where the private key is used to digitally sign each RRset in the zone, and the public key is used to verify the signature. Digital signatures of each RRset are stored in RRSIG records:

We need a public part of the ZSK to verify the signatures, so we store it in a DNSKEY record on a name server. DNSSEC resolver receives RRset and RRSIG as part of the response, and it also needs to receive the DNSKEY record containing the public part of ZSK from the name server. Once it has these three necessary components, it can validate the response:

If we trust the zone-signing key in the DNSKEY record, we can trust all the records in the zone it verifies.

Each server has a KSK. The private key is used to digitally sign the public ZSK stored in a DNSKEY record and to create an RRSIG for the DNSKEY:

The public part of the KSK is also stored in another DNSKEY record, where both the public KSK and the public ZSK are signed by the private KSK. DNS resolvers can then use the public KSK to validate the public ZSK.

The process of validation for resolvers is as follows:

• Request the desired RRset, which also returns the corresponding RRSIG record.
• Request the DNSKEY records containing the public ZSK and public KSK, which also returns the RRSIG for the DNSKEY RRset.
• Verify the RRSIG of the requested RRset using the public ZSK.
• Verify the RRSIG of the DNSKEY RRset using the public KSK.

DNSSEC uses DS records to transfer the trust from a parent zone to a child zone. A zone hashes the DNSKEY record containing the public KSK and gives it to the parent zone to publish as a DS record:

Every time a resolver is referred to a child zone, the parent zone returns the corresponding child zone DS record. The resolver compares the DS record from the parent zone with the hash of the public KSK from the child zone to verify the public KSK and we can trust all of the records in the child zone. This is how a chain of trust is established in DNSSEC.

The DS record is signed like any RRset and includes the corresponding RRSIG in the parent zone. The entire validation process repeats until the resolver reaches the parent's public KSK. To verify it, we need to go to that parent's DS record. To verify it, the resolver must check that parent’s DS record. This process continues up the chain of trust until it reaches the root DNS zone, which has no parent with a DS record to validate against. The root DNS zone is verified through the Root Signing Ceremony, a highly public and extensively audited process in which multiple third parties sign the root DNSKEY RRset.