DNSSEC: what it does and how to fix broken DNSSEC

What DNSSEC protects, why broken DNSSEC takes a domain offline for most visitors, and how to fix a DS record that matches no key.

DNSSEC adds signatures to a domain’s DNS records, so resolvers can check that an answer came from the domain’s DNS provider and wasn’t changed on the way. The registry holds a fingerprint of the domain’s key, called the DS record, and every signature can be traced back to it.

That protection has a cost. If the signatures or keys stop matching the DS record, resolvers that check DNSSEC treat every answer as forged and return an error instead. To their users, the domain disappears, even though its name servers are working.

What SignalDNS checks

Alongside the resolver queries, we send one DNS-over-HTTPS query to Cloudflare (cloudflare-dns.com), which validates DNSSEC, for the name’s A record. Its reply says whether the answer validated. When it didn’t, the reply can carry an Extended DNS Error (RFC 8914) naming the failure, such as signatures that have expired, and we show that.

The registration answer shows whether the registry lists a DS record for the domain.

In the DNS lookup, you can also ask for DS and DNSKEY records. We ask for them with checking disabled, so a zone’s keys are listed even when its DNSSEC doesn’t validate. Each key is shown as a key-signing or zone-signing key, with its key tag. When you ask for both, each DS record is marked with whether it matches one of the keys.

A domain without DNSSEC isn’t a finding. Its answers just aren’t marked as validated.

The domain’s DNSSEC is broken

The answer “No. Its DNSSEC is broken.” means resolvers returned SERVFAIL, and Cloudflare’s validating resolver named a DNSSEC failure. Resolvers that check DNSSEC, including Google Public DNS and Cloudflare’s 1.1.1.1, reject the domain’s answers. Visitors who use them can’t reach the site, and mail servers that use them can’t find where to deliver its mail. This is a problem.

The failures we name, and what they mean:

  • “its signatures have expired” (EDE 7). Signatures carry an end date and must be renewed regularly. Something stopped re-signing the zone, such as a failed signing job, or a server that stopped getting updates from the signer. How to fix it: re-sign the zone, and find out why signing stopped. If your DNS provider signs it, contact them.
  • “its signatures don’t validate” (EDE 6). The signatures don’t match the records or the keys, such as when records were changed on one server without re-signing, or two providers serve different signed copies. How to fix it: re-sign the zone where it’s signed, and make sure every name server serves that copy.
  • “the registry’s DS record doesn’t match any of its keys” (EDE 9). See The DS record matches none of the zone’s keys.
  • “its DNSKEY algorithm isn’t supported” (EDE 1). The zone is signed with an algorithm the resolver doesn’t accept: an old one resolvers have dropped, or a new one they don’t support yet. How to fix it: roll the keys over to an algorithm that IANA’s list recommends for signing, then replace the DS record at your registrar.
  • “its answers aren’t signed” (EDE 10). The registry has a DS record, so resolvers expect signatures, but the name servers send none. Signing was turned off, or the domain moved to a provider that doesn’t sign, while the DS record stayed. How to fix it: remove the DS record at your registrar, or turn on signing at the DNS provider and replace the DS record with the one it gives you.

We also name four other failures: signatures that aren’t valid yet, such as from a signer with a wrong clock; keys without the zone-key flag; a missing proof that a record doesn’t exist; and a DS digest type the resolver doesn’t support.

To confirm DNSSEC is the cause yourself, ask a validating resolver twice, the second time with checking disabled:

dig @1.1.1.1 example.com
dig @1.1.1.1 example.com +cd

If the first returns SERVFAIL and the second returns records, DNSSEC is the problem. DNSViz draws the chain from the root to your records and marks where it breaks.

The DS record matches none of the zone’s keys

The DS record at the registry is a fingerprint of one of the zone’s key-signing keys. Here it matches none of the keys the zone publishes now, so resolvers can’t link the zone’s signatures to the registry and reject them. In the DNS lookup, the DS record shows “matches none of its keys”.

Common causes:

  • A move between DNS providers. The new provider signs the zone with its own keys, but the registry still has the old provider’s DS record.
  • Turning signing off and on again, which creates new keys.
  • A key rollover where the new DS record never reached the registry, or the old key was removed too early.
  • A typo in a DS record entered by hand.

How to fix it: copy the current DS record from your DNS provider’s DNSSEC settings, and replace the old one at your registrar. If you’re not keeping DNSSEC, remove the DS record instead. Resolvers can keep the old DS record for its TTL, so the fix takes that long to reach everyone.

The registry lists a DS record

When DNSSEC fails and the registry’s record says the domain is signed, the DNS answer adds that the registry lists a DS record, which is what resolvers check the zone’s keys against. This cross-check compares the DNS and registration answers, so it appears once both have finished.

It tells you where to look. The DS record is at the registry, and you change it through your registrar. The keys and signatures are at your DNS provider. Either the DS record is out of date, or the zone’s signing is broken:

  • If you moved DNS providers or turned DNSSEC off, update or remove the DS record at your registrar.
  • If you changed neither, check the DNSSEC settings at your DNS provider.

Some registrars set the DS record for you when they’re also your DNS provider; Cloudflare does for domains on Cloudflare Registrar. Some registries can also update it from CDS records the DNS provider publishes (RFC 7344).

Turning DNSSEC off or moving DNS providers safely

Order matters. Resolvers check signatures against the DS record they have saved, so the DS record has to go before the signatures do.

To turn DNSSEC off:

  1. Remove the DS record at your registrar.
  2. Wait until the registry has published the change, then wait for the DS record’s TTL to pass, so resolvers forget it. A dig DS example.com lookup shows the TTL.
  3. Only then turn off signing at your DNS provider.

To move to a new DNS provider while DNSSEC is on, there are two ways:

  • Go unsigned during the move. Turn DNSSEC off as above, change the name servers, then turn on signing at the new provider and add its DS record. The domain keeps working, but isn’t protected for a while. RFC 6781 describes this as the only option when the old provider won’t cooperate.
  • Keep DNSSEC on throughout, with a multi-signer migration, where both providers’ keys are published during the move. Both providers have to support it. Cloudflare’s migration tutorial walks through it.

Never point the name servers at a provider that doesn’t sign the zone while the old DS record is still at the registry. That takes the domain offline for everyone whose resolver checks DNSSEC.

The domain’s answers validate

An OK answer that says its answers are “signed with DNSSEC and validate” means Cloudflare’s resolver followed the chain from the root, through the registry’s DS record, to the zone’s keys and the signature on the name’s address, and every link matched. Validating resolvers accept the answers, and can reject forged ones.

Validation proves where the answers came from, not that they’re what you meant to publish. It doesn’t encrypt DNS either. Signatures expire, so a signed zone has to be re-signed on a schedule; providers that sign zones do this for you. Check again after a move or a key change.

Your provider’s guides

What we can’t tell from outside

We ask one validating resolver, Cloudflare’s, about one record type, the name’s A record. If signatures fail only for another type, such as MX, the resolvers return SERVFAIL for it, but we can’t say why. Resolvers differ slightly in what they accept, such as which algorithms they support, so one can fail where Cloudflare’s doesn’t. We don’t check key sizes, rollover schedules, or how close signatures are to expiring.

Sources

Last reviewed .