DNS trust, part 1 of 3 · Reviewed October 24, 2026
A domain can resolve successfully and still leave an important question unanswered: did the DNS answer survive the journey without being forged? DNSSEC gives validating software a way to check that question. Understanding its boundary helps you interpret a DNS checker without mistaking a green indicator for a complete security assessment.
This series follows three different layers: authenticating DNS answers, using those answers to authenticate a TLS service with DANE, and checking email-domain identity with SPF, DKIM and DMARC. They cooperate, but none replaces the others.
What DNS is answering
DNS publishes more than website addresses. A and AAAA records provide IP addresses; MX records identify mail exchangers; other record types carry service information and policies. Your device usually asks a recursive resolver, which finds or retrieves cached answers from the DNS hierarchy. Authoritative servers publish the records for a zone, an administrative portion of that hierarchy.
That distinction matters operationally. Publishing a signed zone and using a validating resolver are separate jobs. A signature nobody checks does not give the client the same assurance as a validated answer. The IETF identifies DNSSEC as best current practice for authenticating DNS data, while retaining the core specifications and their later updates. RFC 9364 explains that standards framework.
A signature needs a trusted starting point
DNSSEC signs sets of DNS records. An RRSIG carries a signature, a DNSKEY supplies a public key, and a DS record connects a child zone’s key to its parent. The private signing key is not published in DNS. Validation follows these relationships back to a configured trust anchor, commonly associated with the DNS root.
Think of a signed document accompanied by evidence about whose signing key you should trust. Seeing a signature-shaped object is only the beginning: the signature, key relationship and validity period must check out. DNSSEC also has mechanisms for authenticated negative answers, so a resolver can validate evidence that a requested name or record type does not exist. The DNSSEC record specification defines these building blocks.
Four outcomes, not one security score
A useful DNSSEC explanation distinguishes these validation states:
- Secure: the answer validates through an applicable chain of trust.
- Insecure: the resolver establishes that a delegation is unsigned; this does not mean it detected an attack.
- Bogus: the answer should validate but fails the necessary checks.
- Indeterminate: the resolver lacks a suitable trust anchor to establish the status.
DNSSEC authenticates DNS data, not the honesty of the organization behind a domain. An attacker can operate a correctly signed domain. It also does not encrypt queries, make a website safe, or guarantee availability. Those limits and validation states are set out in RFC 4033.
DNSSEC and encrypted DNS solve different problems
DNS over HTTPS and DNS over TLS protect the connection between a client and its chosen resolver. DNSSEC checks signed DNS data. You can use both: encrypted transport protects that hop, while validation checks the answer’s authenticated origin. The resolver still receives the query; encryption does not make it disappear from the service handling it. Google’s secure-DNS transport documentation explains the complementary roles.
A checker may display the resolver’s Authenticated Data flag, usually abbreviated AD. Treat that as the resolver’s assertion about the response, not proof that the checker independently rebuilt and verified every signature. Relying on it requires trust in the resolver and the channel carrying its answer. Likewise, an absent AD flag alone does not identify the cause or prove malicious activity. RFC 6840 clarifies how clients and resolvers use AD.
The website connection remains another layer. SysSeder’s TLS guide explains the encrypted connection that follows a lookup; DNSSEC is not a substitute for it.
Check before changing
Start by recording the exact hostname, record type, resolver and time of the observation. Check whether signatures exist, whether the parent’s DS matches the intended signing setup, and whether validation succeeds. If a lookup fails, investigate rather than immediately disabling validation.
Provider migrations deserve particular care. An old parent DS combined with new signing keys can break validation even when the new authoritative servers answer normally. Cloudflare documents this failure pattern and recommends DNSViz for visualizing the trust chain. Follow your providers’ coordinated migration procedure rather than copying a universal disable-and-enable recipe. Its troubleshooting guide shows what to inspect.
The practical takeaway is narrow and useful: ask whether this answer was authenticated, through which resolver, at what time. Next in the series, DANE adds an application decision: how can a TLS client use authenticated DNS information to recognize the service it intended to reach?
To inspect public records and a resolver’s validation indication, use the SysSeder DNS Inspector. Its coverage notes and unknowns matter: it is not an independent cryptographic chain audit or security certification.
Watch: read the DNS evidence, not just the score
This 70-second walkthrough uses a dated public example.com lookup to explain DNSSEC, DMARC and the DNS Inspector’s configuration-signal score. A high score is not a security guarantee, and different email profiles are not comparable grades.
Watch the narrated DNS Inspector walkthrough on YouTube. Captions are included in the video. The player is hosted by YouTube; playing it contacts YouTube.