DNSSEC and DNS security on your local network

Informatec Digital » Resources » DNSSEC and DNS security on your local network

The internet is built on a handful of key components that we almost never see, but that are there every time we open a browser. One of the most important is the Domain Name System (DNS), and when we talk about DNSSEC and security on a local network , we're really talking about fortifying that foundation to prevent fraudulent redirects, spoofing, and other serious attacks.

Previously, the priority was simply making sure everything worked; today we know that's not enough. DNS was born in the 80s without considering massive cyberattacks, but now we need it to not only resolve names but also validate the authenticity and integrity of each response . That's where DNSSEC comes in, and more recently, proposals like E-DNSSEC, which aim to add confidentiality as well—a key factor if you're concerned about the security of your local or corporate network.

What is DNS and why is it so critical for security?

The Domain Name System (DNS ) is the internet's phone book: it translates easy-to-remember names (like www.example.com) into numerical IP addresses that computers understand (for example, 192.168.2.15 or an IPv6 address). Without this mechanism, we would have to memorize numbers instead of names, which is completely impractical.

This infrastructure is organized as a distributed database in a tree structure , with a root zone at the top, followed by top-level domains (TLDs such as .es, .com, .org), and below that, domains and subdomains. Each portion of this database is called a " zone " and is hosted on one or more authoritative name servers, which publish the "official" information for each domain.

When your computer, mobile phone, or any other device wants to access a website, it starts by querying a stub resolver , which is part of the operating system. This resolver sends the query to a recursive DNS server (usually your internet service provider's, your company's, or a public one like Google Public DNS , OpenDNS, or Quad9). This recursive server then searches for the answer by querying several authoritative servers until it finds the correct IP address.

Recursive resolvers cache the responses they receive to speed up subsequent queries. This is very efficient, but it also opens the door for an attacker to "poison the DNS cache" and slip in false data , so that many subsequent requests are resolved with this manipulated information without the user noticing.

The major problem is that, in its original design, DNS has no robust way to verify the authenticity of responses . The resolver essentially checks that the response appears to be coming from the same IP address it queried, but that source IP address can be spoofed relatively easily. This allows for silent redirect attacks to fraudulent sites that mimic, for example, your bank's website.

Security limitations of traditional DNS

The DNS protocol was created in an era when security wasn't a primary concern. That's why we now know that DNS queries and responses travel in plain text , without encryption, and that record data can be falsified without additional protection.

This opens the door to several types of attacks, most notably DNS cache poisoning and man-in-the-middle attacks. In both cases, the attacker injects forged responses along the way, causing users to end up on websites under their control without noticing anything unusual, since the domain name displayed in the browser remains legitimate.

Imagine you access your bank's website: your computer requests the bank's domain IP address from the recursive server, but an attacker has tricked the server into accepting a fake response with the IP address of an identical website controlled by them . The user enters their credentials, thinking everything is normal, and the cybercriminal receives them in plain text to use on the real site later.

Mechanisms such as Transaction Signatures (TSIG) , defined in RFC 2845, serve to protect certain operations between DNS servers (for example, zone transfers between master and slave servers and dynamic updates). TSIG allows two machines sharing a secret key to verify the identity of the other end and the integrity of messages in transit.

However, TSIG has a very limited scope: it doesn't authenticate the "real" origin of DNS data ; it only ensures that the exchange between two specific servers hasn't been tampered with. If the original information in a zone was already compromised or manipulated before reaching those servers, TSIG won't detect it. Therefore, although it's commonly used for zone transfers, it doesn't solve the underlying problem of the authenticity of published DNS data.

What is DNSSEC and what does it contribute to security?

In response to all these weaknesses, Domain Name System Security Extensions (DNSSEC) were developed . DNSSEC does not replace classic DNS, but rather extends it with a layer of security that allows verification that the received data is legitimate and has not been altered.

DNSSEC is based on public-key cryptography (asymmetric cryptography) . Each DNS zone has a key pair: a private key, which is kept secret, and a public key, which is published on the DNS server itself. The zone owner uses the private key to digitally sign the records in that zone; the public key is used to verify those signatures.

