About domains and DNS
DNSSEC: understanding validation results and their limits
Understand valid, unsigned, failed, and indeterminate results, DS and DNSKEY, and differences from registration data.
Updated: October 9, 2026
DNSSEC adds digital signatures so resolvers can validate that DNS data came from the responsible zone. It does not encrypt DNS traffic.
In NetKarte
Enter the domain or hostname in DNSSEC Check, complete verification, and search. Read the status and validation result: the presence of DS or DNSKEY alone does not establish successful validation.
NetKarte uses Cloudflare's validating resolver. It reports Valid when DS, DNSKEY, and SOA responses are successful, DS and DNSKEY records exist, and all three responses carry AD (Authenticated Data). NetKarte does not independently verify every signature.
It reports Unsigned when no DS is returned and the related queries succeed. This decision does not require AD and does not mean that NetKarte itself verified a signed proof of nonexistence. SERVFAIL with certain DNSSEC extended errors produces Bogus; insufficient evidence produces Indeterminate. Failure to complete a query may instead appear as a retrieval error.
Limitations
DNSSEC validates DNS data authenticity but does not encrypt the query. Successful validation does not guarantee overall website safety; TLS and application security are separate layers.
Read status before records
After entering a name, check both the input hostname and evaluated zone. SOA discovery can select a different zone for a subdomain. Read status and validation first, then DS and DNSKEY.
Keep DS Key Tag, Algorithm, Digest Type, and Digest within one record; likewise DNSKEY Flags, Protocol, Algorithm, and Key Tag. Multiple keys or DS records can occur during transitions and are not errors by count alone. Public-key text is not currently displayed.
Why registration information can differ
Domain lookup shows published registration data; DNSSEC Check uses current DNS responses and resolver validation. Sources and zones can differ. Missing information is not equivalent to validation failure. For failure, give the DNS administrator the evaluated zone and status so signatures and parent DS can be investigated.
References
- IETF / RFC Editor: RFC 4033: DNS Security Introduction and Requirements (External site)Checked: 2026-10-09
- IETF / RFC Editor: RFC 4034: Resource Records for the DNS Security Extensions (External site)Checked: 2026-10-09
- IETF / RFC Editor: RFC 4035: Protocol Modifications for DNSSEC (External site)Checked: 2026-10-09
- IETF / RFC Editor: RFC 8484: DNS Queries over HTTPS (External site)Checked: 2026-10-09