DNS integrity diagnostic

DNSSEC Checker

Validate a live answer from the root trust anchor to the authoritative zone. See the exact delegation path, cryptographic record details, resolver claims, protocol behavior, and the first link that evidence says is unsigned or broken.

Domain, hostname, or URL URLs, Unicode domains, punycode, and one final root dot are normalized. Paths and ports are not queried.

Signed RRset

Validation resolver

Advanced evidence and proposed DS validation

Run UDP, EDNS0 + DO, and TCP diagnostics Validate proposed DS before a registrar change

Examples (press Check after choosing):

Ready. No DNS request is made until you press Check DNSSEC.

Requested DNS answer

Wire RCODE, requested values, TTLs, authoritative agreement, and alias hops are answer evidence—not the DNSSEC verdict. A secure verdict can authenticate a positive answer, NODATA, NXDOMAIN, or compact NXNAME denial.

First unsigned or failing link

A missing DS proves an insecure delegation; it is not a broken signature. A bogus verdict requires validation-failure evidence, not just SERVFAIL or a timeout.

Findings and recommended actions

Evidence-backed operational findings, including server diagnostics and current IANA algorithm guidance.

Root → TLD → authoritative chain

Direct delegation observations are joined to the independent validator trace. Each link says where its evidence came from and when full DNSKEY material was not returned.

DS, DNSKEY, RRSIG, NSEC, and NSEC3 evidence

Parsed fields are shown only for records present in authoritative or delegation responses. Choose DNSKEY as the signed RRset when you need full public-key rows. Denial-record presence is evidence; the server-side validator supplies its proof verdict.

Delegation, authority, and glue

Parent and child NS sets, reachable authoritative servers, SOA serials, and in-bailiwick glue context.

Resolver AD/CD claims

These are explicitly resolver claims. AD says that resolver reports authentication; CD control evidence helps separate validation failure from ordinary DNS failure. Neither is presented as browser-side cryptographic validation.

Protocol and proposed-change diagnostics

Optional authoritative UDP, EDNS0/DO, TCP evidence and API-honored proposed DS matching.

Raw evidence

Useful for escalation and reproduction. JSON export contains the complete response and derived report.

Unsigned is unprotected, not broken

When a signed parent proves that no DS exists for a child, validators continue with ordinary insecure DNS. The name can resolve, but its answers are not authenticated by DNSSEC.

Bogus means validation must fail

A parent DS promises a signed child, but a required DS/DNSKEY/RRSIG proof does not validate. Correct validating resolvers return SERVFAIL; stale DS data after a provider migration is a common cause.

Standards used by this report

RFC 4033 — secure, insecure, bogus, and indeterminate validation states.
RFC 4034 and RFC 4035 — DS, DNSKEY, RRSIG fields and chain validation.
RFC 5155 — NSEC3 authenticated denial of existence.
RFC 9276 — current NSEC3 iteration, salt, and Opt-Out operational guidance.
RFC 9824 — compact NXNAME denial signaled by NXNAME or its TYPE128 compatibility form.
RFC 9904 and the current IANA DNSSEC Algorithm registry / DS Digest registry — separate recommendations for signing, delegation, and legacy validation.

Guidance snapshot verified 2026-08-25. The IANA DNSSEC Algorithm registry was updated 2026-08-10 and the DS Digest registry 2026-01-13. Registry recommendations can change; follow the linked live registries before planning a rollover. A legacy algorithm that is disallowed for new signing can still be required for validation, so its presence alone does not make this report bogus.