A chain of trust allows a system to accept information from an unfamiliar source because each relationship leading to that source can be verified. The chain starts at a trust anchor: a public key or other credential accepted through a trusted process outside the chain itself. Every subsequent link must satisfy the relevant cryptographic and policy checks. Cloud engineers encounter this pattern in DNSSEC, TLS certificate validation, software signing, and verified boot, although each uses different records and validation rules.
For DNSSEC, a validating recursive resolver normally starts with a DNS root trust anchor. The root zone authenticates the delegation signer, or DS, record for a signed top-level domain. That domain authenticates the DS record for a signed child zone, such as example.com. Each DS record identifies a child-zone signing key through a cryptographic digest of its DNSKEY record. The resolver checks this relationship, validates the child zone's DNSKEY record set, and then uses authenticated keys to verify signatures over the requested DNS record set.
DNSSEC uses DNSKEY records to publish public keys and RRSIG records to carry signatures. In the common split-key model, a key-signing key, or KSK, signs the DNSKEY record set, while a zone-signing key, or ZSK, signs other authoritative record sets. NSEC or NSEC3 records provide authenticated denial of existence. Simply publishing a DNSKEY or signing records does not establish a publicly verifiable chain: the parent must publish the correct DS record, and the resolver must perform validation.
For example, when enabling DNSSEC signing for a public hosted zone, first establish signing and confirm that the zone serves the expected DNSKEY and signatures. Then publish the corresponding DS record through the registrar or the operator of the parent zone. For a delegated subdomain owned by another account, publish its DS record in the parent zone. Account boundaries do not change the DNSSEC hierarchy; parent and child operators must coordinate the delegation.
Amazon Route 53 illustrates the separation between signing and validation. It can sign public hosted zones, using a customer-managed asymmetric AWS KMS key for the KSK while managing the ZSK itself. The KMS key must be in US East (N. Virginia), use ECC_NIST_P256, and have SIGN_VERIFY usage. Separately, Route 53 Resolver can validate DNSSEC for public DNS lookups from a VPC when validation is enabled. Public hosted-zone signing does not enable resolver validation, and Route 53 private hosted zones do not support DNSSEC signing.
A validating resolver distinguishes secure answers, insecure answers without an authenticated signed delegation, and bogus answers that fail required validation. A missing DS record generally leaves the child insecure rather than proving that it is signed. By contrast, a stale DS record pointing to a retired key can make an otherwise reachable domain bogus, commonly producing SERVFAIL. During troubleshooting, inspect the parent DS, child DNSKEY, signatures, signature validity periods, and resolver behavior rather than assuming that a DNS timeout or SERVFAIL means the authoritative server is unavailable.
The main trade-offs are operational complexity, larger DNS responses, and stricter failure behavior. Key rollovers and disabling signing require carefully ordered changes that account for TTLs and cached data. Hybrid forwarding and centralized multi-account DNS also require identifying which resolver validates each query path; forwarding alone does not establish trust. DNSSEC authenticates DNS data and detects unauthorized modification, but it does not encrypt queries, guarantee availability, or prove that the destination application is trustworthy. HTTPS remains necessary for transport confidentiality and server authentication.
Amazon Route 53