When a recursive server queries a domain using DNSSEC, along with the usual information (for example, the IP address associated with a name), it also receives the digital signatures and public keys necessary for validation . The recursive server validates the signatures against the published public keys; if the verification is successful, the data is considered authentic and unchanged since it was signed.

If validation fails, the resolver understands that something is wrong (for example, an attempted spoofing or tampering in transit) and responds to the client with an error code, typically SERVFAIL . In this way, the user does not receive potentially malicious data, although from their perspective, all they will see is that the page "doesn't load" or displays an error.

DNSSEC also introduces the concept of a chain of trust , which leverages the existing DNS hierarchy. The root zone signs the keys of top-level domains (such as .es, .com), these in turn sign the keys of their child domains, and so on, so that any domain can be validated using a single point of trust: the public key of the root zone.

KSK and ZSK keys, records, and chain of trust

To better organize security, DNSSEC uses two different types of keys: the Key Signing Key (KSK) and the Zone Signing Key (ZSK) . Although technically they are the same (cryptographically speaking), their function is different within the system.

The ZSK key is used to sign all resource records in the zone (A, AAAA, MX, etc.). It is typically rotated frequently to minimize risk, as any compromise of this key would affect all records in the zone. The KSK, on ​​the other hand, is primarily used to sign the zone key (ZSK) itself, and its hash is published as the DS (Delegation Signer) record in the parent zone.

Thanks to this separation of roles, changing the ZSK is simpler: just generate a new ZSK, sign it with the KSK, publish it in the zone's DNSKEY records, and let the resolvers update their information. There's no need to touch the parent zone, since the DS continues to point to the same KSK, which remains stable for longer.

DNSSEC adds several types of specific records to the DNS protocol, designed to support data signing and validation. Among the most important are DNSKEY, RRSIG, DS, NSEC/NSEC3, and NSEC3PARAM . All of these allow you to build authentication logic without changing the basic operation of queries.

The DNSKEY record stores the zone's public key , which is necessary to verify signatures. The RRSIG record contains the digital signature associated with a specific set of records (a "Resource Record Set"). The DS record is a hash of the child zone's DNSKEY, which is published in the parent zone and serves as a link in the chain of trust.

NSEC and NSEC3 records are used to provide authenticated denial of existence ; that is, to cryptographically prove that a domain name or record does not exist, preventing attacks that attempt to slip in false responses indicating that something does not exist when it actually does (or vice versa).

Chain of trust and DNSSEC response validation

The so-called chain of trust in DNSSEC is built by linking DNSKEY and DS records from the root to the domain we want to validate . The starting point is the root zone's public key, which acts as a trust anchor and is usually configured directly in the recursive resolvers.

For example, if you want to validate a domain like mywebsite.es, the logical process would be: the resolver trusts the root's public key, which signs the .es key; the .es zone publishes a DS record corresponding to the mywebsite.es KSK key; by validating that DS with the .es key, the resolver trusts the mywebsite.es DNSKEY and, from there, can verify the RRSIGs on all its records.

If a valid signature is missing at any point in the chain, or if the DS (Data Signature) is not present where it should be, the chain of trust is broken. In that case, the recursive server performing the validation does not consider the data safe and, depending on its configuration, either does not respond with the requested records or marks the response as invalid.

This hierarchical relationship also means that, for DNSSEC to be truly effective, it's not enough to sign only your zone : the parent zone (for example, .es) and the root zone must also be signed and have their DNS records correctly published. Currently, the DNS root zone and virtually all generic top-level domains (gTLDs) and many country code top-level domains (ccTLDs) are already signed.

When a recursive server with DNSSEC validation enabled detects that the signature doesn't match or that a link is missing, the response it returns to the client is usually accompanied by an RCODE SERVFAIL error code. This can be confusing for the end user ("the website isn't working"), but from a security standpoint, it's a protective measure against potentially manipulated data.

DNSSEC also introduces two key features: data origin authentication , which allows verification that the records actually come from the expected zone, and integrity protection , which ensures that the information has not been modified since it was signed by the zone owner with their private key.

