What is DNSSEC? How does it work?
Overview of the Domain Name System Security Extensions
Overview of the Domain Name System Security Extensions
Domain Name System (DNS) is a hierarchical and decentralized naming system used to identify computers reachable through the internet or other networks. It translates domain names such as www.bunny.net to an IP address A.B.C.D 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. We can only check if the DNS response has come 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 now 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 in the DNS in Internet Protocol (IP) networks. 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. DNS resolver is now able to check the digital signature and confirm 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, to provide these two requirements additional security services need to be used.
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:
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:
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.
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:
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 and using such validation 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 for example ISPs or public recursive name servers and communicate between themselves and those name servers using methods such as DNS over TLS.
To be able 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.
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.
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 KSK is also stored in another DNSKEY record, where both public parts of KSK and ZSK are signed by the private KSK. DNS resolvers can then use public KSK to validate public ZSK.
The process of validation for resolvers is as follows:
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.
Domain Name System. A protocol that resolves names to IP addresses that devices can use to contact other servers.
The layer of the OSI model that supports applications and web-pages.
A service that resolves domain names into network addresses.