Introducing Amazon Route 53 authoritative DNS service for public hosted zones in AWS GovCloud (US) Regions

We are excited to announce the general availability of Amazon Route 53 authoritative Domain Name System (DNS) service for public hosted zones in AWS GovCloud (US). You can now create and manage public hosted zones in AWS GovCloud (US) to manage DNS for internet-facing applications and create alias records with targets to AWS services such as Amazon API Gateway, Amazon Simple Storage Service (Amazon S3), Amazon VPC interface endpoints, AWS Elastic Beanstalk, and Amazon Elastic Load Balancing in the AWS GovCloud (US) Regions. This feature streamlines operational complexities and addresses compliance challenges, thereby empowering customers to meet regulatory requirements while delivering seamless experiences in the same AWS GovCloud (US) Management console.

U.S. Government agencies and customers may need to meet compliance and regulatory requirements when processing sensitive data and Controlled Unclassified Information (CUI) in AWS GovCloud (US). To satisfy these requirements, customers use Route 53, which provides robust and secure Domain Name System (DNS) infrastructure to manage internet-facing DNS for your mission-critical applications. Prior to this, to manage public DNS for your applications in AWS GovCloud (US) using Route 53, you had to use authoritative DNS for public hosted zones in the AWS commercial partition. This required maintaining separate AWS commercial and AWS GovCloud (US) accounts. By default, AWS Identity and Access Management (IAM) credentials from one partition can’t be used to access resources in another partition. Therefore, you needed to create and manage separate sets of IAM credentials (users, roles, access keys, etc.) for each partition. This required switching between separate consoles to manage Route 53 configurations and resources in each partition, which could be cumbersome and prone to errors. This also increased operational work needed to manage DNS across two different partitions posing challenges, potentially slowing down development velocity and creating bottlenecks in managing DNS changes.

In this post, we will discuss migration of Route 53 public hosted zones from AWS commercial to AWS GovCloud (US) partition. We also discuss best practices and considerations for migrating public hosted zones and health checks to AWS GovCloud (US) partition.

Prerequisites

We assume that you are familiar with Amazon Route 53 public hosted zones, DNS record types, routing policies, health checks, Domain Name System Security Extensions (DNSSEC) signing, and DNSSEC for domain registration. We also assume that you are familiar with services such as Amazon Virtual Private Cloud (Amazon VPC), Application Load Balancer (ALB), and Network Load Balancer (NLB).

Baseline scenario

In many organizations, DNS management is split between central networking teams and application teams to balance governance and flexibility. If you have each application team manage their own child public hosted zones, for example service1.example.com, service2.example.com while the parent public hosted zone example.com is managed by a central team, then migrating hosted zones from commercial to AWS GovCloud (US) involves further coordination to make sure of proper DNS delegation, minimal downtime, and accurate DNS resolution. You can read more about the best practices in the post, DNS best practices for Amazon Route 53. We recommend migrating child zones first before migrating the parent zone to Route 53 public hosted zones in AWS GovCloud (US) to ensure a smoother transition. Before we dive into the migration steps, the following section explores the preparation phase.

Preparation Phase

The migration of public hosted zones from commercial to AWS GovCloud (US) accounts necessitates careful preparation. This preparation phase creates a blueprint for migrating both child and parent zones. Following these steps allows you to establish a repeatable migration process for your entire DNS infrastructure. You can use existing health checks configured in the commercial partition for AWS GovCloud (US). If you aren’t planning to use the same health checks, then you must recreate your existing health checks in the AWS GovCloud (US) partition. For detailed preparation steps common to both child and parent hosted zones, refer to the AWS documentation in Route 53 migration.

Before attempting any DNS migration, first validate the process using a test domain. DNS changes can potentially impact application availability, so testing with non-production domains helps make sure of a smooth transition for your production workloads.

Migrating to Route 53 public hosted zones in AWS GovCloud (US) from commercial partition

In this section, we walk through migrating an example.com parent zone registered through Route 53 Domains and a service.example.com child zone within the commercial account. The parent public hosted zone example.com also contains NS records to delegate subdomains for child zones. Each parent and child zone are DNSSEC enabled to ensure data origin authentication and data integrity verification for DNS.

In our example, the child zone service.example.com in the commercial account contains three records:

1. A record pointing to a web server.
2. Primary CNAME record pointing to an ALB in AWS GovCloud West, configured with failover routing policy. The primary record is associated with a health check created in the commercial account.
3. Secondary CNAME record pointing to an ALB in AWS GovCloud East.

