DNSSEC Checker

Ordinary DNS has no authentication built in. A resolver asks a question, gets an answer over UDP, and has no way to confirm the answer came from the real authoritative server rather than an attacker who guessed the query and raced a forged reply back first - the Kaminsky cache-poisoning class of attack works because nothing in the protocol vouches for a reply beyond a matching transaction ID. DNSSEC closes that gap not by encrypting anything (answers stay just as visible on the wire) but by attaching a signature to each record set, so a resolver can verify authenticity even over an untrusted network path.

That signature has to be checkable without blindly trusting whichever server answered. DNSSEC solves this with a chain of trust that starts at the DNS root and follows the same delegation path plain DNS already uses down to the queried zone - it adds signatures and key records to servers already being asked, not new ones.

• DNSSEC authenticates DNS answers; it does not encrypt them - anyone can still see the query and response
• The chain of trust follows the existing delegation path (root → TLD → domain), it does not introduce a separate hierarchy
• A validating resolver either gets a signature that checks out, or it does not - there is no partial trust
• A domain with no DNSSEC records at all is simply unsigned, which is the default and not itself an error

A DNSKEY record holds a zone's public signing key. Most zones publish two: a Zone Signing Key (ZSK) that signs the zone's regular record sets, and a Key Signing Key (KSK) that signs the DNSKEY record set itself - splitting the two lets an operator rotate the ZSK often without touching the KSK, the one the parent zone has to know about. The DNSKEY rdata carries flags (257 marks a KSK via the Secure Entry Point bit, 256 marks a ZSK), a protocol field fixed at 3, an algorithm number, and the public key itself.

A DS (Delegation Signer) record lives in the parent zone, not the child - a hash of the child zone's KSK, published where the parent already holds the child's NS records. This is the actual link in the chain of trust: a resolver that already trusts the parent can fetch the child's DS record, compute the hash of the DNSKEY the child presents, and confirm they match before trusting anything the child zone signs. No DS record at the parent means the chain stops there, even if the child zone itself is fully signed.

An RRSIG record is the signature attached to a signed record set - one RRSIG per record type per zone, covering every record of that type at that name in one signature. Its rdata carries the type it covers, the algorithm and key tag identifying which DNSKEY produced it, expiration and inception timestamps, and the signature bytes themselves. Signatures are time-limited on purpose: a zone keeps re-signing on a rotation schedule, bounding how long a captured signature stays replayable if it ever leaked outside its intended window.

A validating resolver that successfully checks a zone's entire chain - DS at the parent matching the hash of the child's DNSKEY, RRSIG verifying against that DNSKEY, all the way up to the root - sets the AD (Authenticated Data) bit on its response. That single bit is what most applications actually read: a resolver somewhere in the path did the cryptographic work and the answer passed. A resolver that gets a DS record but cannot complete validation, or that receives records with no signatures at all, does not set AD.

This checker reports three chain states. Secure means the zone is signed and the resolver validated the chain end to end (AD set). Unsigned means no DS or DNSKEY record was found at all - the default state for the large majority of domains, not a fault, just the absence of opt-in. Insecure means the zone carries DNSSEC records but the resolver did not get a validated answer: usually a missing or stale DS record at the parent leaves nothing to authenticate against, and it is also where a genuine validation failure surfaces here. That failure case is what DNSSEC exists to catch - a mismatched key, an expired RRSIG, or a tampered response, which RFC 4033 calls bogus - and a validating resolver is supposed to refuse such an answer outright rather than pass it along as if nothing were wrong.

Algorithm choice affects none of this logic but does affect longevity: RSA/SHA-256 (algorithm 8) remains the most widely deployed, while ECDSA P-256 (algorithm 13) and Ed25519 (algorithm 15) produce far shorter signatures and keys for equivalent security margins, which is why newer deployments increasingly favor them over RSA.

DNSSEC's guarantee is narrow: if an answer arrives with AD set, that record set is the one the zone owner actually signed, unmodified in transit. It says nothing about whether the zone owner's content is trustworthy, whether a mail server in an MX record is well-configured, or whether a site behind an A record is safe to visit - separate questions DNSSEC was never designed to answer.

It also hides nothing: query and signed answer both travel in the clear, exactly as unsigned DNS does. Confidentiality is a different problem, addressed by DNS-over-HTTPS or DNS-over-TLS at the transport layer - orthogonal to DNSSEC and commonly deployed alongside it rather than instead of it.