DNSSEC Checker — DNSKEY and DS Record Validation

Standard DNS returns answers with no integrity proof — a network attacker can inject forged A, MX, or TXT records while TTLs remain cached. DNSSEC attaches digital signatures (RRSIG) to record sets and publishes public keys (DNSKEY) so validating resolvers can detect tampering. DS records at the parent zone fingerprint the child KSK so the chain anchors at the TLD and root.

Our checker focuses on presence detection: do DNSKEY and DS answers exist for the name you enter? Full validation requires a resolver configured for DNSSEC and walking the chain through each delegation. This page answers the first question operators ask during rollout — is signing material published where resolvers expect it?

DNSKEY records contain flags, protocol, algorithm, and the public key material for zone signing keys. A zone signing key (ZSK) signs day-to-day records; a key signing key (KSK) signs the DNSKEY set itself. When dnskeyRecords returns non-empty data, the zone operator has published keys — typically meaning signing is active or staged on the authoritative side.

Empty DNSKEY with empty DS usually means the zone is unsigned at that label. Empty DNSKEY with present DS can indicate a misconfiguration or propagation delay after key rollover. Copy raw strings into your DNS provider ticket when opening support cases about algorithm mismatches.

DS records live at the parent zone and contain a key tag, algorithm, digest type, and digest hash of the child KSK. Registrars publish DS when you enable DNSSEC through their panel or supply DS data from your DNS host. hasDs true at the apex means a DS query returned answers — often confirming registrar publication for signed domains.

Some operators publish DNSKEY first and delay DS until they verify signing on authoritative servers. Our recommendation text nudges unsigned zones toward enabling DNSSEC and reminds signed zones to monitor DS updates after KSK rollovers — stale DS breaks validation for the entire subtree.

We query through Google Public DNS JSON API for consistency with other live lookup tools in this suite. Google operates a widely used anycast resolver fleet; answers reflect what that path sees at query time. Corporate split-horizon DNS or unpublished internal views may differ from public results.

If Google returns NXDOMAIN or empty answers while your authoritative panel shows records, wait for TTL expiry or verify you published at the correct zone label. Apex domains need keys at example.com, not only at www.example.com, unless you intentionally sign per-label.

Run before enabling DNSSEC with your DNS host, after KSK rollover events, during acquisition due diligence on domain portfolios, and when troubleshooting mail or HTTPS issues that coincide with DNS changes. Compliance frameworks increasingly ask whether critical domains publish DNSSEC — export our JSON or copy record strings into evidence binders.

Also check after migrating between DNS providers. Keys and DS formats must match what the new host expects. A successful migration often requires generating new DNSKEY, updating DS at the registrar, then removing old DS only after propagation completes.

Mail delivery does not require DNSSEC the way it requires MX, SPF, and DKIM. However, unsigned zones remain vulnerable to DNS spoofing that could redirect MX lookups toward attacker-controlled hosts during cache poisoning scenarios. Defense in depth treats DNSSEC as one layer alongside TLS and mail authentication.

Pair this checker with our email deliverability and SPF/DKIM/DMARC tools when hardening a domain. DNSSEC protects DNS integrity; SPF and DMARC protect mail sender identity. They solve different threat models and complement each other in enterprise architecture reviews.

dnssecEnabled true when either DNSKEY or DS answers appear. Both present is the common healthy pattern for a signed apex with registrar DS. DNSKEY-only may mean DS publication is pending. DS-only without DNSKEY warrants investigation — the parent may reference keys the child no longer publishes.

Recommendation copy for signed zones reminds you to validate with a DNSSEC-aware resolver and plan KSK rollover ceremonies. Unsigned zones receive guidance to consult your DNS host and registrar about enabling signing — not every TLD registrar supports DS upload equally.

Key signing key rollover is the highest-risk DNSSEC maintenance event. Publishing new DNSKEY before updating DS, waiting for propagation, then removing old DS prevents validation outages. Automated monitors should alert when DS digest changes unexpectedly.

Our tool is a point-in-time snapshot, not continuous monitoring. Schedule rechecks after every DNSSEC-related change and archive results. Pair with DNS TTL checker when planning how long old DS should remain during transition windows.

Seeing DNSKEY does not prove signatures validate end-to-end. Expired signatures, wrong algorithms, or broken NSEC/NSEC3 chains still fail validating resolvers while our presence check passes. Use dedicated DNSSEC debug tools or dig +dnssec for full validation when troubleshooting resolver failures.

We do not query RRSIG, NSEC, or CDS records. Advanced deployments using CDS/CDNSKEY for automated DS updates need additional tooling beyond this page.

Lookups query public DNS for domains you submit. We do not store searches permanently. Use results for legitimate security audits, migration planning, and infrastructure documentation — not for unauthorized reconnaissance.

DNSSEC record strings are public by design once published. Copying them into tickets does not expose private keys — only public key material and digests appear in DNSKEY and DS answers.