Figure 1 shows a list of records in the service.example.com child public hosted zone.

Figure 1: Records in the service.example.com public hosted zone in commercial account

The parent zone example.com in the commercial account contains five records:

1. NS record pointing to the service.example.com child zone for subdomain delegation.
2. DS record for the service.example.com zone.
3. Alias A record pointing to the NLB.
4. Alias AAAA record pointing to a NLB.
5. SOA record identifying the base DNS information about the domain.

Figure 2 shows a list of records in the example.com parent public hosted zone.

Figure 2: Records in the example.com parent public hosted zone in commercial account

There are two migration strategies depending upon the infrequent or frequent record changes in your existing public hosted zones. In this post, we focus on public hosted zones with infrequent record changes. This migration is voluntary, and you can continue to use Route 53 public hosted zones in the commercial partition for resources in AWS GovCloud (US) partition. For frequent record changes, we recommend pausing record changes during migration and modifying your application to publish record changes in both old and new hosted zones until the delegation is transferred. If you need additional guidance for migrating hosted zones with frequent record changes, then contact AWS Support for specific migration assistance. When migrating a public hosted zone from a commercial account to an AWS GovCloud (US) account with infrequent record changes, follow these recommended steps.

Migration walkthrough for child public hosted zone service.example.com

The following six steps walk you through the migration for child public hosted zone service.example.com.

Step 1: Disable DNSSEC for child public hosted zone service.example.com in the commercial account

When migrating DNSSEC enabled domains such as example.com and service.example.com, the order in which you perform the steps is crucial to avoid breaking the chain of trust. The Delegation Signer (DS) record at the domain registration for the parent zone ensures that DNSSEC validation works correctly across child zones.

Disabling DNSSEC signing for service.example.com in the commercial AWS partition involves two actions:

1. Delete the DS record for child zone service.example.com from the parent zone example.com in the commercial account. This step prevents DNSSEC validation failures when the child zone migrates to the AWS GovCloud (US) account. You must contact the parent zone owner to remove the DS record.

You must allow time for DNS resolvers to update their caches. This waiting period typically spans two days, during which the Time-to-Live (TTL) of the deleted record expires. You can determine the TTL for the records using the dig command, as demonstrated in examples in this documentation. Attempting to proceed before the full TTL expiration risks service.example.com that is unavailable on the internet.

2. When the TTL expires, disable the DNSSEC signing for service.example.com child zone by navigating to the AWS Management Console in the commercial partition (see Figure 3).

If you disable DNSSEC signing before you turn off DNSSEC by deleting the DS record, then your domain might become unavailable on the internet.

Figure 3: Disable DNSSEC signing for the service.example.com child zone

Step 2: Create a public hosted zone for a child zone in the AWS GovCloud (US) account

In this step, you create a new public hosted zone for child zone service.example.com within the AWS GovCloud (US) account (see Figure 4). After you create a hosted zone, note the four name servers that Route 53 associated with your hosted zone. Update the domain registration for the domain to use these four name servers at a later step.

Figure 4: Create a public hosted zone in the AWS GovCloud (US) account

At this point, start monitoring your newly created child public hosted zone to log information about the public DNS queries by configuring Public DNS query. To get Amazon CloudWatch metrics on the console, you must choose AWS GovCloud (US-West) for the Region.

Step 3: Migrate health checks

Route 53 health check service exists in both the commercial and AWS GovCloud (US) partitions. Both health check partitions can make health checks against publicly exposed endpoints in AWS GovCloud (US). You can use either partition to create your health checks, but this necessitates careful planning to determine which AWS services with which you want the health checks to integrate. Route 53 supports all three types of health checks in the AWS GovCloud (US) partition. When you configure health checks to monitor an endpoint in AWS GovCloud (US), Route 53 health checkers uses both AWS GovCloud West and East Regions by default to send health check requests to the endpoint. You can’t choose the health checker Regions in AWS GovCloud (US) partitions to monitor your endpoint. To migrate health checks from the commercial to the AWS GovCloud (US) account, you can follow these steps:

1. Create new Health Checks in the AWS GovCloud (US) partition
2. Confirm the endpoints are reachable from AWS GovCloud (US) checker IPs, because they are different for the AWS GovCloud (US) partition
3. Validate that the health checks are behaving as desired
4. Associate the health check with records

In our example, you create a health check for the ALB endpoint. Associate this health check with records in the next step.

Step 4: Create records in the new child zone in the AWS GovCloud (US) account

