DNSSEC: Securing Your Domain Name 🔐

If you own a domain name, you’ve undoubtedly heard of the DNS: the key infrastructure that brings life to websites. But are you familiar with DNSSEC?

In this article, we’ll first take a look at how the DNS system works and its vulnerabilities, before exploring why implementing the DNSSEC protocol is essential to securing your domain name.

How DNS servers work

What is the DNS system?

The DNS, or Domain Name System, can be compared to a huge web directory made up of many servers, listing all Internet addresses and their corresponding IP addresses.

The process of translating a domain name (netim.com) into an IP address (172.66.43.171) is called DNS resolution. To better understand, here’s a simplified version of the steps involved:

1. 1. When you access netim.com, your browser (the network client) sends a request to the DNS resolver.
   2. The DNS resolver queries the DNS servers.
   3. First, the root servers which direct the request to the appropriate TLD servers;
   4. Then, the TLD servers (the registry’s servers responsible for the extension) that manage top-level domains such as .com, .org or .fr, and redirect to the authoritative servers (or name servers);
   5. And finally, the authoritative servers (or name servers) which contain all the accurate information about the queried domain (A, MX, CNAME records, etc.) and return the corresponding IP address.

What are the vulnerabilities of the DNS?

The DNS system we’ve just described has governed the entire Internet network since 1985. As such, you can imagine that the stakes and risks have evolved over the years.

Today, several threats jeopardise the authenticity of DNS responses, aiming to falsify or redirect them to incorrect, often malicious IP addresses. This is known as DNS Spoofing. Here are the two main DNS spoofing methods:

DNS Cache Poisoning

The terms DNS cache poisoning and DNS spoofing are often used interchangeably. In fact, we could say that DNS spoofing is the ultimate goal of cache poisoning.

DNS cache poisoning is an attack that injects false data into the DNS resolver’s cache. So, when a user initiates a query, the wrong IP address is returned.

The cybercriminal can thus set up a website that is almost visually identical to the original, prompting you to log in, in order to steal your information (login credentials, password, personal data, etc.). This is known as phishing.

Man-In-The-Middle Attack (MITM)

The “man-in-the-middle” cyberattack results in the same outcome as DNS cache poisoning: DNS spoofing. The only difference lies in the method used.

The MITM attack intercepts a DNS query in transit between the resolver and the client (for example on an unsecured Wi-Fi network), and returns a faked response faster than the legitimate server. Here too, the risks include phishing or spreading malware.

🤔 So, how can you guarantee the authenticity of DNS responses and protect yourself from DNS Spoofing? DNSSEC offers an effective solution 👇

The DNSSEC security protocol

What is DNSSEC?

Since its creation, the DNS system has lacked any authentication protocol, exposing it to vulnerabilities that compromise user security. That’s why the DNSSEC protocol (“Domain Name System Security Extensions”) was developed, to enhance connection security by ensuring the integrity of DNS responses.

When DNSSEC is enabled, exchanges between the DNS resolver and servers still follow the same pattern, but DNSSEC introduces verification steps to ensure the authenticity of visited IP addresses.

To do this, DNSSEC adds cryptographic signatures to a domain’s DNS records (A, AAAA, MX, CNAME, etc.). These signatures are stored in the DNS name servers.

How does DNSSEC work?

First, the domain owner must activate DNSSEC with their registrar or domain manager.

Once DNSSEC is enabled, the DNS records are digitally signed in the zone file, which will now include new DNSSEC records (RRSIG, DNSKEY, DS etc.) in addition to the usual ones (A, AAAA, MX, CNAME, etc.).

So, when a DNS resolver receives a query, it verifies the signature using a chain of trust that retraces the DNS resolution steps in reverse (see schema above and below).

The DNSSEC protocol’s chain of trust

Here is a summary of the verification process triggered by DNSSEC:

On the domain’s DNS records side, when DNSSEC is enabled:

1. The DNSSEC protocol generates signatures for each zone file record, using a pair of public and private keys: this is the ZSK (“Zone Signing Key”). When a record is signed with the ZSK, an RRSIG (“Resource Record Signature”) record is created, and the ZSK key is published in the DNSKEY record.
2. At the same time, a key is generated to sign the ZSK itself: this is the KSK (“Key Signing Key”). The KSK therefore signs the DNSKEY record (which contains the ZSK), generating a new record RRSIG for the DNSKEY.
3. The KSK is then encrypted and stored in a DS (Delegation Signer) record published in the parent zone. For example, if the DNS resolver queries the netim.com records on the authoritative server (or name server), then the DS record will be published in the parent zone, i.e. the TLD server for .com (see diagram below).

On the DNS resolver’s side, when a domain name is queried:

1. First, the DNS resolver retrieves the DNS record and its signature (RRSIG record), as well as its ZSK key stored in the DNSKEY record. It uses the ZSK to verify the RRSIG signature.
2. The resolver now needs to verify the authenticity of the ZSK using the KSK. To do this, it checks the RRSIG for the DNSKEY record.
3. Finally, the resolver verifies the authenticity of the KSK using the DS record published in the parent zone (i.e. the TLD server), and ensures they match.
4. The chain of trust is repeated in the same way for .com, whose DS record is located in the root server.
   🔒 The DNS root zone being the starting point of the entire chain, its authentication is carried out using a public key called the Trust Anchor, which is directly stored in the DNS resolver like a built-in certificate.

💡 In the end, we can conclude that enabling the DNSSEC protocol, through a chain of trust made up of public and private keys, makes it possible to secure access to a domain name by guaranteeing the returned IP address.

A new Trust Anchor for 2026

As we’ve seen, the DNSSEC chain of trust relies on a final validation: the DNS root’s public key, also known as the Trust Anchor. This is what allows resolvers to validate all signatures up to the top of the DNS hierarchy.

But like any cryptographic key, it must be renewed regularly to ensure a high level of security.

That is why in August 2024, ICANN published a new version of the Trust Anchor, which is scheduled to be activated in 2026. This rotation, known as the Root KSK Rollover, is a rare but essential event for the overall security of the web.

This renewal process is part of the DNSSEC key ceremonies, organised under extremely secure and transparent conditions (filmed, documented and overseen by several specialised operators). If you would like to learn how a Root KSK Ceremony is conducted, you can consult the report and video of the 55th official IANA ceremony.

🖊️ Explore all our domain name articles.
📧 Don’t forget to subscribe to our newsletter from your Netim Direct client area to receive all our news and special offers!