DNSSEC SERVFAIL Fix: Stale DS, Broken Chain, Safe Nameserver Move

Your domain suddenly stops opening, and dig shows SERVFAIL. In many cases, DNSSEC is the cause. The DS record at your registrar no longer matches the keys on your nameservers.

This guide is a simple runbook for DNSSEC SERVFAIL stale DS troubleshooting. You will find the broken link, fix it, change DNSSEC or nameservers in the safe order, and wait the right TTL time.

In this guide, example.com is the broken domain. Replace it with your own domain. We assume you have a running Ubuntu 26.04 or Ubuntu 24.04.

First, you must install the DNS tools, including dig and delv, which are in bind9-dnsutils, and dnssec-dsfromkey is in bind9-utils:

Check the versions, time, and date with the commands below:

You should see System clock synchronized: yes. If it says no, fix the time before anything else:

Create a work folder and set variables. Keep every output in this folder, so you can compare before and after:

PARENT is the zone that holds your DS record. For example.com it is com. For example.co.uk it is co.uk.

Then, save the current state. This is your evidence and your rollback data:

Follow these steps in order. Each step checks one link in the DNSSEC chain, so you can find the exact break. Save every output in your work folder so you can compare it after the fix.

First, make sure the domain really returns SERVFAIL. Ask a few public resolvers that check DNSSEC, because they can give different answers:

Look at the status: line in each result, which tells you the reason:

Try two more resolvers, because they can behave differently:

Newer dig versions print an Extended DNS Error (EDE) in the OPT PSEUDOSECTION. It gives a reason. These are the common ones:

Not every resolver returns an EDE. If you do not see one, continue to the next step.

Now check if DNSSEC is the cause. The +cd option (checking disabled) tells the resolver to skip the DNSSEC check:

Compare the results with the normal query:

This one test is the base of DNSSEC SERVFAIL stale DS troubleshooting. It tells you if you are fixing the right problem.

Also, you can use delv. It validates DNSSEC by itself and gives the reason:

If it works, you see ; fully validated. If it fails, you see resolution failed and the reason.

Next, follow the full DNS path. The +trace option starts at the root servers and goes down to your nameservers:

• The .com servers point to your nameservers. Check that they are the ones you expect. If not, the registrar has old or wrong NS records.
• If you see a DS line and its RRSIG, the parent says your domain is signed.
• Your nameservers answer last. If they time out or refuse, the problem is not DNSSEC.

Note: +trace does not validate anything. It only shows you the path and the data. Use it to look, not to decide.

Now check what the parent zone says about your domain. The DS record is stored at the parent, for example, in .com, and it points to your key. Ask a parent server directly, so you see the real DS and not a cached copy:

Read it from left to right:

• 86400 is the TTL in seconds. It tells you how long resolvers can keep the DS.
• 2371 is the key tag. It points to one DNSKEY.
• 13 is the key algorithm.
• 2 is the digest type. 2 is SHA-256.
• The last value is the digest, the fingerprint of the key.

Write down the TTL. You will need it later.

If this command shows no DS, the parent does not expect DNSSEC. Then a DNSSEC chain error is not the cause, and the problem is elsewhere, or only a cached DS is left.

Now check the keys on your nameservers. Ask each nameserver for its DNSKEY records, one by one:

All of them must return the same keys, and one key must match the DS you found in Step 4. If the keys are different or missing on one server, resolvers can fail on some tries only.

If DNSKEY queries time out, but normal A queries work, a firewall may block large UDP answers or TCP port 53. Test TCP:

At this point, you should compare the DS at the parent with your real keys. Create a DS from the DNSKEY that your nameservers serve, then check it with the DS from Step 4:

If the command prints nothing, your zone has no key with flag 257 (KSK). If your zone only uses a key with flag 256, add -A to the command.

Now compare the four values: key tag, algorithm, digest type, and digest.

Even with a good DS, expired signatures give SERVFAIL. Ask for a signed record:

The RRSIG line has the format type algorithm labels original-TTL expiration inception key-tag signer signature. The dates are in UTC as YYYYMMDDHHMMSS. Check them with the current time:

