Cross-account Route 53

Delegating subdomains to hosted zones in other AWS accounts lets each environment or team manage its own DNS without access to the parent domain.

The mechanism is an NS record in the parent zone pointing at the child zone’s name servers. Nothing is shared between the accounts: the parent simply says “for this subdomain, ask those servers”.

Structure

• Parent DNS account — holds the hosted zone for the registered domain, example.com.
• Child accounts — hold hosted zones for subdomains: dev.example.com, test.example.com, and so on.

Hosted zones

A hosted zone is a container for the records that define how traffic is routed for a domain or subdomain. Every hosted zone is created with two record sets:

• NS — the four name servers Route 53 has assigned to this zone
• SOA — administrative information about the zone

Delegating a subdomain

In the parent account

1. Confirm the hosted zone for example.com exists and its NS records match what the registrar publishes for the domain.
2. Note the domain’s name servers; you will be adding a delegation to them.

In the child account

1. Create a public hosted zone for the subdomain, dev.example.com.
2. Record the four NS values Route 53 generated for it.

Use a public hosted zone

NS delegation from a public parent zone works only if the child zone is public. A private hosted zone’s name servers are not reachable from the internet, so the delegation resolves to nothing and dev.example.com is dead on the public internet.

For private, VPC-internal subdomains do not delegate at all — associate the VPC with the private hosted zone using a VPC association authorization. See cross-account private hosted zones.

Back in the parent account

1. Open the example.com hosted zone.
2. Create a record of type NS with the name dev.example.com.
3. Enter the four name server values from the child account’s hosted zone, one per line.

That is the delegation. Records created in the child account under dev.example.com now resolve publicly, and the parent account never sees them.

Repeat for each subdomain and account.

Verify

# The parent zone should return the child's name servers
dig +short NS dev.example.com

# Query the child's name servers directly to confirm they are authoritative
dig @ns-1234.awsdns-12.org dev.example.com SOA

What this buys you

Separation. A team with permission to change dev.example.com has no permission over example.com. A mistake in one environment cannot take the apex down.

Visibility. Queries, health checks and query logging are per hosted zone, so each environment’s DNS activity is separately observable and billable.

Simpler IAM. Route 53 permissions are granted per hosted zone; delegation gives you a natural boundary to grant them on.

Practice

• Grant each child account permission on its own hosted zone only.
• Keep the parent account’s role in the process to creating and reviewing delegations.
• Record delegations somewhere outside Route 53 — a delegation that nobody remembers creating is one nobody dares delete.
• Use a consistent subdomain convention: environments (dev, test, staging), or Regions (eu-west-2), but not both at the same level.

Troubleshooting

Symptom	Look at
The subdomain does not resolve	Is the child zone public? Do the NS values in the parent match the child’s current name servers?
It resolves for some clients only	Propagation. The parent zone’s own TTL on the NS record governs this
It resolved and then stopped	The child hosted zone was deleted and recreated; Route 53 assigns new name servers, and the parent’s NS record now points at the old ones
Records exist but return NXDOMAIN	The records are in a different zone from the one delegated — check for a duplicate hosted zone for the same name

Related pages

• Cross-account private hosted zones
• Route 53 and DNS