DNSSEC: A Primer – Rayden & Security

About DNS

The Domain Name System (DNS) was proposed by American computer scientist Paul Mockapetris in 1983, who was at UC Irvine at that time. DNS was created to solve the maintainability and scalability issues of a local hosts file. Today, DNS is one of the core protocols of the Internet, providing a mapping between names for endpoints on the Internet to their Internet Protocol (IP) addresses. This allows you to enter into your browser memorable strings such as google.com, instead of IPv4 addresses like 172.217.10.110. It runs on the IANA-reserved port 53/udp (and to a lesser extent, 53/tcp)

The original DNS protocol has little security guarantees: data can be intercepted, modified, and fabricated (spoofed) undetected.

About DNSSEC

In comes DNSSEC, a set of extensions to the DNS protocol, aimed at addressing a number of its security issues. It is fairly complex with three RFCs: RFC4033, RFC4034, RFC4035. Its main concern is to help DNS clients (resolvers) authenticate DNS responses.

DNSSEC introduces several new Resource Record (RR) types to the DNS protocol:

RRSIG – the cryptographic signature for a resource record set (RRset) (more on it later)
DNSKEY – the public key that a resolver uses to verify DNSSEC signatures in RRSIG records
DS – stands for Delegation Signer, which contains the hash, hash algorithm a short numeric value in reference to a DNSKEY record
NSEC – a reference to the next DNS record name in the zone, as well as the record types that exist for that name. It is used to verify denial-of-existence (that some record does not exist) of a record type and name.
NSEC3 – similar to an NSEC record, but with cryptographically hashed record names to prevent enumeration of the record names in a zone.
NSEC3PARAM – used to determine which NSEC3 records are required for denial-of-existence responses.

Grouping resource records

DNS records are not signed individually; instead, they are grouped into resource record sets (called an RRset) with records bearing the same label and resource record type.

#Domain TTL   Class Type Priority Host
www1    86400 IN    A            1.1.1.1
www1    86400 IN    A            1.1.1.2
www1    86400 IN    A            1.1.1.3
www2    86400 IN    A            1.1.2.1
www2    86400 IN    A            1.1.2.2
www8    86400 IN    A            1.1.8.1
mail    86400 IN    MX  10       2.2.2.1
mail    86400 IN    MX  20       2.2.2.2

For example, in the records above, there will be 3 resultant RRset objects generated: one for www1 A records, another for www2 A records and one for mail MX records. The implication is that verification must be done on all records with the same label and type, and not on individual records.

Establishing Zone Trust

For a resolver to trust the DNS responses it receives, it needs to cryptographically verify the records using digital signatures. For this purpose, each DNS zone has two pairs of public/private keys, known as the Zone Signing Key (ZSK) and the Key Signing Key (KSK). Signing is performed by the DNS server, and verification is performed by the resolver.

Signing

The private ZSK is used to sign all RRset objects in the zone where each digital signature is placed in an RRSIG record, and the public ZSK is placed in a DNSKEY record so that resolvers can use it to verify RRSIGs.

\begin{alignedat}{2} &\text{Signing an RRset:} \\ &\quad \text{RRSIG}_{i} = \text{Encrypt}(\text{ZSK}_{priv}; \text{RRset}_i) \end{alignedat}

(Recall that in asymmetric/public key cryptography, encryption using a private key can only be decrypted using its corresponding public key, and it is used to prove authenticity, integrity and non-repudiation. Conversely, anything encrypted using a public key can only be decrypted with its corresponding private key, and is used for confidentiality.)

The KSK validates the ZSK by signing the DNSKEY record (public ZSK), and the resultant signature is placed in another DNSKEY record.

\begin{aligned} &\text{Signing the ZSK:} \\ &\quad \text{RRSIG}_\text{ZSK}^\text{DNSKEY} = \text{Encrypt}(\text{KSK}_{priv}; \text{DNSKEY}_\text{ZSK}) \\ &\text{where} \\ &\quad\text{DNSKEY}_\text{ZSK} = \text{ZSK}_{pub} \end{aligned}

Verification

For each DNS record that a resolver wishes to validate, the following actions are performed:

The corresponding RRset and RRSIG records are requested.
The DNSKEY records containing the KSK and ZSK are requested, as well as the RRSIG for the DNSKEY RRset (to verify the ZSK).
The RRSIG of the DNSKEY RRset for the public ZSK is validated using the public KSK (DNSKEY record for ZSK is verified)
The RRSIG of the RRset for the DNS record is validated using the public ZSK (RRSIG record for RRset is verified)

This gives us a two-step verification process, where the second step is repeated for each RRset:

\begin{aligned} 1.&\quad \text{DNSKEY}_\text{ZSK} = \text{Decrypt}(\text{DNSKEY}_\text{KSK}; \text{RRSIG}^\text{DNSKEY}_\text{ZSK})\\ 2.&\quad \text{RRset}_i = \text{Decrypt}(\text{DNSKEY}_\text{ZSK}; \text{RRSIG}_i)\\ &\text{where} \\ &\quad\text{DNSKEY}_\text{KSK} = \text{KSK}_{pub}\\ &\quad\text{DNSKEY}_\text{ZSK} = \text{ZSK}_{pub} \end{aligned}

Establishing Hierarchical Zone Trust

DNS is hierarchical in nature, and zones are usually dependent on one another. Previously, we have seen that in a DNS zone, the KSK establishes trust for the ZSK using an RRSIG, but how do we trust the KSK, which is self-signed?

Enter the Delegation Signer (DS) record, which connects the trust in some zone with its parent zone. A zone operator (who administrates the zone) hashes the DNSKEY record of the public KSK. This hash is then passed to the parent zone operator, who publishes it as a DS record. For example, the operator of zone A computes

\text{DS}^A = h_\text{KSK}^A = \text{Hash}(\text{DNSKEY}_\text{KSK}^A )

Whenever a resolver is referred to a child zone by its parent zone, the DS record for the child zone is supplied by the parent, which signals that the child zone has DNSSEC enabled. Verification of the child zone KSK is then done by hashing and comparing it to the DS record supplied by the parent zone. This is the hashes match, then the resolver can operate on the assumption that the DNSKEY record for the KSK has not been tampered with, and that the records of the child zone can be trusted.

However, this makes swapping out a KSK much more difficult than swapping out a ZSK. To swap out a KSK, the DNSKEY record has to be replaced, and the hash of the new public KSK has to be added by the parent zone operator as a DS record; the old DS record can only be deleted when the TTL expires, otherwise this will cause DNSSEC verification errors when the hashes do not match.

Authenticated Denial-of-Existence

The NSEC and NSEC3 (“Next Secure”) records helps authenticate an NXDOMAIN reply, which is when the hostname or domain in the query does not exist. Without an authenticated denial-of-existence response, resolvers can be hit with a denial-of-service attack by spoofing NXDOMAIN replies.

In the example zone file above, when querying for the non-existent name www5, the DNS server would send a NSEC record containing www8, which means that A records between www5 and www8 do not exist. NSEC records are signed and can be verified in the same manner as an RRset. However, this allows for zone enumeration – so NSEC3 records were developed in RFC 5155, which hashes the names then sorts them in lexicographical order. Since the resolver knows the hash algorithm (in this case SHA1), the original assertion is verifiable.

Conclusion

Like any other RRset, DS records in the parent zone are signed as well. This creates a chain of trust when we recursively validate the DNSKEY record for the public KSK and the DS record in the parent zone.