DNSSEC: what it is, how it works, and what it’s used for

Have you heard of DNSSEC and want to gain a clearer understanding of how it works and its purpose? In this comprehensive overview, we’ll explore why DNSSEC was introduced and when it can be beneficial.

In simple terms, DNSSEC (DNS Security Extensions) enhances the security of the Domain Name System (DNS). It was developed because the DNS system has vulnerabilities that can be exploited for cyberattacks.

Let’s dive into why DNSSEC is crucial for securing websites and applications.

What is DNSSEC?

DNSSEC (Domain Name System Security Extensions) is a security protocol designed to make the DNS system more secure by authenticating the origin of DNS data.

In simple terms, the DNS system is what enables us to access websites by translating domain names (such as “supporthost.com”) into IP addresses.

While domain names are easy for people to remember, network communication relies on IP addresses to route information to its destination. Servers and devices connected to the internet must know these addresses for the exchange of data, whether it’s visiting web pages, sending emails, or transmitting information.

However, the DNS system is not inherently secure. To address these weaknesses, DNSSEC was created, providing a solution to the security problems within DNS.

What Is the problem?

The DNS system lacks an authentication mechanism, which means during the DNS resolution process (the step that translates a domain name into an IP address), there’s a risk of a DNS spoofing attack, also known as DNS cache poisoning.

Spoofing occurs when a network host’s identity is falsified. For example, an attacker could exploit this flaw to redirect users from a legitimate website (e.g., “sitolegitimate.com”) to a malicious one (e.g., “sitefasullo.com”).

Despite its importance, DNSSEC remains unfamiliar to many. The vulnerabilities in DNS were identified as far back as the 1990.

Although attempts were made to secure the system, they were largely unsuccessful. A preliminary version of DNSSEC (called DNSSEC-bis) was created in 2005, but it wasn’t until 2010 that ICANN officially rolled out DNSSEC to effectively address these authentication issues.

To fully understand how DNSSEC works, it’s essential to first grasp the fundamentals of how the DNS system functions.

How the DNS system works

The DNS (Domain Name System) resolution process, which translates a domain name into its corresponding IP address, involves several key steps, as outlined in the DNS guide.

Here’s a simplified breakdown of the process:

1. I connect to a website, such as “domain.com.”
2. The browser (acting as the client) sends a request to the DNS resolver.
3. The DNS resolver functions as an intermediary, responsible for retrieving the IP address associated with the domain name.
4. To do this, the resolver sends requests to various servers, including the root server, the TLD (Top-Level Domain) server (in this case, for “.com”), and the authoritative nameserver for “domain.com.”
5. Once the DNS resolver obtains the correct IP address, it sends this information back to the browser, which can then load and display the content of the website.

This is the basic DNS resolution process. An important part of this system involves DNS records.

DNS records (which we have covered in the DNS propagation guide) are stored in a DNS zone file, contain critical information such as the IP address. For example, the IP address can be stored in an “A record” for IPv4 format, or in an “AAAA record” for IPv6. These records ensure the correct routing of traffic on the internet.

With this basic understanding of the DNS system, we can now move on to explore how DNSSEC works.

How the DNS system works with DNSSEC

DNSSEC (DNS Security Extensions) adds an additional layer of security to the DNS system. Alongside the usual exchange of information between the DNS resolver and various servers, DNSSEC introduces cryptographic signatures into the process.

These digital signatures ensure that the information exchanged is verified, protecting against interference from malicious actors, such as those attempting a man-in-the-middle attack.

A quick explanation: a man-in-the-middle attack happens when a third party intercepts and manipulates communication between two entities. In the case of websites, the HTTPS protocol, as opposed to HTTP, encrypts communication to protect the exchange of sensitive information.

Similarly, DNSSEC uses cryptographic keys to ensure the authenticity of domain records, preventing the insertion of false records during the DNS resolution process.

For example, during DNS resolution, if records are altered by a third party, the request could be directed to a different DNS server, leading to a different IP address and ultimately a different website.

One of the main risks of this type of attack is being redirected to a malicious site designed to steal sensitive information, such as login credentials or payment details.

