Defaults.Exposed

Route 53 DNSSEC with a KMS key and a DS record

You’ve found the DNSSEC switch at AWS Route 53 and want to know whether pressing it finishes the job or can take the domain offline. That depends on where the two halves happen: the DNS host signs the zone and produces a DS record; the registrar lodges it in the parent zone. Until both are done, no resolver validates anything.

Route 53 is the DNS host that signs the hosted zone using a customer managed AWS KMS key. It publishes a DNSKEY and a DS record once signing is enabled, but it does not publish that DS record into the parent zone; the registrar does that part.

What a signed zone proves

DNSSEC attaches signatures to the answers your DNS hands out, so a resolver can confirm that the address it got for your domain came from your zone and wasn’t changed on the way. It says nothing about what’s running at that address, and nothing about email: a signed domain can still have its name forged on a message, because the controls for that are SPF, DKIM and DMARC, covered on the DMARC page.

The signing happens wherever the zone is served, so it’s a DNS host job, and the host publishes the public key in the zone as a DNSKEY record. The DS record is a hash of that key, and it belongs one level up, in the parent zone (.com, .org, .co.uk, whichever your domain sits under), where a resolver picks up the chain of trust before it asks your nameservers anything.

Only the registrar can place a record there, so the DS goes through the registrar’s account, which may or may not belong to the company running your DNS. Of the 316,600,902 domains carrying a grade or counted dead in the September 2026 census, 21,732,692 (6.9%) are signed and validate, and 173,606 (0.05%) are signed and broken, meaning a DS record is lodged and the signatures in the zone don’t match it. The order below keeps you out of the second group.

Confirm who answers DNS before you touch anything

Open the Route 53 console, go to Hosted zones, open the hosted zone for the domain, and note the NS record values. The registrar’s nameserver setting must match those four Route 53 nameservers exactly. If the domain’s nameservers point elsewhere, enable DNSSEC at whichever provider runs the DNS instead of Route 53.

The steps run in the order that can’t break the domain, and each carries its own wait; this one has none. What it decides is which steps happen inside AWS Route 53 and which happen in another account. Skip it and you can end up signing a zone no resolver is querying, or lodging a DS for a key the live nameservers aren’t using.

Switch DNSSEC on

  1. Sign in to the AWS console and open Route 53.
  2. Go to Hosted zones and open the hosted zone for the domain.
  3. Open the DNSSEC signing tab and choose Enable DNSSEC signing.
  4. For the key-signing key, choose Create customer managed key or select an existing eligible one.
  5. Confirm the key is asymmetric, has usage Sign and verify, uses the ECC_NIST_P256 spec, and sits in the US East (N. Virginia) us-east-1 region.
  6. Give the KSK a name, then confirm and enable signing so Route 53 signs the hosted zone.
  7. On the DNSSEC signing tab, find DS record under Establish a chain of trust and read the Key Tag, Signing algorithm, Digest algorithm and Digest values.
  8. If the domain is registered through Amazon Registrar, follow the console’s DNSSEC section under the domain’s settings to publish the DS record there.
  9. If the registrar is a different company, open its DNSSEC or DS record section and enter the Key Tag, Algorithm, Digest Type and Digest exactly as shown.
  10. Save at the registrar so the DS record is accepted in the parent zone.

Route 53 publishes the DNSKEY and generates the DS record values on its own once signing is enabled. It does not publish the DS record into the parent zone; the reader has to carry those values to the registrar and save them there, even when the registrar is Amazon Registrar.

Signatures and the DNSKEY have to be live on the nameservers before a DS pointing at them is lodged anywhere, because once the DS lands in the parent zone, validating resolvers demand signatures that match it. In a two-company setup this is the point to stop, wait for the DNS host to show the zone as signed, and only then carry the DS across.

The DS record, value by value

A DS record carries four values, shown together on one panel once signing is on. The key tag is a number identifying which DNSKEY the record refers to. The algorithm names the signing algorithm the host chose: 13 is ECDSA P-256 with SHA-256, what most hosts generate today; 8 is RSA with SHA-256, still valid; 5 and 7 are older RSA variants a fresh setup shouldn’t use.

