DNSSEC Check
DNSSEC Check helps you validate dnssec configuration and signatures, for authoritative DNS validation, resolver checks, and faster troubleshooting.
Advertisement · Anuncio
Advertisement · Anuncio
Technical Analysis & Guide
What It Does
The DNSSEC checker queries a domain for its DS record (published by the parent zone through your registrar), its DNSKEY set (published in your own zone) and an NSEC record, then classifies the domain as signed, incomplete or unsigned. It shows up to three DS records and the number of DNSKEYs found. It is a presence check of the chain-of-trust links, not a full cryptographic validation of every signature.
Why It Matters
- →Spoofing protection: Validating resolvers reject forged answers for a signed zone, which blocks cache-poisoning attacks of the kind publicized by Kaminsky in 2008.
- →Broken chains cause outages: A DS at the registrar that no longer matches any DNSKEY makes the domain bogus, and validating resolvers return SERVFAIL for every name.
- →Provider migrations: Moving DNS hosts without first removing or replacing the DS is the most common way signed domains go dark.
- →Dependent standards: DANE for SMTP (RFC 7672) and TLSA records only work on DNSSEC-signed zones, so mail TLS hardening depends on this chain.
- →Compliance signals: Several government and ccTLD programs require or reward DNSSEC on public domains, and auditors check for DS presence.
How to Read Results
- status signed (pass): Both a DS at the parent and DNSKEYs in the zone were found. dsRecords shows up to three entries in the form key-tag algorithm digest-type digest, e.g. 2371 13 2 1F987CC6....
- dnskeyCount: Number of DNSKEY records. Two is typical (one KSK with flags 257, one ZSK with flags 256); more appear during key rollovers or with multiple signers.
- hasNSEC: Whether an NSEC record was returned at the apex. False is normal for zones using NSEC3 or providers that synthesize denial proofs on the fly; it is not an error by itself.
- status incomplete (warn): DNSKEYs exist but the parent has no DS, so the zone is signed but resolvers treat it as insecure. Publish the DS at the registrar to finish the chain.
- status unsigned (warn): Neither DS nor DNSKEY was found. Resolvers treat the domain as insecure and accept unsigned answers.
- Unexpected unsigned result: If the chain is bogus, a validating resolver may return SERVFAIL and the tool sees no data. Confirm with dig +cd DNSKEY example.com before concluding the zone is unsigned.
Technical Background
DNSSEC is defined by RFC 4033 (concepts), RFC 4034 (record types) and RFC 4035 (protocol changes). It adds origin authentication and integrity to DNS without encryption. Each RRset in a signed zone carries an RRSIG signature made with a private key whose public half is published as a DNSKEY at the zone apex. The parent zone publishes a DS record containing a hash of the child's key-signing key, and the parent's own records are signed and vouched for by its parent, up to the root key that validating resolvers ship as a trust anchor. A DS line such as example.com. 3600 IN DS 2371 13 2 1F987CC6... encodes the key tag, the algorithm (13) and the digest type (2, SHA-256).
Most zones use a split-key design. The key-signing key (KSK, DNSKEY flags 257, the SEP bit set) signs only the DNSKEY RRset and is referenced by the DS at the parent; the zone-signing key (ZSK, flags 256) signs everything else. This lets operators rotate the ZSK frequently without touching the registrar, while KSK rollovers require a coordinated DS update. RFC 6781 and RFC 7583 describe the timing: pre-publish the new key, wait for old TTLs to expire, swap signatures or the DS, and only then retire the old key. CDS and CDNSKEY records (RFC 7344, RFC 8078) let a parent that supports them pick up DS changes automatically. Proof of non-existence uses NSEC, which links names in canonical order, or NSEC3 (RFC 5155), which hashes names to limit zone walking; RFC 9276 recommends NSEC3 with zero extra iterations and an empty salt.
Algorithm choice follows RFC 8624. RSASHA256 (8) and ECDSAP256SHA256 (13) are MUST implement for validators, and Ed25519 (15) is RECOMMENDED. Algorithm 13 is the common default today because its keys and signatures are far smaller than RSA, keeping responses under UDP size limits. RSAMD5, DSA and GOST must not be used, and RSASHA1 variants (5 and 7) are not recommended for signing. For DS digests, SHA-256 (type 2) is mandatory and SHA-1 (type 1) must no longer be generated.
A validating resolver assigns each answer one of four states from RFC 4035: secure (a complete, valid chain), insecure (a signed parent proves there is no DS, so the child is deliberately unsigned), bogus (a DS exists but signatures are missing, expired or do not match) and indeterminate. Only bogus breaks resolution: the resolver returns SERVFAIL rather than unverified data. The usual causes are a stale DS after changing DNS providers, expired RRSIGs when a signer stops re-signing, or a KSK rollover in which the DS was swapped before the new key had propagated. Because this tool reads data through a resolver, a bogus zone may simply appear empty; dig +dnssec, dig +cd and delv show the difference.
Common Errors and How to Fix Them
- ProblemDomain returns SERVFAIL everywhere right after switching DNS providers.
- FixThe registrar still publishes the old provider's DS. Remove the DS (or replace it with the new provider's DS) at the registrar. For future moves, remove the DS, wait for the parent DS TTL plus a margin, then change name servers.
- ProblemChecker reports incomplete: DNSKEY present, no DS at parent.
- FixCopy the DS values (key tag, algorithm, digest type 2, digest) from your DNS provider into the registrar's DNSSEC panel. If the registrar supports CDS/CDNSKEY, enable automatic DS publishing instead.
- ProblemDS entered with the wrong algorithm number or a SHA-1 digest.
- FixUse exactly what the signer generates: algorithm 13 if the zone uses ECDSA P-256, digest type 2 (SHA-256). A mismatched algorithm makes the chain bogus.
- ProblemSignatures expired after a self-hosted signer stopped running.
- FixRRSIGs have fixed validity windows. Restart automatic re-signing (BIND dnssec-policy, Knot or PowerDNS), confirm new expiry dates with dig +dnssec, and monitor RRSIG expiration.
- ProblemKSK rollover broke resolution for some users.
- FixThe DS was changed before the new DNSKEY had been published for at least its TTL. Restore a DS matching the key still in use, then redo the rollover following RFC 7583 timing.
- ProblemZone still signed with RSASHA1 (algorithm 5 or 7).
- FixPerform an algorithm rollover to 13 or 8 using your signer's documented procedure, which double-signs the zone before swapping the DS.
Frequently Asked Questions
How do I enable DNSSEC for my domain?
Turn on DNSSEC signing at the provider hosting your DNS zone, which creates the DNSKEYs and signatures. Then publish the resulting DS record at your registrar, either by pasting it into the DNSSEC panel or through automatic CDS support. The chain is complete once this checker reports both DS and DNSKEY.
What does a bogus DNSSEC status mean?
Bogus means a validating resolver expected signatures, because a DS exists at the parent, but could not verify them. It then refuses to return the data and answers SERVFAIL. Typical causes are a DS that no longer matches the zone's keys, expired signatures or an incorrect algorithm. Insecure, by contrast, simply means the zone is unsigned.
Which DNSSEC algorithm should I use?
Algorithm 13, ECDSA P-256 with SHA-256, is the most widely recommended choice: it is mandatory for validators under RFC 8624 and produces small responses. Algorithm 8, RSA/SHA-256, is also fully supported. Ed25519 (15) is recommended but slightly less universally validated. Avoid SHA-1 based algorithms 5 and 7.
Will DNSSEC slow down my website?
The impact is minimal for users. Signed responses are larger and validating resolvers perform extra lookups for DNSKEY and DS, but those are cached like any other record. Using ECDSA keys keeps packets small. The real risk is operational: a broken chain causes outages, so automate signing and monitor it.
Does DNSSEC encrypt DNS queries?
No. DNSSEC proves that answers are authentic and unmodified, but queries and answers remain readable on the network. Privacy comes from encrypted transports such as DNS over TLS (RFC 7858) and DNS over HTTPS (RFC 8484). The two are complementary and can be used together.
Academic Documentation
Protocol context and primary references
REST API Documentation
v1.0GET /api/tools/dnssec
curl -X POST https://epcybertools.com/api/tools/dnssec \
-H "Content-Type: application/json" \
-d '{"domain":"cloudflare.com"}'
{
"success": true,
"results": [
{ "test": "Sample Check", "status": "pass", "message": "All clear" }
]
}
Usage Examples
# DS at the parent and DNSKEYs in the zone
dig DS example.com +short
dig DNSKEY example.com +multi
# Look for the ad (authenticated data) flag
dig @1.1.1.1 A example.com +dnssec | grep flags