The result must be OK. This means the signature has started and has not expired yet. If it says BAD, your signer stopped re-signing the zone. Fix the signer (see the BIND section below) or contact your DNS provider.

Also, check that the keytag= value matches one of the keys in your DNSKEY set.

Finally, check the domain with a visual tool, like DNSViz or the Verisign DNSSEC Debugger. These tools draw the DNSSEC chain and mark the broken link in red. Use them to confirm what you found with dig.

You can put all the checks above in one script. It tests the public resolvers, reads the DS at the parent, and checks the keys and signatures on every nameserver. Run it any time a domain returns SERVFAIL, and you get the main facts in a few seconds. Create the file with:

Add the following script to the file:

Save the file, make it executable, and run it:

Most DNSSEC failures come from a small set of causes. Find your symptom in the table below to see the cause and the fix. Use the results from the steps above to confirm it before you change anything.

Stale DS is the top cause in DNSSEC SERVFAIL stale DS troubleshooting. It happens like this:

• The domain was signed at the old DNS provider. The registrar holds a DS for the old key.
• You changed the nameservers to a new provider.
• The new provider has different keys, or no keys at all.
• Validating resolvers still see the old DS. It does not match. They return SERVFAIL.

Pick one of the three fixes below.

It is the fastest way to restore the domain. Log in to your registrar. If you use PerLod, open your domain in the client area and go to the DNSSEC settings.

Delete the DS record and check that the parent no longer has it:

No output means the DS is gone at the parent. Resolvers may keep the old DS in cache until its TTL ends. Check the real status on public resolvers:

You can clear the cache of the big public resolvers: Google Public DNS cache flush and Cloudflare cache purge.

The domain works again, but it is now unsigned. You can turn DNSSEC on later, in the safe order below.

Use this if the new provider already signs your zone.

First, check that all new nameservers serve a DNSKEY and good signatures (Steps 5 and 7).

Then, get the new DS from your new DNS provider, or create it yourself:

At the registrar, delete the old DS and add the new one. Enter the four values: key tag, algorithm, digest type, and digest. Some registrars ask for the DNSKEY public key instead. Then, they build the DS for you.

Finally, run Step 4 and Step 6 again. The parent DS and the computed DS must be the same.

If the old provider still has the signed zone and the same keys, set the old nameservers again at the registrar. The old DS then matches again.

Use this only when the old zone is still correct and signed. For more on rollback and zone copy checks, read the guide on changing nameservers without downtime.

Algorithm and digest errors are the second group in DNSSEC SERVFAIL stale DS troubleshooting. The DS has the right key tag but wrong numbers. A resolver needs all four values to match.

These are the common algorithm numbers:

These are the digest types you will see most often:

Fix a mismatch like this:

1. Do not type the numbers manually. Create a new DS from your live DNSKEY with dnssec-dsfromkey -2.
2. Replace the old DS at the registrar with the new one.
3. If the registrar does not accept your algorithm, switch the zone to an algorithm it supports. Follow the disable and re-enable steps in the next section, because changing the algorithm while a DS is live is risky.

One wrong character in the digest breaks the chain. Always copy and paste the DS.

Order is the most important rule in DNSSEC SERVFAIL stale DS troubleshooting. The parent (DS) and the child (DNSKEY) must never disagree for longer than the cache time.

The simple rule: the DS goes last when you turn DNSSEC on, and first when you turn it off.

Use this order when you want to disable DNSSEC or when you switch to a new DNS provider. The DS record must go first, and the keys must go last. If you do it the other way, the DS has no key to match, and the domain returns SERVFAIL.

1. Read the DS TTL from Step 4. Example: 86400 seconds (1 day).
2. Remove the DS at the registrar.
3. Keep the zone signed. Do not remove the keys yet. Resolvers that cached the old DS still need valid keys.
4. Wait at least the DS TTL. A safer rule is 1.5 times the TTL. If the TTL is 24 hours, wait 36 hours.
5. Confirm the DS is gone on public resolvers.
6. Only now, turn off signing at your DNS provider or remove dnssec-policy from the BIND zone.
7. Verify that the zone has no DNSKEY and still resolves.

