What Is DNSSEC? How to Protect Your Domain

A green DNSSEC status can still hide a broken chain

I have learned not to trust a DNS panel’s green badge until I have checked the answer from outside that panel. During a late-night test in my Proxmox lab, I found that the authoritative servers were not serving the same DNSKEY data. The domain looked healthy in the provider interface, but a validating resolver had already started returning SERVFAIL.

There were no customers involved, just a broken test zone and a cup of tea. Still, it reinforced a rule I use in production: DNSSEC is a chain, and every link needs to be checked.

DNSSEC verifies that a DNS response came from the authoritative source and was not changed in transit. It does not encrypt DNS traffic, hide your passwords, or protect your website application. It adds digital signatures to DNS records so a validating resolver can decide whether the response is trustworthy.

The short answer to “what is DNSSEC?” is this: DNSSEC helps prevent a resolver from accepting forged DNS data for your domain. When a validating resolver requests an A, AAAA, MX, or TXT record, it checks the signature and the chain of trust behind the answer.

Where ordinary DNS leaves room for attack

DNS translates a domain name into an IP address. When your browser asks for the A or AAAA record for example.com, a recursive resolver usually contacts the domain’s authoritative nameservers and caches the response. With ordinary DNS, the resolver has no cryptographic proof that the answer really came from the domain owner.

That gap can be abused through cache poisoning or forged responses sent between the client and resolver. An attacker may try to send visitors to a server they control even though those visitors typed the correct domain name. HTTPS certificate warnings expose some attacks, but users can ignore warnings, and not every service uses a browser certificate.

DNSSEC adds a signature chain to the lookup. The resolver can ask, “Did this address really come from the authoritative records for this domain?” and verify the answer using cryptographic data instead of trusting the server’s claim. If validation fails, a validating resolver rejects the response and usually returns SERVFAIL.

The records behind the trust chain

DNSSEC terminology looks crowded at first. In support tickets, I separate the main record types like this:

• DNSKEY: Contains the domain’s DNSSEC public keys. With managed services, the details may be hidden; on a BIND installation, you will commonly encounter KSK and ZSK roles.
• RRSIG: A digital signature for a DNS record set such as A, MX, or TXT. The resolver verifies it using the appropriate DNSKEY.
• DS: A Delegation Signer record. It carries a digest of a DNSKEY into the parent zone and connects your domain to the trust chain above it.
• NSEC or NSEC3: Used to prove that a record does not exist. DNSSEC validates both “this record exists” and “there is no record at this name.”

The flow is easier to follow than the names suggest: the root zone provides the trust anchor for the TLD, the TLD publishes the DS record for your domain, the DS helps validate the domain’s DNSKEY, and the DNSKEY validates the RRSIG signatures for A, MX, TXT, and other records.

One mismatched link is enough to break validation. DNSSEC may appear enabled in your DNS provider’s panel while the registrar still publishes a DS record for an old key. A green status indicator is not proof by itself. Test from outside the panel.

KSK and ZSK have different jobs

DNSSEC deployments commonly use two key roles. The Zone Signing Key, or ZSK, signs the ordinary records in the zone. The Key Signing Key, or KSK, signs the DNSKEY record set, and a digest of that key is published in the parent zone as the DS record.

This separation makes key rotation easier to manage. A ZSK can be changed without changing the DS record; changing the KSK also requires a coordinated DS update. Managed DNS providers often automate the process. If you run your own BIND servers, monitor that automation instead of assuming a scheduled job is alive.

I learned that distinction the hard way with a certificate-renewal cron job that stopped running silently. Scheduled does not mean monitored.

DNSSEC and HTTPS protect different layers

These technologies are sometimes treated as alternatives, but they solve different problems. HTTPS protects the connection between the browser and web server with TLS. DNSSEC validates the DNS response. An SSL/TLS certificate does not, by itself, prevent a forged DNS answer from pointing a domain at the wrong address.

You still need an HTTPS certificate on a domain protected by DNSSEC. Email also needs separate SPF, DKIM, and DMARC records. One layer does not configure the others.

