What Is DNSSEC, and How Does It Secure Your DNS?

The DNS (domain name system) is the backbone of the Internet. It enables core functionalities like mapping IP addresses to domain names that are so commonly used today.

Unfortunately, the DNS system was designed in more friendly days where the internet was not yet a minefield of threats like viruses and scams. That is why it lacks any kind of security.

Bad actors use this to their advantage to waylay unsuspecting users into the wrong websites and dupe them into downloading system-compromising software. This is possible due to the interception of DNS traffic and the injection of incorrect data into it, which is known as a man-in-the-middle attack.

DNSSEC is a DNS security protocol that aims to remove the inherent vulnerabilities in the DNS system by enabling the verification of information as well as its source. In this article, we will check out exactly how that works.

Constituents of DNSSEC

For DNSSEC to work, the resolver and DNS systems must be DNSSEC capable. You will see later in this article that a DNSSEC-capable resolver can do a lot more than a standard resolver. DNSSEC-capable systems are backward compatible, so they can work with non-DNSSEC systems, but they will not be able to extend their security features to them.

What is DNNSEC?

The DNSSEC protocol uses a mixture of hashing and public key cryptography to verify DNS records and their source. DNS records are basically text files that contain all the information required for the functioning of the DNS.

For example, an A/AAAA record contains information about the IP address belonging to a domain name. So, when a request comes to a DNS server asking for the IP address of the domain, it consults the A/AAAA record to find the IP and returns it to the client.

For more information on DNS and how it works, refer to this article.

In standard DNS implementations, there are no ways to verify that DNS records came from the right source (authoritative nameserver) or if their contents have been altered. An attacker can simply fabricate records in a DNS system to divert traffic to malicious websites where they can fool people into compromising their information and devices.

DNSSEC introduces a few new components that enable the verification of DNS records and their sources. Those new components include the following:

• RRSET: Stands for Record Set. A record set is a set of all DNS records of the same type. So, if there was a domain with multiple A records, they would all be bundled in one RRSET.
• RRSIG: Stands for Record Signature. An RRSIG record accompanies an RRSET and contains the cryptographic signature that is used to verify the authenticity of the RRSET.
• DNSKEY Record: It contains the public key that is used to verify the RRSIG.
• DS Record: Contains the hash of the DNSKEY record with the key signing key (KSK). More on that later, but just know that it is used to delegate trust from a parent domain to a child domain.

There are other records added by DNSSEC as well, but the four we have listed are the ones most crucial for its implementation. So, let us check out how DNSSEC works.

How Does DNSSEC Work?

Since DNS is a hierarchical system, DNSSEC naturally works on different hierarchies. We will first start our discussion in the same hierarchy, i.e., a single level.

Creating Trust Within a Zone

Let us start from the top. A DNS has administrative zones. Each zone deals with one domain. So, in each zone, there is a DNSSEC zone signing key (ZSK) pair. One is a private ZSK only held by the zone admin, while the public ZSK is published in a DNSKEY record.

The private ZSK is used to sign an RRSET, thereby creating its RRSIG record. The RRSIG is stored in the domain nameservers. The nameservers are the highest authority, and all records published in them are inherently trustworthy.

Now, what happens when a DNS resolver asks the nameserver for any record is that the nameserver sends both the record and the RRSIG. The resolver sees the RRSIG and also pulls the DNSKEY record with the public key in it. It uses the public key to verify that the signature was made using the corresponding private key.

This entire exchange shows two things:

• The record is trustworthy. It has not been tampered with.
• The record comes from the correct source, i.e., nobody has inserted themselves between the resolver and the nameserver to send fake records.

However, if that was the extent of it, then DNSSEC would not be too secure because it is possible that the ZSK was also compromised. After all, how can a resolver be sure that the published ZSK in the DNSKEY record is valid or not?

To counter this vulnerability, there is another keypair in DNSSEC: the Key Signing Key or KSK. The KSK is used to verify a DNSKEY RRSET. The private KSK signs the public ZSK and creates its RRSIG.

The public KSK is published in another DNSKEY record. Resolvers first use the public KSK to verify the ZSK, and then the ZSK is used to verify the actual record they requested.

Zone admins can also manually check their public keys by using a DNSKEY record lookup tool. This can help them verify that the public keys have been propagated to DNS servers around the world without being compromised.

Chain of Trust Between Parent and Child Zone

Only establishing trust within a zone still leaves one security flaw, and that is that the KSK also signs itself, which is not really trustworthy. There is a need to bring trust from a higher authority (i.e., the parent zone) to the current zone (the child zone).

So, how is this done? Well, this is where the DS record or the delegation signer record comes into play. In the parent zone, the DNS zone admin hashes the DNSKEY record containing the KSK. This hash is stored in a DS record in the parent zone.

When a resolver queries the parent zone and the parent zone relegates it to a child zone, it also provides the DS record. The resolver then checks the KSK of the child zone and creates a hash of it. If the hash matches that of the DS record, the resolver knows that the KSK is intact and that the parent zone trusts the child zone.

This means that the resolver can trust all records in the child zone. Of course, the question still remains whether the KSK of the parent zone is trustworthy or not. In most cases, the parent itself is the child zone of another. This is true for all servers in the DNS hierarchy except for the root-level zones.

The root zones do not have parent zones because nobody is higher than them in the hierarchy. This is where the root signing ceremony comes in.

The DNS root signing ceremony is a periodic event where cryptographic keys used to secure the Domain Name System (DNS) root zone are generated, updated, and stored securely. It ensures the integrity and authenticity of the DNS infrastructure, which is crucial for secure internet communication.

Conclusion

Now, you know how DNSSEC secures the DNS system. It uses a mixture of hashing and public key cryptography to sign the data in the DNS system. The verification of these signs indicates that the data is uncompromised and is from a valid source.

ZSKs sign the DNS records, while the KSKs sign the DNSKEY record with the ZSKs. DS records delegate trust from parent zones to child zones, and the root signing ceremony creates and signs the private key for securing the root zones. In this way, the DNSSEC protocol secures the entire DNS system.