Use this order when you turn DNSSEC on again. Sign the zone first, check that every nameserver serves the keys, and add the DS record last. This way, the DS always has a key to match when resolvers check it.

1. Turn on signing at your DNS provider or set a dnssec-policy in BIND. Prefer algorithm 13.
2. Check that every nameserver returns the DNSKEY and good RRSIG records (Steps 5 and 7).
3. Wait a short time so all nameservers and caches are in sync. If you use low TTLs (300 seconds), 10 to 15 minutes is enough.
4. Create the DS and add it at the registrar.
5. Check that the parent now shows the DS (Step 4) and that Step 6 matches.
6. Check that resolvers validate the domain (see the next section).

Do not change your nameservers and your DNSSEC settings at the same time. Each change has its own cache time, so the old and new data can overlap and break the chain. Make one change, wait for the TTL, check the result, and only then make the next one.

1. Remove the old DS and wait for the DS TTL.
2. Change the nameservers at the registrar.
3. Wait for the old NS TTL to end (the parent NS TTL for .com is often 2 days, so check yours with dig).
4. Enable DNSSEC at the new provider.
5. Add the new DS at the registrar.

TTL is the time, in seconds, that resolvers keep a record in their cache. After you change a DS, a nameserver, or a key, some resolvers still show the old data until the TTL ends. The table below shows what to wait for after each change, so you do not make the next step too early.

Read the real TTL values from your own dig output. They are the second number on each line:

You can only change the TTL of your own zone records. The DS and NS TTL at the parent are set by the registry, and you cannot lower them.

After you fix the problem, do not trust only your own computer. Your local resolver may still show old cached data. Check the domain on several public resolvers, confirm that DNSSEC validation passes, and compare the result with your previous files.

Check from the parent, from your nameservers, and from public resolvers:

A good result shows status: NOERROR. If the domain is signed, the flags: line also has ad (Authenticated Data), for example flags: qr rd ra ad. If the domain is unsigned on purpose, there is no ad flag. This is normal.

You can run delv for a clear answer:

Look for ; fully validated. Then save the result and compare it with your saved files:

If you run your own resolver, clear its cache:

Finally, check the website and mail:

Skip this section if your DNS provider signs the zone for you. If you run your own authoritative server, BIND 9.20 can sign the zone and re-sign it automatically with dnssec-policy. This prevents expired signatures.

Install BIND and open the zone config with the commands below:

Add the zone. Replace example.com with your domain:

The folder /var/lib/bind/ is writable by BIND on Ubuntu. BIND keeps the signed copy of the zone there, and the keys are stored in /var/cache/bind/. Create the zone file:

Add your records. Use your own IPs and names:

Fix the file owner, then check the config and the zone:

Allow DNS through the firewall. Use both UDP and TCP, because signed answers are large:

Reload BIND and check the signing state:

Test the signed zone on the server:

Create the DS to give to your registrar:

Add the DS at the registrar. Then tell BIND that the DS is published, so it can continue its key plan:

Every time you edit the zone file, raise the serial number first, check it with named-checkzone, and then reload:

A domain that returns SERVFAIL after a DNS change is usually a broken DNSSEC chain. Use +cd to prove it, then check the parent DS, the DNSKEY on every nameserver, and the RRSIG dates. A stale DS or a mismatched algorithm or digest is the most common cause.

The fix is almost always about order and waiting. Remove the DS first and wait for its TTL before you turn off signing. Sign first and add the DS last when you turn DNSSEC on. Never change nameservers and DNSSEC in the same minute. Keep this page as your DNSSEC SERVFAIL stale DS troubleshooting checklist.

When your domain is working again, read the DNSSEC and WAF configuration guide to set up DNSSEC and protect your server in the right way.

To keep your domain and DNS settings in one place, register and manage your domain through PerLod. Then use this guide whenever you change authoritative DNS or DNSSEC settings.