With the new AWS GovCloud (US) hosted zone created for your child zone, you can create DNS records for the service.example.com zone in the AWS GovCloud (US) account from the commercial account by using the Console or the AWS CLI. Alternatively, you can also use AWS CloudFormation or AWS Cloud Development Kit (AWS CDK) to create these records. If you previously exported records programmatically during preparation phase, then use import instructions to streamline the transfer. In our example, you manually create an A record and two CNAME records in the service.example.com zone. It is essential to create all these records with a low TTL value between 60 seconds and 900 seconds, as this enables quick rollback if any issues are discovered during the migration process. Then, you associate the health check ID (the health check ID is different in the AWS GovCloud (US) account) from Step 3 for the primary record. Figure 5 shows the list of records in this newly created child zone in the AWS GovCloud (US) account.

Figure 5: Records in the service.example.com child public hosted zone in the AWS GovCloud (US) account

To confirm that you successfully created all of your records in the new hosted zone, we recommend that you list the records in the new hosted zone and compare the output with the list of records from the old hosted zone. You can use the procedure in this documentation to list and compare the records from the hosted zone.

Step 5: Update the parent zone example.com to use nameservers for the new child zone

To route internet traffic for service.example.com, update the NS record in the example.com parent zone, giving it the name of the subdomain service.example.com for delegation. For the NS record value, specify the names of the name servers from the child zone for service.example.com from Step 2. Figure 6 shows the updated NS record for child zone in the parent zone with child zone nameservers.

Figure 6: Update NS record for child zone in the parent zone with child zone nameservers for subdomain delegation

You can use CloudWatch to monitor the DNS resolution service.example.com zone through new AWS GovCloud (US) nameservers using CloudWatch metrics and query logging to track performance metrics, identify potential issues, and verify stable DNS operations across all services. You can track the traffic shift in real-time by verifying that queries are answered correctly by the new infrastructure and making sure of proper resolution across all record types. Observe DNS query metrics begin publishing on the new hosted zone for service.example.com in the AWS GovCloud (US) account while metrics on the old hosted zone in the commercial account gradually decrease. Additionally, you can review the query logging to confirm that you aren’t observing any SERVFAIL or other errors for the child zone in the AWS GovCloud (US) account.

Rollback

If you detect any DNS resolution or application connectivity issues, then maintain the ability to quickly revert to the original name servers for service.example.com from the commercial account. Keep the previous public hosted zone in the commercial account active until you’ve confirmed stable operation through the new AWS GovCloud (US) infrastructure.

Step 6: Post-migration tasks

After confirming that your child zone service.example.com has migrated and traffic is flowing normally, do the following:

1. Change the TTL values for the NS record toa more typical value, for example 172800 seconds (two days) as before for your DNS records in the child zone in the AWS GovCloud (US) account.
2. After confirming extended DNS stability and when you’re confident that you no longer need the old hosted zone, you can optionally delete it from the commercial account. For instructions, see Deleting a public hosted zone.

You can delete the health checks for records in the child zone if you aren’t using the health checks in the commercial account.

Migration walkthrough for the parent zone example.com in the commercial account

Migrating example.com is a critical operation that affects all of its child domains. Before we begin, we must ensure all child zones such as service.example.com are operational in the AWS GovCloud (US) account. Follow the preparation steps before proceeding with example.com migration.

Step 1: Disable DNSSEC for the parent zone in the commercial account

When you disable DNSSEC for the example.com in the commercial account, you must follow two steps:

1. Delete the public keys before you disable DNSSEC for example.com public hosted zone (see Figure 7). We recommend that you wait for up to two days before you disable DNSSEC parent domain. This is important because if DNSSEC is enabled for the example.com domain and you disable DNSSEC with the Route 53 domain registrar, then DNS resolvers that support DNSSEC return a SERVFAIL error to clients, and the clients won’t be able to access the endpoints that are associated with example.com.

When Route 53 receives a response from the registry, we send an email to the registrant contact for the domain. The email either confirms that the public key has been deleted from the domain at the registry, or it explains why the key couldn’t be deleted.

If you use a third-party domain registrar instead of Route 53 for your parent domain, then delete the DS record based on the documentation provided by your registrar.

Figure 7: Disable DNSSEC signing for example.com

2. After waiting for two days, continue to Disable DNSSEC signing and deactivate the key-signing key (KSK) by editing the KSK and changing its status to Inactive (see Figure 8). You can determine the TTL for the records using the dig command, as demonstrated in the examples in this documentation.

