CertaDNS

Free Tool · DNSSEC

DNSSEC Analyzer

Walk the chain of trust one link at a time — DS at the parent, keys in the zone, whether the digests match, and whether the signatures are actually being refreshed.

Free · no signup · reads public DNS only ·

What the DNSSEC Analyzer checks

DNSSEC signs your DNS answers so a resolver can tell them from forged ones. It works as a chain: your registrar publishes a DS record in the parent zone, that DS is a digest of a DNSKEY in your zone, and that key signs everything else. Break any link and validation fails.

Most free checkers tell you whether validation passes and stop. That is unhelpful in both directions — when it passes you learn nothing about whether your algorithm is deprecated or your signatures are about to lapse, and when it fails you get a red cross and five possible causes. This one reports each link separately.

The failure that matters most

A DS record at the parent with no matching key underneath it is worse than being unsigned. Validating resolvers fail closed: for them, the domain simply does not exist. Everyone else — including, usually, whoever is testing — sees it working perfectly. This is why the order of operations matters so much: enable signing at your DNS provider first, publish the DS at your registrar second. Never the other way round.

Algorithms

RFC 8624 classifies the signing algorithms. Algorithm 13 (ECDSA P-256) is the usual choice today — small signatures, broad support. Algorithm 8 (RSA SHA-256) is sound and widely deployed. Anything SHA-1 based (5 and 7) is deprecated. We report what you are using and what the guidance says.

Signature freshness

Signatures expire. If the resigning job stops, the zone keeps serving valid-looking answers right up until the day it goes dark for every validating resolver. We measure how far through its own lifetime each signature is, rather than counting days — providers that sign on the fly use lifetimes as short as two days quite deliberately, and flagging that as an emergency would be wrong.

NSEC and zone walking

DNSSEC has to prove a name does not exist, and the original mechanism — NSEC — does that by pointing at the next name that does. Follow the chain and you can enumerate the entire zone, including internal hostnames nobody meant to publish. NSEC3 hashes the names to prevent it, and some providers instead synthesise an NSEC record per query, which is equally safe. We tell the three apart.

Frequently asked questions

Should I turn DNSSEC on?+

If your DNS provider and registrar both support it, yes — and enable signing before you publish the DS. The risk in DNSSEC is almost never the cryptography; it is the operational half, where a DS that outlives its key takes the domain offline for validating resolvers.

What is the difference between a KSK and a ZSK?+

The key-signing key is the one your DS record points at, and it signs the key set. The zone-signing key signs the actual records. Splitting them means you can rotate the ZSK freely without touching your registrar, which is the awkward part of any rollover.

My signatures expire in two days. Is that bad?+

Not by itself. Providers that sign on the fly use short lifetimes deliberately and refresh continuously. What matters is how far through its own lifetime a signature is — which is what this tool measures, rather than counting days.

Is NSEC really a problem?+

It depends what is in your zone. A static NSEC chain lets anyone enumerate every name in it, which is usually more interesting to an attacker than to you — internal hostnames, staging environments, things you forgot were published. NSEC3 costs nothing to switch on.

Which algorithm should I use?+

Algorithm 13 (ECDSA P-256 with SHA-256) for a new zone: small signatures, broad validator support. Algorithm 8 is fine if you are already on it. Move off 5 and 7 — both are SHA-1 based and deprecated by RFC 8624.

Check something else

  • SPF Inspector

    Will my SPF record pass, or has it quietly gone over the lookup limit?

  • DMARC Inspector

    Can someone send mail as my domain right now?

  • DKIM Inspector

    Is my DKIM key actually published, and is it strong enough?

Understand it, then fix it