DNSSEC, the Domain Name System Security Extensions, adds authentication to DNS data. A validating resolver checks the origin of signed records and whether they have been altered since signing. It does this with public keys, delegation records and digital signatures. DNSSEC does not encrypt ordinary DNS queries, hide which names are requested or prove that the website at an authenticated address is safe.

The three record types to recognize are DNSKEY, DS and RRSIG. DNSKEY publishes a zone's public key; a parent-zone DS record links trust to a child zone; and RRSIG contains a digital signature. The signatures apply to record sets, or RRsets: records with the same name, class and type. For example, several A records giving IPv4 addresses for one hostname form an RRset rather than being authenticated as unrelated answers.

Follow the Chain of Trust

A validating resolver starts from a configured trust anchor, commonly for the DNS root, and works down the hierarchy. A trust anchor is a public key or a DS value accepted through a trusted configuration process. It supplies a starting point that the resolver does not have to authenticate through a higher DNS zone. A zone is a portion of the DNS namespace managed under one set of authoritative data.

At a signed parent-to-child delegation, the parent publishes a DS record referring to a child DNSKEY. The resolver authenticates the parent's DS RRset, then compares a DS digest with a hash calculated from the child DNSKEY's owner name and record data. It uses the matching key to verify a signature on the child's DNSKEY RRset, establishing which keys can authenticate the child's other data. The resolver may need additional DNS queries to obtain these records.

The chain matters because a signature alone is not automatically trustworthy. Anyone could create a key and sign a zone copy. An authenticated proof that the parent has no DS can establish an insecure delegation, even when the child publishes signatures. In that case, validation through the parent is unavailable, although a separately configured trust anchor for the child can establish another trusted starting point.

Understand DNSKEY and Key Roles

A DNSKEY record holds a public key and metadata for DNSSEC. The corresponding private key is used by the zone signer and must be protected by the operator; it is not published in DNS. A resolver uses the public key to verify signatures. The key algorithm and flags are part of the record's interpretation, but simply seeing a DNSKEY does not prove that a validating resolver trusts it.

Operators often separate a key-signing key (KSK) from a zone-signing key (ZSK). In a typical design, the KSK signs the DNSKEY RRset and is the key connected to the parent DS, while the ZSK signs the zone's other data RRsets. These are operational roles, not a requirement that every zone use exactly two keys. A combined signing key can serve both roles.

The parent stores the DS record as a digest reference to a child key rather than a copy of the full public key. When a zone operator changes signing keys, parent and child data must remain coordinated. With a supported DS, an absent or mismatched child key can break validation unless another valid path exists. A nonvalidating query may still return an answer in that situation.

What an RRSIG Proves

RRSIG carries a digital signature over a particular RRset along with information such as the covered type, signing algorithm, key tag and validity period. A validating resolver checks the signature with an authenticated DNSKEY. Altering the signed record data makes that signature fail verification. The resolver also checks the signature's start and expiration times, so a working signing process must keep signatures current.

For example, if a signed A RRset is returned with its RRSIG, the resolver verifies that the address data matches the signature and that the key used is connected through the trust chain. The result authenticates the DNS statement about the address. It does not test whether packets can reach that address, whether a web server is listening or whether the site has a valid TLS certificate.

DNSSEC can also authenticate a statement that a name or record type does not exist. Signed NSEC or NSEC3 records supply evidence that a resolver checks against the requested name and type. A bare empty answer is not enough to establish an authenticated negative result. The proof must apply to the relevant part of the DNS tree.

Read the Four Validation States

These states describe whether the resolver can authenticate the data and whether it expected signatures to be available. They depend on the resolver's trust configuration, so they are not properties of a domain name alone.

  • Secure: The resolver establishes a trusted path to the RRset and verifies the signatures needed to authenticate it. The DNS data is authenticated under that chain.
  • Insecure: The resolver knows that no usable authentication chain connects the data to its trusted starting points, for example because it has authenticated the absence of a parent DS. The data may contain signatures, but they are not authenticated through that chain.
  • Bogus: The resolver has reason to expect a valid signed path, but the required signature, key or proof cannot be validated. This can reflect misconfiguration, stale data, corruption or an attack; the status alone does not establish the cause.
  • Indeterminate: The resolver cannot determine whether the data should be signed with the trust or DNSSEC information available to it. No applicable trust anchor, or an inability to obtain the information needed to establish that expectation, can leave the state undecided.

Interpret Resolver Results

These labels are not a rating of the website's content. An insecure answer is not automatically forged, and a bogus answer is not proof of an attack. When validation is required, a recursive resolver normally returns SERVFAIL for data it cannot authenticate as expected. SERVFAIL also has other causes, so that response alone does not diagnose a DNSSEC failure.

If two resolvers disagree, first ask whether both validate DNSSEC and whether they use the same trust anchors, supported algorithms and delegation data. Cached signatures and records may also differ temporarily. A missing signature is different from a verified unsigned delegation, and a timeout alone does not establish either condition. Changing resolvers without understanding that distinction can hide a validation problem.

For a domain-specific failure, record the queried name and record type, the resolver used, the time and any detailed validation error. The zone operator can use that information to examine the parent DS, child DNSKEY and RRSIG records involved. Keep normal validation enabled while the responsible operator investigates the failed link or signature.