Map your DNS setup before enabling DNSSEC

You may be able to enable DNSSEC with one button. I still write down where DNS is actually managed first. The registrar, authoritative DNS provider, and hosting company do not have to be the same business.

1. Identify the authoritative nameservers. Check the nameserver values at the registrar and establish which service is really publishing the zone.
2. Understand the provider’s DNSSEC workflow. Some panels generate and publish signatures automatically; others give you DS values to enter at the registrar. Do not apply both workflows at random.
3. Export the current records. Save A, AAAA, MX, TXT, CNAME, CAA, and any custom SRV records. If these record types are unfamiliar, DNS Record Types Explained: Practical Guide to A, AAAA, MX, CNAME, TXT, SRV and CAA covers the common examples.
4. Check for secondary DNS or a DNS proxy. If a CDN, WAF, and registrar DNS service are all involved, be certain which system creates and serves the signatures.
5. Prepare another way to contact you. A DNSSEC mistake can also break email addresses tied to the domain. Check the phone number and alternate email address on the registrar account.

If you are changing nameservers, include DNSSEC in the change plan. For a domain transfer, confirm where DNS is hosted and how the DS record will be handled. The checklist in How to Transfer a Domain Name Without Downtime should include this DNSSEC check. Debugging SERVFAIL after the transfer is a poor time to discover that nobody owns the DS change.

Enabling DNSSEC through a hosting or DNS panel

With a managed DNS service, the process usually has three parts: enable DNSSEC at the authoritative provider, enter the resulting DS information at the registrar, and validate the result from outside. Some registrars add the DS record automatically through an API integration.

When a panel asks you to enter DS information, it will generally show:

• Key tag
• Algorithm
• Digest type
• Digest

A single mistyped character can break the chain. Check for spaces at the beginning or end when copying values. Compare the DS data with the value generated by the DNS provider, and make sure you are not using information from an old key.

If several DS records are present, do not delete them all without checking. During a controlled key transition, old and new keys may both be valid for a period of time. Follow the provider’s rotation procedure. If you do not manage the keys yourself, an automated DNSSEC workflow usually means less manual work and fewer opportunities for this particular mistake.

Validating DNSSEC from Linux

When a DNS ticket arrives, I inspect the chain with dig before trusting what a panel says. A basic query is:

dig example.com A +dnssec

An RRSIG in the response means the server returned signature data. The ad flag indicates that the resolver considers the answer authenticated. The +dnssec option requests DNSSEC records; it does not perform validation by itself.

That last detail catches people out.

To inspect the DS record published by the parent zone:

dig example.com DS +short

You can compare the digest with the DNSKEY data published by your DNS provider. To query an authoritative server directly, first list the nameservers:

dig example.com NS +short
dig @ns1.example-dns.net example.com DNSKEY +dnssec

The first command lists the authoritative nameservers. The second asks one of them for its DNSKEY and signature data. Replace the example domain and nameserver with your actual values.

For a clearer view of local DNSSEC validation, use delv:

delv example.com A

When validation succeeds, the output includes information about the trust chain. Errors such as broken trust chain or no valid signature mean you should inspect DS, DNSKEY, and RRSIG together. Looking only at the A record can hide the real fault.

Tests I run after enabling DNSSEC

I do not test only from my own laptop. I query through different recursive resolvers, a mobile connection, and a separate network. Caches expire at different times, so answers will not necessarily change everywhere at once.

My practical test order is:

1. Query the domain’s A and AAAA records.
2. Check that MX records validate and confirm that email still flows.
3. Query TXT records and verify that SPF, DKIM, and domain-verification records are returned.
4. Check the DS record at the TLD level.
5. Run dig or delv through a resolver that performs DNSSEC validation.
6. Confirm that at least two authoritative nameservers return the same DNSKEY and signature state.

Do not stop because the website opens in a browser. Many teams check the A record and forget MX and TXT. Email delivery and third-party verification services may expose a broken chain before the website does.

Check the quiet records too.

Where I look first when I see SERVFAIL

