What is DNSSEC?

What is DNSSEC? The Domain Name System Security Extensions (DNSSEC) suite is used to strengthen DNS protocol security because the DNS protocol is by design not secure.

In a nutshell, a server offering DNSSEC for its zones and records allows:

1. verification of the integrity of each record
2. validation that the record originates from the authoritative DNS server for the record (authenticity)
3. validation that the DNS server is trusted by upper domain in the DNS hierarchy (chain of trust)

The DNSSEC Big Picture

DNSSEC comes on top of the standard recursion process used during resolution. It uses the opposite path, from the record up to the root zone during the validation process, as shown on the diagram on the left.

DNSSEC helps prevent DNS attacks like DNS cache poisoning and DNS spoofing. DNSSEC does not protect the entire server, it only protects the data exchanged between signed zones. For memory, DNSSEC is not providing privacy.

By providing origin authentication, DNSSEC protects the DNS information exchanged between name servers configured with DNSSEC. DNSSEC ensures data protection from one signed zone to the other, whether the answer to the request is successful or not.

DNSSEC is based on public key cryptography, certificates and digital signatures.

The global picture of components and records is presented on the left diagram.

The process of certification is mainly based on digital signature. Each record is supplemented by its signed hash version which can be used by the client or the recursive DNS server to verify the record. Public keys are published in records to allow the requester to validate signatures using the principle of digital signature: private key used to produce a signature that can be validated using the public key.

Integrity of DNS records

DNSSEC controls the integrity of records gathered in DNS answers. Once receiving a DNS answer from a request on a record, the client can validate the integrity of this record. It is possible to validate the integrity of records provided from a cache or from an authoritative answer.

Integrity control is based on cryptography using signatures: a hash of the record signed with the private key can be verified with the public key, the record and the signature. The signature is applied to a hash of the record, allowing signature on any kind of record of any length.

Each DNS zone has a key set (public and private parts – the ZSK) that is used to sign the records contained within the zone. The private part of the key is kept secured by the zone owner. The public part is published as a record (DNSKEY ZSK – id 256).

For each record of the zone, a specific record signature is also published in the zone – the RRSIG record. This record is published in order for the client to validate the integrity of the answer content. The content of the RRSIG record is a signature of the record hash.

The verification process guarantees that the record has been signed with the ZSK in the zone:

1. get the A record using DNS query, calculate the hash
2. get the public key of the Zone Signing Key using DNS query (DNSKEY ZSK)
3. get the signature of the record using DNS query (RRSIG A)
4. verify the signature using the public key, the hash and the signature

Authenticity of DNS records

DNSSEC ensures that client queries are answered by the proper zone. In order to be sure the key used to sign the record is valid and associated with the legitimate zone, we use the following verification process:

1. get the public Key Signing Key of the zone using DNS query (DNSKEY KSK)
2. get the signature of the Zone Signing Key public key record using DNS (RRSIG DNSKEY ZSK)
3. verify the signature of the ZSK with the public key of the KSK
4. from the KSK public key, build the hash that creates the DS record
5. get the DS record from the upper zone using DNS
6. compare DS contained in upper zone and hash, should be the same

Chain of Trust

In order to ascertain the DNS record signature is fully valid, we can reiterate the validation through the DS record up to the DNS root servers. Since all domains are linked together in the DNS hierarchy, the KSK key of each is reported in the DS record of the upper domain. The root domain cannot be validated through the same principle since the DS key is not stored in another domain. The content of the root anchor keys should be gathered through another channel.