WebCheck

DNSSEC for your domain: chain of trust, DS records and changing provider safely

DNSSEC signs your domain's DNS answers so that nobody can quietly send your visitors to someone else's server. Switching it on is quick. After that, the DS record at your registrar has to keep matching the zone's key.

Updated: 05 November 2026

Forged DNS answers

Before a browser can open www.example.com, it asks a resolver for the IP address, usually one run by the ISP. Plain DNS has no way of telling a genuine answer from a forged one. If an attacker slips the resolver a convincing fake, the resolver caches it and sends every one of its users to the attacker's server until the TTL runs out. The attack is called cache poisoning.

DNSSEC (RFCs 4033, 4034 and 4035) adds signatures to the records in a zone. A validating resolver checks them and discards any answer that fails, so the visitor sees an error message rather than a wrong address.

Where DNSSEC stops

Nothing is encrypted, and securing the connection to your website is still the job of TLS. Protection also ends at the validating resolver. Laptops and phones leave validation to the resolver and simply accept its verdict, the AD bit in the response, so an attacker on hotel Wi-Fi can still tamper with that last stretch. A visitor whose resolver does not validate gets no benefit from your signatures at all.

Nor will DNSSEC save you if someone takes over your registrar account. Whoever can change your name servers there can remove the DS record too. Protect that account with two-factor authentication.

The chain of trust

A signed zone publishes its keys as DNSKEY records and its signatures as RRSIG records alongside the data. A resolver only trusts those keys if the parent zone vouches for them, so the .com zone holds a DS record for example.com containing a hash of your key. The DS record for .com sits in the root zone, whose key every validating resolver has built in.

example.com.      86400  IN  DS      31406 13 2 4A1F0C7E...   ; in the .com zone
example.com.      3600   IN  DNSKEY  257 3 13 mdsswUyr...     ; KSK
example.com.      3600   IN  DNSKEY  256 3 13 oJMRESz5...     ; ZSK
www.example.com.  3600   IN  A       203.0.113.10
www.example.com.  3600   IN  RRSIG   A 13 3 3600 ...

The key signing key (KSK, flag 257) signs only the keys and is what the DS record points to. The zone signing key (ZSK, flag 256) signs everything else. Your provider can swap the ZSK without anyone outside the zone noticing. A new KSK needs a new DS record.

Choosing an algorithm

Since RFC 9904 (November 2025), which replaced RFC 8624, the recommendations live in an IANA registry.

No. Algorithm For signing
13 ECDSA P-256 with SHA-256 recommended, small signatures
15 Ed25519 recommended, though not every resolver validates it yet
8 RSA with SHA-256 recommended, much larger responses
5, 7 RSA with SHA-1 must not be used (RFC 9905)

Algorithm 13 is the usual choice for a new zone. If yours still uses 5 or 7, migrate. Under RFC 9905 validating resolvers treat those algorithms as unsupported, which leaves your zone looking unsigned. For the DS record, use digest type 2 (SHA-256).

Turning DNSSEC on

Your DNS provider signs the zone and your registrar submits the DS record to the registry. For .de domains the registrar submits the public key instead and DENIC builds the DS record. If one company handles both registration and DNS, it is often a single toggle. Otherwise there is one manual step. Cloudflare, for example, shows the key tag, algorithm, digest and public key once you enable DNSSEC, and you enter those values at your registrar.

With CDS records (RFC 7344, RFC 8078) the zone itself announces which DS record it wants. Registries such as those for .ch and .cz apply the change automatically.

When the DS record no longer matches

A DS record that matches none of the zone's keys makes the zone "bogus". Validating resolvers return only SERVFAIL, and for their users your website and mail have vanished. Anyone behind a non-validating resolver sees no problem, which is why these incidents so often begin with "works for me". Typical causes:

  • changing DNS provider while the old DS record stays at the registrar
  • switching DNSSEC off at the provider and forgetting the DS record
  • a new KSK without a new DS record
  • expired signatures because a self-hosted name server has stopped re-signing

On the evening of 5 May 2026 the whole of .de went through this. A key rollover at DENIC produced invalid signatures, and for several hours validating resolvers could not resolve any .de name.

Changing provider in the right order

  1. Remove the DS record at your registrar. The zone at the old provider stays signed.
  2. Wait a day, which is how long .de and .com let resolvers cache the DS record.
  3. Set up the zone at the new provider, compare every record and switch the name servers at your registrar.
  4. Wait again until the old name servers have dropped out of caches: one day for .de, two for .com.
  5. Enable DNSSEC at the new provider and publish the new DS record.
  6. Only then delete the zone at the old provider.

Until step 5 the domain is unprotected but reachable. Avoiding the gap altogether takes the multi-signer model (RFC 8901), and both providers have to support it.

Checking with dig, delv and DNSViz

dig +dnssec example.com SOA @9.9.9.9
dig +cd example.com SOA @9.9.9.9
delv example.com

An ad among the flags of the first response means the resolver validated the signature. If that query returns SERVFAIL while the second, with validation off, gets an answer, the signature is broken. delv from the BIND tools validates by itself. For the clearest picture, DNSViz (dnsviz.net) draws the entire chain as a graph.

What DNSSEC makes possible

Only once DNS is signed can you trust it with information that security depends on. DANE lets you publish your certificate's fingerprint in a TLSA record, which mail servers check when delivering to each other (RFC 7672). And since 15 March 2026 certificate authorities have had to validate DNSSEC wherever it is deployed. If an attacker suppresses your CAA record, the CA notices. The flip side is that a bogus zone also blocks your next certificate.

Checking DNSSEC

ZwoWebCheck asks a validating resolver about your registered domain, so shop.example.com is checked as example.com. The zone only counts as signed when the chain up to the root holds. Without a DS record the report therefore says the zone is not secured end to end, even if your provider is already signing the zone. When the query fails with validation but succeeds without it, the report flags a broken signature as critical.