What Is DNSSEC and Should We Enable It?

The site won't come up, but not from the web server side. dig on your own server returns the correct answer, but from the outside you get SERVFAIL and there's no log in Apache or Nginx. If you've seen this pattern and recently enabled DNSSEC on the domain, there's a good chance the chain of trust is broken somewhere, not that your server is broken.

DNSSEC is a set of signed records that lets a resolver be sure the response it got from DNS hasn't been tampered with. Without it, anyone along the path can swap the response and send the user to their own IP. With it, the response is either valid or not accepted at all. It's that "not accepted at all" that makes things hard.

What a DNS spoofing attack looks like in practice

Suppose an attacker is sitting on the path between the user and the resolver. The user asks for bank.example.ir, the attacker sends a forged response with a high TTL and substitutes their own server's IP. The user even sees a valid SSL certificate, because the attacker can get a certificate for that same domain from a trusted CA if they take control of DNS. Here, none of the usual security tools show anything.

DNSSEC closes this with digital signatures. Each record is signed with the zone's private key, and the resolver verifies the signature with the public key it got from its parent. If the signature doesn't check out, the response is discarded.

Where the chain of trust starts

From the root. The DNS root signs the TLD's public key, the TLD signs your domain's key, and your domain signs its own records. This chain is anchored by the DS record at the parent. If that DS record is wrong or removed, the whole chain breaks and validating resolvers reject your response.

Setup: from key generation to DS publication

If you're using BIND, the order matters. First generate the keys, then sign the zone, then give the DS to the registrar. If you publish the DS before the zone is ready, the site disappears for all validating resolvers.

dnssec-keygen -a ECDSAP256SHA256 -f KSK example.ir
dnssec-keygen -a ECDSAP256SHA256 example.ir
dnssec-signzone -o example.ir -k Kexample.ir.+013+12345 db.example.ir

The output of dnssec-signzone is a signed zone file that should replace the previous file. The RRSIG and DNSKEY records are added automatically. Now check with dig:

dig +dnssec example.ir A @1.1.1.1
dig DS example.ir @a.root-servers.net

In the first response you should see RRSIG and the ad flag in the header section. If ad isn't there, validation was rejected. In the second response, the DS record should have the correct algorithm and hash.

Check the DS record manually

Registrars make a lot of mistakes here. The DS value must match the output of dnssec-dsfromkey exactly. One character off means complete failure. For a quick check, use the DNS and network lookup tools and compare the result with the local output.

This is where they mess up: a renewed key and a site that vanishes

The most common disaster I've seen is this: the team enables DNSSEC, everything works, and six months later the site goes down overnight. The cause? The RRSIG signature expired and nobody re-signed the zone.

The sign is this: the site opens from some networks and not from others. Users on different ISPs see different behavior. dig on your own server is fine, but dig @8.8.8.8 returns SERVFAIL. If you look at the resolver log, you see signature expired or no valid RRSIG. Here nobody suspects DNS, because "it worked yesterday."

The structural fix is automatic signing. BIND 9.16 and later does this with dnssec-policy:

dnssec-policy default {
    keys {
        ksk lifetime P1Y algorithm ECDSAP256SHA256;
        zsk lifetime P3M algorithm ECDSAP256SHA256;
    };
};

With this setting, BIND rotates the keys itself and re-signs the zone. But even with this you should set up alerts. Put a simple monitor on RRSIG expiry and get an alert if less than seven days remain.

The real cost of DNSSEC: bigger than a checkbox in a panel

DNSSEC isn't free, even when you don't pay money. Its cost is time and operational complexity. You have to accept three things:

• DNS responses get bigger. A signed response can exceed 512 bytes and need TCP or EDNS0. If your firewall drops UDP fragments, the site won't open for some users.
• Every record change must be re-signed. If you sign the zone manually, this is an extra step in every deploy.
• Errors are merciless. A wrong record in DNS usually means "that subdomain doesn't work." With DNSSEC it means "the whole domain doesn't work."

If your team is one person managing DNS manually, my suggestion is this: don't enable DNSSEC until you have automatic signing and expiry monitoring. If your registrar offers automatic signing and you can set up expiry alerts, enable it. For banking sites, payments, or anywhere DNS spoofing causes direct damage, DNSSEC is mandatory.

Health checks and continuous monitoring

After setup, check three things regularly. First, validation from several public resolvers:

dig +dnssec +multi example.ir @8.8.8.8
dig +dnssec +multi example.ir @9.9.9.9
dig +trace example.ir

Second, signature expiry dates. With dig +dnssec, the RRSIG value includes the expiry time. Third, the status of the infrastructure services themselves. If DNS is hosted on your own server, don't neglect real-time service status and service level and uptime, because DNSSEC on unstable DNS just surfaces errors faster.

One practical tip: before enabling it on the main domain, test it on a low-importance subdomain. Run the whole cycle once completely, including DS publication and checking ad. If it works there, it'll work on the main domain too.

If you're delegating DNS hosting to someone, make sure they have automatic signing and expiry alerts. ServerNet's security services cover this layer, but even with managed hosting you should know where the DS is registered and who's responsible for key rotation.

Frequently asked questions

Does DNSSEC stop a DDoS attack?

No. DNSSEC only guarantees the authenticity and integrity of the DNS response and has nothing to do with traffic volume. To deal with attack volume you need other layers; DDoS protection is a separate topic. You could even say DNSSEC increases load in some scenarios, because responses get bigger and TCP requests increase.

What happens if I misconfigure DNSSEC?

The site becomes unreachable for all resolvers that validate. This includes Google DNS, Cloudflare, and most major ISPs. Users on non-validating resolvers may still see the site, which makes diagnosis harder. Have a fast rollback: removing the DS record from the parent breaks the chain and usually resolves the problem within a few hours.

How do I know DNSSEC is working correctly on my domain?

With dig +dnssec example.ir @1.1.1.1 and checking the ad flag in the response header. If ad is present, validation succeeded. If you get SERVFAIL, the chain is broken. For a more precise check, compare the parent DS record with the output of dnssec-dsfromkey and check the RRSIG expiry date.

Does enabling DNSSEC slow down the site?

Its effect on page load speed is negligible, because DNS is only resolved once per session. But bigger responses can cause retries and delays on networks with low MTU. If your users are on weak mobile networks, factor this into your testing. The real number is usually a few milliseconds, not more.

Before anything else, check your domain's RRSIG expiry date today. If less than two weeks remain and you don't have automatic signing, that's the only thing you need to do.