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 to 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 in its design. As a result, there is no way to verify the authenticity of the DNS response. Computers only check if the DNS response comes from the same IP address as 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 amplified with the use of DNS cache to speed up the DNS responses, which can store forged data. This type of attack is called DNS cache poisoning.

The Domain Name System Security Extensions (DNSSEC) is a package of extension specifications defined by the Internet Engineering Task Force (IETF) for securing 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 was designed to protect 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 if the information is identical (unmodified and complete) to the information published by the zone owner and served on an authoritative DNS server. Besides the IP address, DNSSEC also protects any data published in the DNS, including text records and mail exchange records and can be used to bootstrap other security systems (e.g. certificate records, SSH fingerprints, and IPSec public keys).

However, DNSSEC doesn't provide confidentiality of data. All DNSSEC responses are authenticated, but not encrypted. Also, DNSSEC does not protect against DoS attacks directly, though it indirectly provides some benefits, due to signature checking determining trustworthy parties. So, these two requirements require additional security services.

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 with a chain of trust starting with a set of verified public keys for a trusted third party. Domain owners generate their key pairs and upload public keys to their domain-name registrar, which then pushes the keys through secDNS to the zone operator, who signs and publishes them in DNS.

DNS is implemented with the use of several resource records. To implement DNSSEC, several new DNS record types were created and adapted:

• RRSIG stores the DNSSEC signature for a record set. DNS resolvers verify the signature with 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, the cryptographic hash algorithm used to create the hash value itself.
• 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's names. DNS resolvers use NSEC records to verify the non-existence of a record name and type as part of 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's names. These records can be used by resolvers to verify the non-existence of a record name and type as part of DNSSEC validation. NSEC3 records are similar to NSEC records, but NSEC3 uses cryptographically hashed record names to avoid the 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 non-existing names/types.

When DNSSEC is used, each answer to a DNS lookup contains an RRSIG DNS record, in addition to the record type that was requested. The RRSIG record is a digital signature of the answer DNS resource record set. The digital signature is verified by locating the correct public key found in a DNSKEY record. The NSEC and NSEC3 records are used to provide cryptographic evidence of the non-existence of any Resource Record (RR). The DS record is used in the authentication of DNSKEYs in the lookup procedure using the chain of trust. NSEC and NSEC3 records are used for robust resistance against spoofing.

DNSSEC was designed to be extensible, so when attacks are discovered against existing cryptographic algorithms, new ones can be employed without breaking the backward compatibility. Currently required by the specification are:

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

RRsets

In DNSSEC all the records of the same type are grouped into a record set (RRset) and this full RRset gets digitally signed, as opposed to each DNS record. This means you are not able to validate an individual record but only RRsets.

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 of 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, which can then contain other DS records to verify further subdomains. For example, a recursive resolver such as an ISP name server wants to get the IP address (A record and/or AAAA record) of the domain www.bunny.net:

• 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 DNSSEC transactions require.
• When the resolver receives an answer via the normal DNS lookup process, it then 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 replay.

Stub resolvers

A stub resolver can simply forward a request to a recursive name server and uses the Authenticated Data (AD) bit in the response as a way to find out 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 prove that a DNS answer is correct, one needs to know at least one key or DS record that is correct from sources other than the DNS. These starting points are known as trust anchors and are typically obtained with the operating system or via other trusted sources. Ideally DNSSEC would need only one trust anchor that is the DNS root, however, certain subdomains started using DNSSEC before the DNS root did.

Signatures and zone signing

To combat replay attacks, additional timestamps in RRSIG records are used in combination with the normal DNS TTL values for caching, that limit the validity of a signature. Unlike TTL values which are relative to when the records were sent, the timestamps are absolute. Consequently, the security-aware DNS resolvers must have clocks that are closely in sync. Due to these timestamps, a DNS zone must be regularly re-signed and re-distributed to secondary servers to maintain valid signatures and not be rejected by the resolvers.

Key management

DNSSEC involves many different keys, stored both in DNSKEY records 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, in addition to the existing old keys. Then, after the caching of old keys has expired, these new keys can be used. Finally, after the caching of records using the old keys has expired, the old DNSKEY records can be deleted. This process is more complicated in the case of keys of trust anchors, such as at the root, which may require an update of the operating system.

DNSKEY records typically work with two types of keys. First, there are key signing keys (KSK) which are used to sign other DNSKEY records. Second, there are zone signing keys (ZSK) which are used to sign 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/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 them in a DNSKEY record on a name server. DNSSEC resolver gets RRset and RRSIG as part of the response and then it needs to also receive the DNSKEY record of the public part of ZSK from the name server. When it has these three necessary parts 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 where the private key is used to digitally sign the public ZSK stored in a DNSKEY record and create an RRSIG for the DNSKEY:

The public part of the KSK is also stored in another DNSKEY record, where both public parts of the KSK and the 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 with the public ZSK.
• Verify the RRSIG of the DNSKEY RRset with 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 provides a corresponding child zone DS record. The resolver compares the DS record from the parent zone with the hash of 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 just like RRset and also has the corresponding RRSIG in the parent. The whole validation process repeats until we get to the parent's public KSK. To verify it, we need to go to that parent's DS record. So we go up the chain of trust until we reach the root DNS zone, which does not have a parent with the DS record to validate against. The root DNS zone is verified with the Root Signing Ceremony from multiple third parties that sign the root DNSKEY RRset in a very public and highly audited way.