DNSSEC basics for domain owners: what it protects, how to enable it, and how to check it

DNS was designed without a way for a resolver to check that an answer really came from the domain's owner. DNSSEC (DNS Security Extensions) adds digital signatures to DNS data so that validating resolvers can detect forged or altered answers. RFC 9364 (BCP 237) states that using DNSSEC for origin authentication of DNS data is the best current practice.

DNSSEC is worth understanding even if you have not turned it on, because a broken DNSSEC set-up is worse than none: validating resolvers refuse to answer for the domain, and since 15 March 2026 public certificate authorities must refuse to issue certificates for it too.

What DNSSEC protects, and what it does not

According to ICANN's explainer, DNSSEC adds two properties: data origin authentication (the answer came from the zone it claims to come from) and data integrity (it was not modified after being signed). This defends against cache poisoning, where an attacker gets a resolver to accept a forged answer and then serves it to many users.

RFC 4033 is equally clear about the limits:

• It provides no confidentiality: queries and answers are still visible on the network.
• It provides no protection against denial of service.
• It does not protect operations such as zone transfers and dynamic updates.
• It cannot help if an attacker logs into your registrar or DNS hosting account: records changed there are signed like any others. Protect those accounts with strong passwords and two-factor authentication.
• It only protects users whose resolver validates. ICANN notes that validation has to be enabled by resolver operators.

The records involved

Validation follows a chain of trust: resolvers trust the root zone's key (the root has been signed since 2010, per ICANN), the root vouches for the TLD's key, and the TLD's DS record vouches for your key. If any link is missing, your zone is treated as unsigned (insecure). If a link is present but wrong, for example a DS record that matches no current key, your zone is treated as bogus and validating resolvers return SERVFAIL.

Turning it on

DNSSEC has two halves, handled by two different parties:

1. Signing, at your DNS host. The host generates keys, signs the zone and keeps re-signing it as signatures approach expiry. ICANN notes that with many hosting providers this is little more than a checkbox. If you run BIND or another authoritative server yourself, this is your job.
2. Publishing the DS record, at your registrar. The DNS host gives you the DS data (key tag, algorithm, digest type and digest) and you submit it through your registrar, which passes it to the registry. Some providers automate this step; often it is still manual. Check that your registrar and your TLD's registry accept DS records before you start.

Order matters. Sign first, confirm the DNSKEY records are visible, then add the DS. If a DS record reaches the parent before your zone is signed with the matching key, the domain becomes bogus.

Checking your set-up

On Debian or Ubuntu, dig and delv come from the bind9-dnsutils package (sudo apt install bind9-dnsutils).

dig example.com DS +short
dig example.com DNSKEY +short
dig example.com A +dnssec

The first command shows the DS record the parent publishes; the second, your zone's keys. In the third, a validating resolver sets the ad (authenticated data) flag in the header when the answer validated, and +dnssec asks for the RRSIG records to be included.

delv validates by itself, starting from the built-in root trust anchor, so it does not depend on your resolver. Its manual explains that answers are either fully validated or were not signed, and that a failure is explained in the output:

delv example.com A
delv example.com A +vtrace

+vtrace shows the validator's reasoning when something fails. For a visual view of the whole chain, Let's Encrypt's documentation recommends a DNSSEC debugger such as dnsviz.net.

The risky moments

• Changing DNS host. Your new host signs with new keys, so the old DS no longer matches. RFC 6781 describes a cooperative key handover between operators; when the old operator will not cooperate, the only viable route is to let the zone go insecure: remove the DS at the registrar, wait for the old DS to expire from caches, move and re-sign, then add the new DS.
• Turning DNSSEC off. Remove the DS first, wait for it to expire from caches, then stop signing. Doing it the other way round leaves a DS pointing at signatures that no longer exist.
• Self-hosted signing that stops. Signatures carry expiry dates. If re-signing stops, the zone becomes bogus when they expire.
• Certificate issuance. Since 15 March 2026 the CA/Browser Forum Baseline Requirements require CAs to validate DNSSEC during domain validation and CAA checks and forbid treating errors such as SERVFAIL as permission to issue. A bogus zone now means failed certificate renewals as well as unreachable services.

What you should do

• Secure your registrar and DNS hosting accounts first; DNSSEC cannot protect against changes made there.
• If your DNS host and registrar support it, enable signing, verify the DNSKEY records, then add the DS record.
• Check the result with delv and dig +dnssec, and look at the chain in a DNSSEC debugger.
• Before changing DNS host or disabling DNSSEC, plan the DS removal and waiting time.
• Add a DNSSEC check to your monitoring so a bogus zone is noticed before users or certificate renewals fail.

Sources

• rfc-editor.org/rfc/rfc9364.html
• rfc-editor.org/rfc/rfc4033.html
• rfc-editor.org/rfc/rfc6781.html
• icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en
• manpages.debian.org/trixie/bind9-dnsutils/delv.1.en.html
• manpages.debian.org/trixie/bind9-dnsutils/dig.1.en.html
• letsencrypt.org/docs/caa
• cabforum.org/working-groups/server/baseline-requirements/documents
• github.com/cabforum/servercert/blob/main/docs/BR.md