The validation of information with DNSSEC is done like this:

1. A request is sent from a browser to visit the “domain.com” site.
2. The request goes to the DNS resolver.
3. The DNS resolver queries the DNS servers: root zone, TLD zone for “.com” and the nameservers of “domain.com”.
4. In this case, since DNSSEC is enabled, during the information exchange in addition to communicating DNS records, the digital signature is also transmitted and validated.
5. Therefore, the resolver, in order to validate the request, must also perform a check on the digital signature. The validation is done through key pairs with the Public Key Cryptography (PKC) system (similar to the validation of SSL certificates).
6. To finish, the validated response returns to the browser showing the content of the requested website or resource.

In practice, authenticating the validity of servers with DNSSEC ensures that there can be no man-in-the-middle attacks.

This is broadly how DNSSEC works. Let us now turn to a more in-depth view.

How DNSSEC works in detail

To go into more detail, let us see how verification works. This type of validation always consists of a private key and a public key.

If you want to first delve into the mechanism of Public Key Cryptography, you can read this introductory resource on RedHat’s PKC (in English).

Two keys called DNSKEYs are introduced: KSK and ZSK. Let’s see what they are used for.

ZSK

The ZSK, Zone Signing Key, is used to validate the DNS zone.

For example, the following DNS zone allows a domain to be connected to an IP with the A record:

domain.com A 9.9.9.1

An RRSIG record is then created, using the ZSK public key to validate the DNS zone.

At this point, we need to be sure that the public ZSK is valid and really associated with “domain.com,” and then we need to validate it in turn through the KSK.

KSK

A public Key-Signing key (KSK) is used to validate the other key, the ZSK.

Due to the presence of KSKs, you enter what has been called the “chain of trust” or chain of trust. This chain is used to validate information on multiple levels.

As we said, DNS resolution involves:

• Root server.
• TLD server.
• “domain.com” server.

A DS (Delegation Signer) record associated with the TLD server is introduced, the content of which is the hash of the KSK.

The hash is obtained by transforming one string into another with an encryption algorithm.

That way, when the DNS resolver queries the “domain.com” server and gets the KSK, it can compare the KSK with the DS record of the TLD and make sure they match.

The same thing happens at the top level. The root server has a DS record that points to the TLD. The KSK of the TLD is compared to this DS record for validation.

This chain validation causes each level to be validated.

If you’re looking for more technical details about blockchain validation that will help you understand the specific steps involved in transmitting and validating information, you can refer to this resource by Daniel Benway, which includes a video in English.

What DNSSEC does

Now that we’ve covered how DNSSEC works, let’s clarify its purpose and when it’s essential to use it.

DNSSEC serves three main functions:

1. It validates the source.
2. It checks the integrity of the data.
3. It enables authenticated “denial of existence.”

The validation of the source and the integrity of the data is carried out through the process we discussed earlier, using DNSKEYS keys.

For authenticated “denial of existence,” the process works like this: if I search for a subdomain, such as “test.supporthost.com,” DNSSEC will return a response that confirms the subdomain does not exist.

This is made possible by a verification process in which the server explicitly responds that the subdomain is nonexistent. The NSEC record is used to perform this verification.

How DNSSEC is implemented

First, the DNS Zone must be validated. This involves creating the necessary records—ZSKs, KSKs, and RRSIGs—that we mentioned earlier.

Once the keys and records are set up, they need to be tested to ensure no errors are present.

Finally, the DS record is established to enable full validation. DNSSEC becomes fully active only after the DS record is set.

If you’re a SupportHost customer, you can follow the tutorial to activate DNSSEC in just a few steps.

Who needs DNSSEC

Although DNSSEC isn’t yet widely adopted, it is designed to ensure the validity of websites and applications, and its use will likely become more widespread over time.

So, do you need it? Should everyone use it?

If you handle sensitive data—such as banking or medical information—or operate in environments where data security is critical and the risk of attacks is high, then yes, you should seriously consider activating this additional layer of security as soon as possible. The risks associated with not doing so have been extensively discussed throughout this article.

Have you heard of DNSSEC before? Do you still have any questions? Feel free to share your thoughts in the comments.