Route 53 Subdomain Delegation: Cross-Account DNS and ACM Certificate Verification

How DNS delegation works

DNS is a hierarchy. The root zone delegates authority for .com to Verisign's name servers. Verisign delegates example.com to your Route 53 hosted zone. Your hosted zone can delegate api.example.com to another hosted zone (in any account) by adding NS records pointing to the child zone's name servers.

When a resolver queries api.example.com:

1. Root → .com name servers
2. .com → example.com name servers (your main hosted zone)
3. example.com → sees NS records for api.example.com → redirects to child zone name servers
4. Child zone → returns the actual answer

Cross-account subdomain delegation

The most common production pattern: a root account owns the apex domain, and each environment or team gets a subdomain in their own account.

Step 1: Create the child hosted zone in the child account

# In account B (api team)
aws route53 create-hosted-zone \
  --name api.example.com \
  --caller-reference unique-string-$(date +%s)

# Note the four Name Server values returned
# Example: ns-123.awsdns-45.com, ns-456.awsdns-67.net, ...

# Terraform in account B
resource "aws_route53_zone" "api" {
  name = "api.example.com"
}

output "name_servers" {
  value = aws_route53_zone.api.name_servers
}

Step 2: Add NS records to the parent zone in the root account

# Terraform in account A (root account)
resource "aws_route53_record" "api_delegation" {
  zone_id = aws_route53_zone.root.zone_id
  name    = "api.example.com"
  type    = "NS"
  ttl     = 300

  records = [
    "ns-123.awsdns-45.com.",    # note trailing dot — required for FQDN
    "ns-456.awsdns-67.net.",
    "ns-789.awsdns-01.org.",
    "ns-012.awsdns-34.co.uk.",
  ]
}

After this, any records added to the api.example.com hosted zone in account B resolve correctly. Account B has full DNS authority over the subdomain.

ACM certificate validation after delegation

TLS certificate validation via DNS (the AWS recommended method) requires adding a CNAME record that ACM specifies. After delegation, this CNAME must go in the child zone, not the parent.

Certificate request: *.api.example.com in account B
ACM says: add CNAME _abc123.api.example.com → _def456.acm-validations.aws.

Where to add it: api.example.com hosted zone in account B

This is correct because api.example.com authority belongs to account B's zone after delegation. Adding the validation record to account A's zone won't work — resolvers won't find it there because account A's NS records for api.example.com point to account B.

# In account B — both the certificate and its validation record
resource "aws_acm_certificate" "api" {
  domain_name       = "*.api.example.com"
  validation_method = "DNS"
}

resource "aws_route53_record" "api_cert_validation" {
  for_each = {
    for dvo in aws_acm_certificate.api.domain_validation_options : dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  }

  zone_id = aws_route53_zone.api.zone_id   # api.example.com zone in account B
  name    = each.value.name
  type    = each.value.type
  ttl     = 60
  records = [each.value.record]
}

resource "aws_acm_certificate_validation" "api" {
  certificate_arn         = aws_acm_certificate.api.arn
  validation_record_fqdns = [for record in aws_route53_record.api_cert_validation : record.fqdn]
}

# Check what NS records the parent zone returns for the subdomain
dig NS api.example.com @8.8.8.8

# Should return the child zone's name servers, not the parent's
# Expected: ns-123.awsdns-45.com., ns-456.awsdns-67.net., ...

# Check that the child zone answers authoritatively
dig A something.api.example.com @ns-123.awsdns-45.com

# Check the full resolution chain
dig +trace api.example.com

# Verify ACM validation record is in the child zone
dig CNAME _abc123.api.example.com