DNSSEC

Domain Name System Security Extensions, or DNSSEC, adds cryptographic authentication to DNS. Ordinary DNS does not inherently prove that an answer is authentic, so an attacker who successfully injects a forged response can redirect clients to an unintended address. DNSSEC allows a validating resolver to check signatures before accepting protected DNS data. Its protections depend on correct authoritative signing, a valid chain of trust, and validation along the client's resolution path.

DNSSEC signs resource record sets rather than individual packets. An RRSIG record carries a signature over a record set, such as the A records for www.example.com. DNSKEY records publish the zone's public keys. A Delegation Signer, or DS, record in the parent zone contains a digest identifying a child zone's signing key. A resolver follows these relationships from a configured trust anchor, normally the DNS root, through the parent zones to the requested zone. NSEC or NSEC3 records provide authenticated denial of existence, allowing a resolver to verify that a requested name or record type does not exist.

Authoritative signing and recursive validation are separate functions. A DNS hosting provider can sign a public zone, but clients using a nonvalidating resolution path do not automatically gain protection against forged answers. Conversely, enabling validation on a recursive resolver does not sign the domains an organization owns. A validating resolver distinguishes secure answers, unsigned or insecure answers, and bogus answers that fail expected validation. Unsigned DNS is not automatically rejected; a broken chain for a zone that should validate normally causes SERVFAIL.

For example, when securing example.com in a cloud public DNS service, first enable zone signing and verify that the authoritative servers publish the expected DNSKEY and RRSIG records. Then publish the corresponding DS record through the domain registrar so it appears in the parent zone. Simply adding an NS delegation, or publishing a DS record inside the child zone itself, does not establish the required parent-to-child trust relationship. Delegated subdomains require their own signing and DS configuration if they are to participate in the chain.

In Amazon Route 53, DNSSEC signing is available for public hosted zones, not private hosted zones. Route 53 manages the zone-signing key, while a key-signing key is backed by a customer managed asymmetric AWS KMS key. That KMS key must be in US East (N. Virginia), use the ECC_NIST_P256 key specification, and have SIGN_VERIFY usage. Configure the required key policy, enable signing, and publish the generated DS details in the parent zone. Route 53 Resolver DNSSEC validation is a separate VPC setting for public DNS resolution; it does not validate private hosted-zone data or DNS responses obtained through forwarding rules.

Hybrid and multi-account designs must therefore identify where validation actually occurs. If an on-premises resolver forwards public queries to a cloud resolver, confirm that the receiving resolution path validates those queries. If cloud queries are forwarded to on-premises DNS, configure validation where that forwarded resolution is performed rather than assuming a VPC setting protects every answer. Signing keys, parent-zone DS records, and resolver settings may also belong to different accounts or teams, requiring coordinated changes.

Operational trade-offs include larger DNS responses, additional validation work, key-management responsibilities, and the possibility of resolution failures after configuration mistakes. Permit both UDP and TCP port 53 where DNS transport requires them, because larger responses can require TCP fallback. Plan key rollovers around DNSKEY and DS cache lifetimes, and never remove a key while cached trust information still depends on it. When disabling signing, remove the parent DS record and allow relevant caches to expire before stopping signatures. Monitor signing health, key accessibility, signature expiration, and validation failures.

DNSSEC provides authenticity and integrity, not confidentiality, service availability, or proof that an application is trustworthy. DNS over TLS and DNS over HTTPS encrypt a DNS transport connection; they complement rather than replace DNSSEC. HTTPS is still needed to authenticate and encrypt application traffic. During troubleshooting, requesting DNSSEC records with dig +dnssec does not itself validate them; use a validating tool or a trusted validating resolver and interpret its validation result.