Attacks mitigated by DNSSEC and their relationship to TLS/HTTPS

Implementing DNSSEC helps protect against several common threats. First, it makes DNS response spoofing extremely difficult , as the attacker would have to generate valid signatures without knowing the zone's private key, which is cryptographically impossible if the keys are managed correctly.

Furthermore, DNSSEC reduces the risk of cache poisoning on recursive servers by preventing the acceptance of manipulated responses that fail signature validation. It also complicates man-in-the-middle (MITM) attacks on DNS traffic, in which an attacker modifies responses in transit: if the response fails validation, the resolver discards it.

It's important to understand, however, what DNSSEC doesn't do. These extensions aren't designed to encrypt the content of queries or responses . All DNS traffic, even with DNSSEC, still travels in plain text unless you use other complementary technologies (such as DoT, DoH, or E-DNSSEC-type solutions). DNSSEC focuses on ensuring that what you receive is authentic and hasn't been altered, not on hiding what you're asking.

This clearly differentiates it from protocols like TLS and HTTPS . While HTTPS encrypts traffic between the browser and the web server to prevent third parties from spying on or modifying the communication, DNSSEC simply signs DNS data to detect spoofing. A site can have HTTPS without DNSSEC or DNSSEC without HTTPS, but the combination of both offers much more comprehensive protection against spoofing and spying.

Organizations like ICANN and the IETF have been promoting the widespread adoption of DNSSEC by registries, registrars, ISPs, and network operators for years. The goal is for more and more zones to be signed and for more resolvers to actively validate them, so that the average user can benefit from these cryptographic guarantees without taking any special action.

DNSSEC in .es domains and owner obligations

In the specific case of Spain, the ".es" Domains unit managed by Red.es has long incorporated additional technologies and procedures to improve the quality and security of the DNS service under the .es country code. Among these measures is the implementation of a DNSSEC security protocol in accordance with IETF specifications.

The .es domains are responsible for signing the .ES top-level zone and obtaining authorization from the DNS root, thus integrating into the global chain of trust. This means that if you own a .es domain, you can leverage this infrastructure to secure your own domain with DNSSEC.

As a domain owner, the general procedure for enabling DNSSEC involves ensuring that your authoritative DNS servers publish the signed zone. Typically, this entails generating a public key for your zone, signing the records, publishing the DNS key, and then submitting the key material (or the DS record itself) to the registry or your registrar so they can create the corresponding DS record in the parent zone.

In practice, many DNS hosting providers and registrars already offer a fairly simple option to enable DNSSEC, sometimes as easy as checking a box in the control panel. However, there may be a small annual cost associated with this functionality, depending on the provider and service level.

Once the zone is signed and the Domain Name System (DNS) has been successfully published, your domain becomes part of the DNSSEC chain of trust. From that moment on, DNS resolutions for your domain can be cryptographically validated by resolvers that have DNSSEC validation enabled, increasing user trust and reducing the risk of spoofing attacks.

DNSSEC on the local network: user-side validation

From the perspective of an end user or a company concerned about the security of its local network, the key question is: what does it take to benefit from DNSSEC? The good news is that you don't need to configure anything on each computer individually , as long as your recursive DNS server (the one your computers use) validates DNSSEC.