The digest type says how the key was hashed: 2 is SHA-256, the one to publish; 4 is SHA-384, which some hosts offer alongside it; 1 is SHA-1, which registries are removing. The digest is the fingerprint itself, 64 hexadecimal characters for SHA-256, with no spaces. Here is what the panel gives you to carry across:

Key Tag: [value shown on the DNSSEC signing tab]
Signing algorithm: [value shown on the DNSSEC signing tab]
Digest algorithm: [value shown on the DNSSEC signing tab]
Digest: [value shown on the DNSSEC signing tab, paste only]

Lodge the DS values exactly as the host displays them. If the host offers two digest types for the same key, the SHA-256 one alone is enough. There’s nothing to tighten afterwards: the strength of the record is fixed by the algorithm the host signs with, and a host that manages the keys rolls them and refreshes the DS itself.

Where each value goes depends on the registrar’s form. The key-signing key is created inside Route 53’s DNSSEC signing tab, not typed as a DNS record: set key usage to Sign and verify, spec to ECC_NIST_P256, and region to us-east-1. At the registrar, the DS record fields are Key Tag, Algorithm (typically 13), Digest Type (typically 2) and Digest, entered exactly as Route 53 displays them with no TTL field involved.

Paste every value rather than typing it. A digest with one wrong character produces a DS that no key in the zone matches, and a validating resolver can’t tell that apart from a hijacked zone, so it refuses the whole domain. Match the algorithm and digest type numbers to the panel, whatever the registrar’s form offers as a default.

A few things trip people at AWS Route 53 in particular.

Wait, then check the chain

Two waits stack here, and they aren’t the same length. DNSSEC changes can take from minutes up to a day to fully propagate and validate. The DS record values appear on the hosted zone’s DNSSEC signing tab under Establish a chain of trust once signing is confirmed.

The parent zone is the slower one. The registry publishes the DS on its own schedule, and any resolver that looked your domain up recently keeps the old answer, with no DS in it, until the parent’s TTL runs out, which can be up to a day. During that window one network can show the domain validating while another shows it unsigned, and both are reporting what they’ve cached.

Once that day has passed, run the free scan against the domain. It validates the way a resolver does and reports each link separately: whether a DS is published in the parent, whether it matches a DNSKEY in the zone, and whether the signatures verify.

Check the DNSSEC signing tab on the hosted zone to confirm signing is still enabled and that the displayed Digest still matches what was saved at the registrar.

To see the raw answer, ask a validating resolver with dig:

dig +dnssec yourdomain.com A

Read the flags on the header line. ad means the resolver validated the chain and it held. A normal answer with no ad means the resolver saw the domain as unsigned, so after the wait the DS hasn’t reached the parent zone or was never lodged. SERVFAIL means the chain is there and broken, and the DNSSEC SERVFAIL page walks through which link.

Broken is worse than unsigned. Validating resolvers, including the large public ones, drop the domain for their users while everyone else still reaches it, so the outage looks intermittent and gets blamed on hosting.

Before you move DNS or turn signing off

The step that catches people comes months later, when the domain moves to a new DNS host or signing gets switched off and the DS record stays behind in the parent zone. From then on validating resolvers demand signatures the new nameservers aren’t producing, and the domain returns SERVFAIL for their users until someone removes the DS.

So the teardown runs in reverse. Remove the DS record at the registrar first, wait out the parent’s TTL so no resolver still holds a copy, and only then switch signing off or change the nameservers. A domain with no DS and a signed zone is treated as unsigned, which is safe; a domain with a DS and no signatures is treated as forged, which is the outage.

The other habit is signing in one place. If the DNS host already signs the zone, its DS goes to the registrar and the registrar’s own signing switch stays off; two signers means two keys and one DS, and resolvers refuse whichever half doesn’t match. The DNS page covers the other records in the same zone.

Before you log out of the registrar, write down where the DS is lodged and the key tag it carries, next to the renewal date, with “remove the DS first” beside it. That note is what stops the domain going dark the day someone changes the nameservers.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.