How does the DNSSEC chain of trust differ from an X.509 certificate path, and what does the difference mean when a signer's key is compromised?
answer
- one tree, one root
- parents sign only their children
- a hash, not a certificate
- links fetched by query
- damage limited to a subtree
basics
~20 sA DNSSEC chain follows the DNS tree: only a zone's parent can vouch for its key, from a single root. So a compromised DNSSEC key forges only names below its zone, while in the web PKI any trusted CA can issue for any name.
solid answer
~50 sBoth systems chain signatures up to a trust anchor, but DNSSEC's chain is fixed by the namespace. The keys for `example.com` can be vouched for only by `com`, and `com`'s only by the root, so every name has exactly one path, set by its delegations. The links are plain DNS records, not certificates. A parent signs a `DS` that holds a digest of the child's key, with no subject, issuer or extensions, and the resolver fetches each link with an ordinary query. RFC 6698 sums up the consequence: a compromised DNSSEC signer can compromise only keys in its own subdomains. In the public web PKI, by contrast, client software typically lets any trusted CA issue for any name. The cost is that you must trust every parent above you, and you cannot choose another one.
go deeper
Recall the core contrast: DNSSEC trust follows the DNS tree from one root, while the web PKI lets many CAs vouch for any name.
Explain the links concretely: a DS digest signed by the parent versus a certificate signed by an issuer. Explain that a resolver fetches DNSSEC links by query, and say what each design limits a compromise to.
Reason through compromise scenarios at child, parent and root level, and the operational flip side: parent operators and registrars sit permanently in your chain, and one bad DS takes the whole child down.
Weigh namespace-constrained trust against a many-issuer market: concentration of power in parent operators against the weakest-link exposure of many CAs, and what each means for where an organisation anchors identity.
## Same idea, different shape Both DNSSEC and X.509 public-key infrastructure answer one question: *why should I believe this public key belongs to this name?* Both answer it with a chain of signatures ending at a **trust anchor**, a key you trust because it was configured, not because something vouched for it. The shape of the chain, and therefore what a compromise costs, differs sharply. RFC 6698, which uses DNSSEC to publish TLS keys, sets out the comparison in its motivation section. Its three points are the backbone of a good answer: 1. **Keys are tied to DNS names**, not to arbitrary identifying strings. 2. **Signed keys for any domain are reachable online** with an ordinary DNSSEC query, so distribution is solved. 3. **The keys for `example.com` can only be signed by the keys for `com`, and those only by the root.** An untrustworthy signer can compromise only names in its own subdomains. ## Side by side | Aspect | DNSSEC chain of trust | X.509 certificate path (public web model) | |---|---|---| | Who may vouch for a name | only the parent zone in the DNS tree | any CA the client trusts, for any name | | Number of roots | one root zone, usually one anchored key set | many CA roots shipped with client software | | Paths per name | exactly one, fixed by delegations | possibly several, through different issuers | | What a link is | a signed `DS` record holding a digest of the child's `DNSKEY` | a certificate binding a subject name to a key, signed by an issuer | | How links reach the verifier | the resolver queries DNS for each `DS` and `DNSKEY` RRset | typically the server presents its chain during the handshake | | What expires | each `RRSIG` carries its own validity window | each certificate carries its own validity window | | Withdrawing trust | remove the `DS` or key; trust fades as cached copies expire | separate certificate revocation machinery | ## What a compromise costs This is the question interviewers are really asking. - **A compromised child key** (say `example.com`'s) lets an attacker forge data for `example.com` and anything below it, until the zone replaces the key and the parent updates its `DS`. Nothing outside that subtree is affected. - **A compromised parent key** (say `com`'s) is worse. The attacker can sign a forged `DS` for any child of `com`, pointing at a key they control, and so forge any name under `com`. They still cannot touch names under `org` or `net`, because `com` has no say there. - **A compromised root key** reaches everything, which is why the root key-signing key is handled with such care and why RFC 5011 has rules for revoking and replacing trust-anchor keys. In the public web PKI, RFC 6698 points out, "client software typically allows any CA to usefully sign any other certificate", and the model "allows any of these CAs to issue a certificate for any domain name". One compromised CA among many can therefore impersonate any site. That is the single weakest-link problem DNSSEC's tree structure avoids. ## The price of the tree The namespace constraint is not free: - **You cannot choose your vouchers.** `example.com` must trust whoever operates `com` and the root. There is no shopping around and no second opinion; a zone has one parent. - **Parents hold power over children.** A parent operator, or anyone who compromises it, can redirect trust for every child. - **Breakage cascades.** If a parent's `DS` stops matching the child's key, every name in the child fails validation. That is a key-rollover and operations problem, but the tree is why it is so widespread when it happens. - **Escape hatches are local.** A resolver can configure its own anchor for a zone, an *island of security*, but that is resolver policy, not a second issuer the world can see. ## What is not different Some things look different but are not. Both systems rely on anchors that ship with software or configuration. RFC 6698 notes that DNSSEC keys "come built into the DNSSEC client software", just from a single root rather than a multiplicity of CAs. Both use time-limited signatures. In both, the verifier must check every link and must not skip one because a later link looks fine. The deeper mechanics of building and validating an X.509 path belong to the certificate side of the house. The point here is the contrast in structure, not the algorithm for either.
- If com's DNSSEC signing key were compromised, which names could an attacker forge, and how?Any name under `com`, but nothing outside it. The attacker signs a forged `DS` for a child such as `example.com`, pointing at a key they hold, then signs forged data with that key. Validators accept it because the `DS` carries a valid `com` signature. Names under `org` or `net` are safe, since `com` never vouches for them. Recovery needs `com` to change its key and its own parent's `DS` for it to follow.
- Why can a DNSSEC zone not use a second parent the way a certificate can chain through a second issuer?A DNS name has exactly one parent zone, and the `DS` that vouches for it can live only on that parent's side of the cut. So there is exactly one public path from the root. The only alternative is local: a resolver operator can configure that zone's key as a trust anchor of its own. That helps only that resolver and is not a second issuer the world can see.
saying these in an interview costs you the question
- Any TLD operator can sign a valid DNSSEC key for any domain, just as any CA can.
- DNSSEC uses X.509 certificates issued by the domain's registrar.
- A DNSSEC zone can get a second parent to vouch for it, like a cross-signed CA.
- Because each zone signs its own data, a compromised parent key cannot affect child zones.
- A TLS server sends the DNSSEC chain to the resolver, as with certificates.