What Makes Up the DNSSEC Chain of Trust?

When DNSSEC is enabled for a domain, you may encounter labels such as DNSKEY and DS. Seeing those items individually does not, by itself, show that a DNS response can be authenticated. A validating resolver needs to build a connection from a starting point it already knows to the signed DNS response. The DNSSEC chain of trust describes that structure. This topic is not about diagnosing an outage or listing record-change steps. Its purpose is to distinguish, at a conceptual level, how trust progresses through the DNS hierarchy. The basic structure consists of a trust anchor, DNSKEY and DS record sets, and the key associated with the private key that signs the requested DNS data.

At a glance

• The DNSSEC chain of trust is a chain of signed data made from alternating DNSKEY and DS record sets.
• A validating resolver starts with a configured trust anchor.
• A DNSKEY verifies the signature covering a DS record set, while a DS contains a hash of another DNSKEY.
• The chain ends with a DNSKEY whose corresponding private key signs the requested DNS data.
• A signed delegated zone without the relevant DS link in its parent is an island of security.

The chain of trust is not one record

RFC 4033 defines an authentication chain as an alternating sequence of DNSKEY and Delegation Signer, or DS, record sets. It is a chain of signed data, with each link vouching for the next. For that reason, it is not enough, conceptually, to assess DNSSEC only by whether an individual DS or DNSKEY item is present.

The source shows the typical authentication chain as DNSKEY followed by zero or more DS-to-DNSKEY subchains, followed by an RRset. The asterisk means that the DS-to-DNSKEY subchain can be absent or can occur more than once.

DNSKEY and DS do not have the same role in this structure. A DNSKEY is used to verify the signature covering a DS record set. Verifying that signature allows the DS record set to be authenticated. A DS contains a hash of another DNSKEY. The resolver authenticates the next key by matching the hash in the DS with the relevant DNSKEY.

• The chain is an alternating sequence of DNSKEY and DS record sets.
• A DNSKEY is used to verify the signature covering a DS record set.
• A DS contains a hash of another DNSKEY.
• Matching the DS hash with a DNSKEY moves the chain to the next key.

Source: [1]

The starting point: a trust anchor

A validating, security-aware resolver does not begin the validation chain without a starting point. A trust anchor is a DNSKEY configured in the resolver, or a DS hash of a DNSKEY. The resolver begins building an authentication chain to a signed DNS response from that known public key or hash.

This start matters because the resolver traces newly learned public keys back to a previously known authentication key. That known key can have been configured in the resolver, or it can have been learned and verified previously. RFC 4033 therefore says that a resolver must be configured with at least one trust anchor.

In short, trust does not arise automatically from the domain name itself. It depends on an authentication connection that can be built between an accepted starting point and the signed response being requested.

• A trust anchor is a configured DNSKEY or a DS hash of a DNSKEY.
• The resolver builds the chain from this starting point.
• A resolver must be configured with at least one trust anchor.

Source: [1]

How the DNSKEY and DS link progresses

The core movement in the chain depends on two separate relationships. First, a DNSKEY verifies the signature covering a DS record set. This allows the DS information to be authenticated. Next, the hash in the DS record set matches another DNSKEY. That lets the resolver move to the next DNSKEY link.

Example scenario: imagine that the root DNSKEY record set is used to authenticate the DS record set for example. In this case, the root DNSKEY is used to verify the signature covering the example. DS record set. The hash in the example. DS record set also matches one of the example. DNSKEY records. This illustrates a connection progressing from the root towards the key for the example. zone.

The same relationship can continue through as many DS-to-DNSKEY subchains as needed. At every stage, the questions are the same: which DNSKEY verifies the signature covering the DS record set, and which DNSKEY matches the hash in the DS? Distinguishing those two links is more useful than treating the record names as isolated labels.

• A DNSKEY verifies the signature covering a DS record set.
• The authenticated DS provides a hash of another DNSKEY.
• Matching the hash with the relevant DNSKEY creates the next link.
• The structure can include zero or more DS-to-DNSKEY subchains.

Source: [1]

How the chain reaches signed DNS data

According to RFC 4033, the chain finally ends with a DNSKEY whose corresponding private key signs the requested DNS data. In other words, the DNSKEY and DS links followed by the resolver eventually reach the DNSKEY associated with the private key that signs the requested data.

It is important to separate the role of the private key here. The source does not describe the private key itself as the readable item at the end of the chain; it describes the DNSKEY corresponding to that private key. The private key signs the requested DNS data, while the validation path built by the resolver is described through DNSKEY and DS record sets.

The DNSSEC chain of trust is therefore not just a check of one key or one hash. It is a chain of signed data that starts with a trust anchor and progresses through verification of signatures covering DS record sets and matches between DS hashes and subsequent DNSKEYs.

• The chain ends with a DNSKEY.
• That DNSKEY’s corresponding private key signs the requested DNS data.
• The chain is the authentication path between a trust anchor and signed data.

Source: [1]

Island of security: why being signed is not enough

An island of security is a signed, delegated zone for which the delegating parent does not contain a DS record holding a hash of one of the zone’s DNSKEY records. In that situation, there is no authentication chain from the delegating parent to that zone.

This definition shows the difference between being signed and being authenticated from the parent. A zone can be signed, but if the DS link in the parent is absent, the chain described by the source does not continue to that zone.

RFC 4033 states that responses from an island of security, or from its descendants, can be authenticated only if their authentication keys can be authenticated by a trusted means outside the DNS protocol. For example, a delegated zone can be signed and have DNSKEY records, while the parent has no DS record containing a hash of one of those DNSKEY records. That example represents the island-of-security definition; it is not a diagnosis of any particular domain configuration.

• An island of security has no DS record in the parent carrying the relevant DNSKEY hash.
• Being signed alone does not mean that an authentication chain exists from the parent.
• Without trusted authentication of the keys outside DNS, responses from the island cannot be authenticated.

Source: [1]

Practical checklist

• Treat DNSSEC validation as a chain that begins with a trust anchor in the resolver.
• Distinguish between a DNSKEY verifying the signature covering a DS record set and directly validating the DS record set.
• Keep the two DS functions separate in your model: it contains a hash of another DNSKEY, and that hash matches the DNSKEY.
• Remember that the chain ends with the DNSKEY whose corresponding private key signs the requested DNS data.
• When considering a signed delegated zone, consider whether the parent has a DS link containing a hash of the relevant DNSKEY.
• If that parent link is absent, consider the island-of-security definition and the need for trusted authentication of keys outside DNS.

The DNSSEC chain of trust starts with a trust anchor in the resolver. A DNSKEY verifies the signature covering a DS record set, and the hash in the DS matches the next DNSKEY. These links can continue as needed until they reach the DNSKEY whose corresponding private key signs the requested DNS data. If the parent-side DS link is absent, a signed delegated zone can be an island of security.

Frequently asked questions

What is a trust anchor in the DNSSEC chain of trust?

A trust anchor is a DNSKEY configured in a validating resolver, or a DS hash of a DNSKEY. The resolver uses this information as the starting point for building an authentication chain to a signed DNS response.

How does a DNSKEY authenticate a DS record set?

A DNSKEY is used to verify the signature covering the DS record set. That signature verification allows the DS record set to be authenticated. The hash in the DS then matches another DNSKEY.

What is an island of security?

An island of security is a signed, delegated zone whose delegating parent has no DS record containing a hash of one of that zone’s DNSKEY records. Its responses cannot be authenticated unless its keys are authenticated by a trusted means outside the DNS protocol.

Sources

[1] rfc4033.txt