To do this, all you need is for your DNS provider (your ISP, a public resolver, or your organization's internal DNS) to have a recursive server with DNSSEC validation enabled and properly configured . Virtually all modern resolvers have supported DNSSEC for years; enabling it usually involves only a few changes to their configuration file and adding the root trust anchor.

Once validation is enabled, when one of your computers on the local network queries a signed domain, the recursive resolver verifies all signatures and the chain of trust before returning the response. If anything doesn't match, it returns no records, and the user sees an error, effectively preventing them from connecting to a potentially fraudulent site.

To check if your domain is protected by DNSSEC, there are several online tools available, such as DNSSEC Analyzer and other validation utilities . When you enter your domain, you should see records such as RRSIG (cryptographic signatures), DNSKEY (public keys), and DS (hash of the DNSKEY in the parent zone). If the tool indicates that there is no digital signature associated with the records, your domain will be considered "unsigned" or "insecure."

If, after this check, you find that your domain or the DNS servers you use on your local network aren't taking advantage of DNSSEC, it's advisable to contact your service provider or ISP to request its activation. If they don't offer this option, it might be a good time to consider switching to a provider that does support DNSSEC validation, thus increasing the level of security for both your company and your customers.

Limitations of DNSSEC: privacy and other aspects

Despite all its advantages, DNSSEC is not a magic bullet for all DNS security problems. A key issue is that it doesn't provide query confidentiality . DNS packets, even with DNSSEC, still travel in plain text, so anyone with access to the traffic (for example, on an unsecured public Wi-Fi network ) can see which domains are being queried.

It also offers no access control or specific defense against denial-of-service (DoS or DDoS) attacks . In fact, by adding more data (signatures, keys, additional records), it increases the size of DNS responses, which can be exploited in amplification attacks if the infrastructure is not properly configured and protected.

On the other hand, DNSSEC introduces some operational complexity: key pairs must be managed, ZSK and KSK must be rotated, DS publication in the parent zone must be coordinated , and it must be ensured that there are no mismatches that break the chain of trust. An error in these procedures can cause a domain to stop validating correctly, generating apparent service outages.

Within the DNSSEC process itself, there are control bits in the messages (such as the CD bit in queries and the AD bit in responses) that influence how validation is performed and reported. An attacker who could manipulate these bits in an insecure environment could attempt to degrade the protection offered by a recursive resolver. Therefore, it is recommended that communication between resolvers and clients using DNSSEC take place over secure channels.

Despite these limitations, DNSSEC remains an essential component for strengthening DNS authenticity and integrity. However, to go a step further and also guarantee the confidentiality of queries, it is necessary to combine it with other technologies or evolve towards more advanced solutions.

E-DNSSEC: Towards an authenticated and encrypted DNS

To address the privacy gap left by DNSSEC, the concept of E-DNSSEC (DNSSEC encrypted) has been proposed . The idea behind this approach is to add encryption to DNSSEC queries so that, in addition to being authenticated and signed, they are also protected from third-party inspection while traveling over the internet or through the local network.

The goal of E-DNSSEC is to combine the properties of DNSSEC (authenticity and integrity) with encryption mechanisms that provide confidentiality for queries between the DNSSEC client and the DNSSEC server . This increases the overall security of the DNS service, preventing external observers from seeing which domain names are being resolved.

The conceptual process would involve analyzing the query on the recursive server, encrypting it before sending it to the authoritative server, and then decrypting and processing it normally using DNSSEC . The response, in turn, could be returned signed and encrypted back to the recursive server or the client, maintaining confidentiality throughout the entire process.

This combination would ensure the DNS message is secured from the beginning to the end of the resolution process: authenticated and with integrity thanks to DNSSEC, and protected from prying eyes thanks to additional encryption. In a local or enterprise network context, such an approach could be integrated with other perimeter security solutions.

Today, proposals like E-DNSSEC are part of a broader effort to strengthen DNS privacy , alongside technologies such as DNS over TLS (DoT) and DNS over HTTPS (DoH). The underlying direction is clear: the DNS of the future must be both authentic and confidential, and it's not enough to simply resolve names quickly; it must also be done securely.

In an environment where there are increasingly more sophisticated cyberattacks, impersonations, and threats targeting basic infrastructures, having DNSSEC is already an important security requirement for any serious domain, and moving towards encrypted solutions like E-DNSSEC or similar is emerging as a logical next step to further strengthen the protection of networks, including local networks.

This entire ecosystem—from classic DNS to DNSSEC and encrypted solutions like E-DNSSEC—demonstrates that DNS security is not an optional extra, but a core component of the internet architecture and any modern local area network. Having resolvers that validate, signed zones, well-maintained chains of trust, and, in the future, encrypted channels for queries, makes all the difference between an exposed network and an infrastructure prepared for current and future challenges.