(Domain Name System Security Extensions) signs DNS data so a resolver can prove an answer was not tampered with. When you query with +dnssec (which sets the do flag), the extra records appear alongside the normal ones.

The record types

  • RRSIG is a signature over a set of records of one type (an RRset). Its rdata leads with the type it covers, the algorithm number, a label count, the original , a signature expiration and inception time, a key tag, and the signer's name, followed by the signature itself. The validity window matters operationally: an expired RRSIG makes a validating resolver return SERVFAIL, and expired signatures are a common cause of a domain that "suddenly stopped resolving" for some users but not others.
  • is a public key for the zone. A validator uses it to check the RRSIGs in that zone. Its rdata is a flags field, a protocol byte (always 3), an algorithm, and the key material.
  • DS (Delegation Signer) is the link between a parent zone and a child. It is a hash of the child's DNSKEY (DNS Public Key record), published in the parent. Its rdata is a key tag, an algorithm, a digest type, and the digest. This is the record you give your registrar to turn DNSSEC on for a delegation.
  • (Next Secure record) and (Next Secure version 3) provide authenticated denial of existence. Instead of simply saying "no such name," a signed zone proves the gap: NSEC points to the next existing name, and NSEC3 does the same over hashed names to make walking the zone harder. This is how a validated NXDOMAIN or NODATA is itself trustworthy.

The chain of trust

Validation is a chain from the root down. A resolver trusts the root's key (the single configured trust anchor), uses the root's DS to vouch for the top-level domain's DNSKEY, uses that to validate the 's (top-level domain) DS for the next zone, and so on down to the name you asked about. Each hop is a DS in the parent matching a DNSKEY in the child, and each RRset is covered by an RRSIG. A break anywhere, a missing DS at a delegation, a key rollover that removed the wrong key, an expired signature, snaps the chain and the resolver returns SERVFAIL.

What ad actually means

The ad (Authentic Data) flag in the header is the resolver's verdict: it means this particular resolver validated the chain and it held. It is not proof you can independently trust unless you trust the resolver and the path to it, and it does not mean the client validated anything. If you asked with do set and got real data back but ad is not set, the resolver either did not validate or the data is unsigned; that gap is usually the thing worth chasing.

The AD flag tells you what somebody else concluded

ad in a response means the resolver you asked validated the chain. It does not mean the answer is signed, and it does not mean you validated anything.

Between that resolver and your application is a path you may not control. A forged response with the bit set looks exactly like a validated one to anything that trusts the flag without validating, which is why the bit is only meaningful over a trusted channel to a resolver you trust.

If validation matters to you, validate — +dnssec and checking the RRSIG yourself answers your question. The AD flag answers somebody else's.