A DNSSEC failure often looks like the entire website is down. First separate a problem affecting every client from one affecting only particular resolvers. To compare two public validating resolvers:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Then check these possibilities:

• The registrar may still have a DS record belonging to the previous DNS provider.
• The new DNS provider may be serving a DNSKEY set that does not match the DS at the parent.
• An authoritative server may be serving an old zone file or stale DNSSEC data.
• The DNS server’s clock may be wrong. RRSIG records have validity periods, and a serious clock error can make an otherwise correct signature fail.
• A DNSSEC key rotation may have stopped halfway through.
• A record set may have changed without a valid replacement RRSIG being published.

These queries show whether two independent validating resolvers are seeing the same answer. They do not, by themselves, identify every broken link.

People sometimes suggest deleting the DS record as a quick fix. That disables validation and may restore resolution, but it also removes DNSSEC protection. Find the cause first. If operational pressure forces you to remove the DS record, document the decision and restore DNSSEC after correcting the underlying problem.

Do not turn an outage into a permanent downgrade.

DNSSEC has limits and needs maintenance

DNSSEC does not protect your registrar account. If that account is compromised, an attacker may change the nameservers or manage the DS record. Use multi-factor authentication, protect the recovery email address, and limit administrative access.

DNSSEC also does not patch vulnerabilities in your web server. An outdated WordPress plugin, an administrator password such as 123456, or incorrect filesystem permissions remain problems. DNSSEC helps validate that the DNS record points to the expected IP address; it does not prove that the application running there is secure.

A wrongly signed record can have a harsher effect than an unsigned record because a validating resolver rejects it. Monitor DNSSEC keys, signature validity periods, and DS changes. If you operate your own DNS infrastructure, log changes, create alerts, and write the rollback step before making the change.

Nameserver performance, TTL values, and resolver behavior still matter. Measuring and Improving DNS Performance with Anycast, Multi-DNS and Health Checks looks at those subjects from an operational angle. DNSSEC adds signatures; it does not make a poorly designed DNS architecture fast or resilient by itself.

A practical DNSSEC plan for your domain

For a small WordPress site, I prefer a DNS provider that supports DNSSEC and automates key rotation. I export the current zone, enable DNSSEC at the provider, enter the generated DS information at the registrar, and validate the result through different resolvers. I also record the date, DS digest, and provider used.

If you manage multiple sites or an ecommerce platform, make the process stricter. Follow DNS provider maintenance notices, do not leave registrar access in one person’s account, and require a second check for DS changes. One incorrect DNS record can affect a customer’s website, email, and third-party API integrations at the same time.

Add these items to the migration plan:

• Record the current DS and DNSKEY values.
• Validate DNSSEC on the new authoritative nameservers.
• Change the DS record only after the new key is ready and being served consistently.
• Do not shut down the old DNS provider immediately.
• Query A, AAAA, MX, and TXT records through different resolvers.
• Monitor signature validity and nameserver consistency.

I keep this checklist beside the change window now. The extra five minutes are cheaper than explaining to a customer why a resolver somewhere on the internet refuses to believe their domain exists.

Frequently asked questions

What is DNSSEC, and does every domain need it?

DNSSEC is a security layer that validates whether DNS responses came from the authoritative source and were not modified. It is not mandatory for every domain, but it is useful when you want to reduce the risk of forged DNS responses or altered DNS records.

Does DNSSEC slow down a website?

DNS responses become larger because signature and validation data are added. With a correctly configured DNS service, this normally does not create website slowness that users notice. Nameserver performance, TTL values, and resolver behavior should still be evaluated separately.

Do I still need an SSL certificate after enabling DNSSEC?

Yes. DNSSEC validates DNS records, while SSL/TLS encrypts the connection between the browser and server and authenticates the server. They protect different layers and are not substitutes for each other.

My domain returns SERVFAIL after DNSSEC was enabled. What should I do?

Compare the DS record at the registrar with the DNSKEY and relevant RRSIG records on every authoritative server. dig +trace, dig +dnssec, and queries through different resolvers can show where the chain breaks. Removing the DS record should be treated as a controlled emergency measure, not the first diagnostic step.