Delegating a subdomain to another Route 53 hosted zone is how you give ownership of a part of your DNS namespace to a different team or service, allowing them to manage its records independently.
Let’s say you own example.com and want to delegate app.example.com to a separate Route 53 hosted zone. This is common when you have a distinct application team that needs to manage the DNS for their specific subdomain without affecting the parent zone.
Here’s how it works in practice.
First, you create a new public hosted zone for your subdomain.
aws route53 create-hosted-zone --name app.example.com --caller-reference app-example-com-delegation-$(date +%s)
This command creates a hosted zone for app.example.com and returns a HostedZoneId and a set of NameServers. You’ll see output like this:
{
"Location": "https://route53.amazonaws.com/2013-04-01/hostedzone/Z1A2B3C4D5E6F7",
"HostedZone": {
"Id": "/hostedzone/Z1A2B3C4D5E6F7",
"Name": "app.example.com.",
"CallerReference": "app-example-com-delegation-1678886400",
"Config": {
"Comment": "",
"PrivateZone": false
},
"ResourceRecordSetCount": 2
},
"ChangeInfo": {
"Id": "/change/C1234567890ABCDEF01234567890ABCDEF",
"Status": "PENDING",
"SubmittedAt": "2023-03-15T10:00:00.123Z",
"Comment": "Create public hosted zone for app.example.com"
},
"NameServers": [
{
"Value": "ns-1111.awsdns-11.org"
},
{
"Value": "ns-2222.awsdns-22.net"
},
{
"Value": "ns-3333.awsdns-33.co.uk"
},
{
"Value": "ns-4444.awsdns-44.com"
}
]
}
The NameServers array contains the four DNS servers that Route 53 has assigned to this new hosted zone. These are the authoritative servers for app.example.com.
Next, you need to tell the parent zone (example.com) that app.example.com is now managed elsewhere. You do this by creating NS (Name Server) records in the parent zone that point to the name servers of the child zone.
In your example.com hosted zone (let’s assume its ID is Z0123456789ABCDEF0), you’ll create a record set.
aws route53 change-resource-record-sets --hosted-zone-id Z0123456789ABCDEF0 --change-batch '{
"Comment": "Delegate app.example.com to its own hosted zone",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "app.example.com",
"Type": "NS",
"TTL": 172800,
"ResourceRecords": [
{"Value": "ns-1111.awsdns-11.org"},
{"Value": "ns-2222.awsdns-22.net"},
{"Value": "ns-3333.awsdns-33.co.uk"},
{"Value": "ns-4444.awsdns-44.com"}
]
}
}
]
}'
The UPSERT action means "create if it doesn’t exist, update if it does." The Name is the subdomain you’re delegating (app.example.com), the Type is NS, and TTL is set to a common value for delegation records (2 days). The ResourceRecords are the exact Name Servers obtained from the child zone’s creation.
Once this change is applied, any DNS query for app.example.com that hits the example.com authoritative servers will be directed to the Name Servers listed in this NS record. Those Name Servers are the ones for the app.example.com hosted zone, which will then be able to resolve records like www.app.example.com or api.app.example.com.
The crucial point is that the example.com zone only knows about the NS records for app.example.com. It does not contain A, CNAME, or any other records for app.example.com itself. Those live exclusively in the app.example.com hosted zone. This separation of concerns is what makes delegation powerful.
The most surprising thing about this process is that you don’t actually "point" the subdomain to an IP address from the parent zone. Instead, you are creating a set of pointers (the NS records) that tell DNS resolvers where to go to find the actual authoritative servers for that subdomain. It’s like leaving a forwarding address at the post office for a specific street name within a larger neighborhood.
After you’ve set up the NS records in the parent zone, you can then go into the app.example.com hosted zone and add records like:
aws route53 change-resource-record-sets --hosted-zone-id Z1A2B3C4D5E6F7 --change-batch '{
"Comment": "Add A record for www.app.example.com",
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.app.example.com",
"Type": "A",
"TTL": 300,
"ResourceRecords": [
{"Value": "192.0.2.1"}
]
}
}
]
}'
This creates an A record for www.app.example.com within its dedicated zone.
The final piece of the puzzle is ensuring that the Name Servers you’ve delegated to are actually registered with domain registrars if you’re using Route 53 for domain registration. If you registered example.com with Route 53, it automatically handles associating the NS records for app.example.com with the parent domain’s delegation. If example.com is registered elsewhere, you’d need to manually configure the NS records at that external registrar for app.example.com.
The next thing you’ll likely encounter is needing to manage alias records, especially for AWS resources like ELBs or CloudFront distributions within your newly delegated subdomain.