Figure 8: Change KSK status to inactive

Step 2: Create a public hosted zone for parent zone in the AWS GovCloud (US) account

Follow the same migration in Step 2: Create a public hosted zone for a child zone in the AWS GovCloud (US) account as outlined for the child zone, but for the example.com hosted zone in the commercial account.

Step 3: Create records in the new parent zone in the AWS GovCloud (US) account

Follow the same Step 4: Create records in the new child zone in the AWS GovCloud (US) account as outlined for the child zone, but for the example.com hosted zone in the commercial account. In our example, you create an Alias A and Alias AAAA records pointing to the NLB target in the AWS GovCloud (US) Regions, but you can’t choose alias targets in the commercial Regions. Figure 9 shows the list of records in the newly created example.com public hosted zone in the AWS GovCloud (US) account.

Figure 9: Records in example.com parent public hosted zone in the AWS GovCloud (US) account

Step 4: Update the AWS GovCloud (US) nameservers in your Route 53 registrar

Next, we update the AWS GovCloud (US) nameservers in your domain registrar, which in our example is Route 53. If your domain is registered with another provider, then access their domain management interface. In our example, navigate to Registered domains under Route 53 in the commercial account and choose example.com. Navigate to the name servers section and replace the current NS records with the new four AWS GovCloud (US) name servers for your parent public hosted zone from Step 2 of the parent zone migration walkthrough section.

If you detect any DNS resolution or application connectivity issues, then maintain the ability to quickly revert to the original name servers for example.com from the commercial account. Keep the previous public hosted zone in the commercial account active until you’ve confirmed stable operation through the new AWS GovCloud (US) infrastructure.

Step 5: Re-enable DNSSEC signing and establish the chain of trust

After migrating the parent zone example.com to the AWS GovCloud (US) account from your commercial account, you can re-enable DNSSEC signing.

1. Enable DNSSEC signing for example.com in the AWS GovCloud (US) hosted zone by creating a new KSK and updating the public key in Route 53 domains.
2. When the parent domain is configured, configure DNSSEC for service.example.com by enabling DNSSEC signing and establishing the parent-child trust chain to make sure complete domain hierarchy security.

We recommend that you follow the same process used during your initial DNSSEC implementation. For detailed step-by-step instructions, refer to the posts Amazon Route 53 DNSSEC documentation and Configuring DNSSEC signing and validation with Amazon Route 53.

Step 6: Testing and verification

Finally, this phase makes sure of the successful migration of example.com and its child domains to AWS GovCloud (US) to maintain the continuity and security of the service:

1. Perform DNS resolution tests for example.com and service.example.com using various DNS resolvers and from different geographic locations. This verifies global accessibility and correct delegation.
2. When the new public parent zones in AWS GovCloud (US) are fully operational, you can delete the parent zone in the commercial account. You can also delete the health checks configuration if you have migrated to the AWS GovCloud (US) account.

Figure 10: CloudWatch dashboard showing DNS performance metrics for parent and child zones

Considerations

When working with Route 53 in AWS GovCloud (US) Regions, there are important differences compared to AWS commercial Regions that you should be aware of:

1. Review the Route 53 Service Level Agreement (SLA) for AWS GovCloud (US) to ensure that the anticipated monthly uptime percentage for a hosted zone aligns with your organization’s requirements.
2. IP-based routing is not supported.
3. Traffic Flow features are not available.
4. The customer managed key that you use with DNSSEC signing must be in AWS GovCloud (US-West).
5. The CloudWatch Logs log group for query logging must be in AWS GovCloud (US-West).
6. Currently, we support alias targets for API Gateway, Elastic Beanstalk, Application Load Balancer, Classic Load Balancer, Network Load Balancer, Amazon S3 website endpoint, and VPC endpoint. The other alias targets are not supported.

Conclusion

In this post, we walked you through the migration steps for your Amazon Route 53 public hosted zones from the commercial to the AWS GovCloud (US) account. This launch of the Route 53 authoritative DNS for public hosted zones in the AWS GovCloud (US) Regions equips our government and regulated industry customers to serve DNS queries to your public hosted zones from locations within the AWS GovCloud (US) Regions. This feature streamlines operational complexities and addresses compliance challenges, thereby empowering customers to meet regulatory requirements while delivering seamless experiences in the same AWS GovCloud (US) console. To get started today, learn more about migrating your Route 53 public hosted zones to AWS GovCloud (US) from commercial partition.

About the authors