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
22.214.171.124. It runs on the IANA-reserved port
53/udp (and to a lesser extent,
The original DNS protocol has little security guarantees: data can be intercepted, modified, and fabricated (spoofed) undetected.
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
DS– stands for Delegation Signer, which contains the hash, hash algorithm a short numeric value in reference to a
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
NSECrecord, but with cryptographically hashed record names to prevent enumeration of the record names in a zone.
NSEC3PARAM– used to determine which
NSEC3records 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 126.96.36.199 www1 86400 IN A 188.8.131.52 www1 86400 IN A 184.108.40.206 www2 86400 IN A 220.127.116.11 www2 86400 IN A 18.104.22.168 www8 86400 IN A 22.214.171.124 mail 86400 IN MX 10 126.96.36.199 mail 86400 IN MX 20 188.8.131.52
For example, in the records above, there will be 3 resultant RRset objects generated: one for
A records, another for
A records and one for
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.
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
(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
For each DNS record that a resolver wishes to validate, the following actions are performed:
- The corresponding RRset and
RRSIGrecords are requested.
DNSKEYrecords containing the KSK and ZSK are requested, as well as the
DNSKEYRRset (to verify the ZSK).
DNSKEYRRset for the public ZSK is validated using the public KSK (
DNSKEYrecord for ZSK is verified)
RRSIGof the RRset for the DNS record is validated using the public ZSK (
RRSIGrecord for RRset is verified)
This gives us a two-step verification process, where the second step is repeated for each
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
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.
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
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
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.
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.