# Working with public hosted zones A public hosted zone is a container that holds information about how you want to route traffic on the internet for a specific domain, such as example.com, and its subdomains (acme.example.com, zenith.example.com). You get a public hosted zone in one of two ways: + When you register a domain with Route 53, we create a hosted zone for you automatically. + When you transfer DNS service for an existing domain to Route 53, you start by creating a hosted zone for the domain. For more information, see [Making Amazon Route 53 the DNS service for an existing domainMaking Route 53 the DNS service for an existing domain](MigratingDNS.md). In both cases, you then create records in the hosted zone to specify how you want to route traffic for the domain and subdomains. For example, you might create a record to route traffic for www.example.com to a CloudFront distribution or to a web server in your data center. For more information about records, see [Working with records](rrsets-working-with.md). This topic explains how to use the Amazon Route 53 console to create, list, and delete public hosted zones. **Note** You can also use a Route 53 *private* hosted zone to route traffic within one or more VPCs that you create with the Amazon VPC service. For more information, see [Working with private hosted zones](hosted-zones-private.md). **Topics** + [ # Considerations when working with public hosted zones ](hosted-zone-public-considerations.md) + [ # Creating a public hosted zone ](CreatingHostedZone.md) + [ # Getting the name servers for a public hosted zone ](GetInfoAboutHostedZone.md) + [ # Listing public hosted zones ](ListInfoOnHostedZone.md) + [ # Viewing DNS query metrics for a public hosted zone ](hosted-zone-public-viewing-query-metrics.md) + [ # Deleting a public hosted zone ](DeleteHostedZone.md) + [ # Checking DNS responses from Route 53 ](dns-test.md) + [ # Configuring white-label name servers ](white-label-name-servers.md) + [ # NS and SOA records that Amazon Route 53 creates for a public hosted zone ](SOA-NSrecords.md) + [ # Enabling accelerated recovery for managing public DNS records ](accelerated-recovery.md) # Considerations when working with public hosted zones Note the following considerations when working with public hosted zones: **NS and SOA records** When you create a hosted zone, Amazon Route 53 automatically creates a name server (NS) record and a start of authority (SOA) record for the zone. The NS record identifies the four name servers that you give to your registrar or your DNS service so that DNS queries are routed to Route 53 name servers. For more information about NS and SOA records, see [NS and SOA records that Amazon Route 53 creates for a public hosted zone](SOA-NSrecords.md). **Multiple hosted zones that have the same name** You can create more than one hosted zone that has the same name and add different records to each hosted zone. Route 53 assigns four name servers to every hosted zone, and the name servers are different for each of them. When you update your registrar's name server records, be careful to use the Route 53 name servers for the correct hosted zone—the one that contains the records that you want Route 53 to use when responding to queries for your domain. Route 53 never returns values for records in other hosted zones that have the same name. **Reusable delegation sets** By default, Route 53 assigns a unique set of four name servers (known collectively as a delegation set) to each hosted zone that you create. If you want to create a large number of hosted zones, you can create a reusable delegation set programmatically. (Reusable delegation sets aren't available in the Route 53 console.) Then you can create hosted zones programmatically and assign the same reusable delegation set—the same four name servers—to each hosted zone. Reusable delegation sets simplify migrating DNS service to Route 53 because you can instruct your domain name registrar to use the same four name servers for all of the domains for which you want to use Route 53 as the DNS service. For more information, see [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html) in the *Amazon Route 53 API Reference*. # Creating a public hosted zone A public hosted zone is a container that holds information about how you want to route traffic on the internet for a specific domain, such as example.com, and its subdomains (acme.example.com, zenith.example.com). After you create a hosted zone, you create records that specify how you want to route traffic for the domain and subdomains. **Restrictions** Note the following restrictions for creating hosted zones with Route 53. You can create a hosted zone only for a domain that you have permission to administer. Typically, this means that you own the domain, but you might also be developing an application for the domain registrant. You can create hosted zones for domains and subdomains only. Route 53 doesn't support hosting top-level domains (TLD) such as `.com`. **To create a public hosted zone using the Route 53 console** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. If you're new to Route 53, choose **Get started** under **DNS management**. If you're already using Route 53, choose **Hosted zones** in the navigation pane. 1. Choose **Create hosted zone**. 1. In the **Create Hosted Zone** pane, enter the name of the domain that you want to route traffic for. You can also optionally enter a comment. For information about how to specify characters other than a-z, 0-9, and - (hyphen) and how to specify internationalized domain names, see [DNS domain name format](DomainNameFormat.md). 1. For **Type**, accept the default value of **Public Hosted Zone**. 1. Choose **Create**. 1. Create records that specify how you want to route traffic for the domain and subdomains. For more information, see [Working with records](rrsets-working-with.md). 1. To use records in the new hosted zone to route traffic for your domain, see the applicable topic: + If you're making Route 53 the DNS service for a domain that is registered with another domain registrar, see [Making Amazon Route 53 the DNS service for an existing domainMaking Route 53 the DNS service for an existing domain](MigratingDNS.md). + If the domain is registered with Route 53, see [Adding or changing name servers and glue records for a domain](domain-name-servers-glue-records.md). # Getting the name servers for a public hosted zone You get the name servers for a public hosted zone if you want to change the DNS service for your domain registration. For information about how to change your DNS service, see [Making Amazon Route 53 the DNS service for an existing domainMaking Route 53 the DNS service for an existing domain](MigratingDNS.md). **Note** Some registrars only allow you to specify name servers using IP addresses; they don't allow you to specify fully qualified domain names. If your registrar requires using IP addresses, you can get the IP addresses for your name servers using the dig utility (for Mac, Unix, or Linux) or the nslookup utility (for Windows). We rarely change the IP addresses of name servers; if we need to change IP addresses, we'll notify you in advance. **To get the name servers for a hosted zone using the Route 53 console** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, click **Hosted zones**. 1. On the **Hosted zones** page, choose the radio button (not the name) for the hosted zone, then choose **View details**. 1. On the details page for the hosted zone, choose **Hosted zone details**. 1. Make note of the four servers listed for **Name servers**. # Listing public hosted zones You can use the Amazon Route 53 console to list all of the hosted zones that you created with the current AWS account. For information about how to list hosted zones using the Route 53 API, see [ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html) in the *Amazon Route 53 API Reference*. **To list the public hosted zones associated with an AWS account using the Route 53 console** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **Hosted zones**. The page displays a list of the hosted zones that are associated with the AWS account that you are currently signed in with. 1. To filter hosted zones, use the search bar located at the top of the table. Search behavior depends on whether the hosted zone contains up to 2,000 records or more than 2,000 records: **Up to 2,000 hosted zones** + To display the records that have specific values, click the search bar, choose a property in the dropdown list, and enter a value. You can also enter a value directly in the search bar and press Enter. For example, to display the hosted zones that have a name beginning with **abc**, enter that value in the search bar and press Enter. + To display only the hosted zones that have the same hosted zone type, select the type in the dropdown list, and enter the type. **More than 2,000 hosted zones** + You can search for properties based on exact domain name, all properties, and type. + Search using the exact domain name for faster search results. # Viewing DNS query metrics for a public hosted zone You can view the total number of DNS queries that Route 53 is responding to for a specified public hosted zone or combination of public hosted zones. The metrics appear in CloudWatch, which lets you view a graph, choose the time period that you want to view, and customize the metrics in a variety of other ways. You can also create alarms and configure notifications, so that you're notified when the number of DNS queries in a specified time period go above or below a specified level. **Note** Route 53 automatically sends the number of DNS queries to CloudWatch for all public hosted zones, so you don't need to configure anything before you can view query metrics. There's no charge for DNS query metrics. **Which DNS queries are counted?** Metrics include only the queries that DNS resolvers forward to Route 53. If a DNS resolver has already cached the response to a query (such as the IP address for a load balancer for example.com), the resolver will continue to return the cached response without forwarding the query to Route 53 until the TTL for the corresponding record expires. Depending on how many DNS queries are submitted for a domain name (example.com) or subdomain name (www.example.com), which resolvers your users are using, and the TTL for the record, DNS query metrics might contain information about only one query out of every several thousand queries that are submitted to DNS resolvers. For more information about how DNS works, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic). **When do query metrics for a hosted zone start to appear in CloudWatch?** After you create a hosted zone, there's a delay of up to several hours before the hosted zone can appear in CloudWatch. In addition, you must submit a DNS query for a record in the hosted zone so there's data to display. **Metrics are available only in US East (N. Virginia)** To get metrics on the console, you must choose US East (N. Virginia) for the Region. To get metrics using the AWS CLI, you must either leave the AWS Region unspecified, or specify `us-east-1` as the Region. Route 53 metrics aren't available if you choose any other Region. **CloudWatch metric and dimension for DNS queries** For information about the CloudWatch metric and dimension for DNS queries, see [Monitoring hosted zones using Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). For information about CloudWatch metrics, see [Using Amazon CloudWatch metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) in the *Amazon CloudWatch User Guide*. **Getting more detailed data about DNS queries** To get more detailed information about each DNS query that Route 53 responds to, including the following values, you can configure query logging: + Domain or subdomain that was requested + Date and time of the request + DNS record type (such as A or AAAA) + Route 53 edge location that responded to the DNS query + DNS response code, such as `NoError` or `ServFail` For more information, see [Public DNS query logging](query-logs.md). **How to get DNS query metrics** Shortly after you create a hosted zone, Amazon Route 53 starts to send metrics and dimensions once a minute to CloudWatch. You can use the following procedures to view the metrics on the CloudWatch console or view them by using the AWS Command Line Interface (AWS CLI). **Topics** + [ ## Viewing DNS query metrics for a public hosted zone in the CloudWatch console ](#hosted-zone-public-viewing-query-metrics-console) + [ ## Getting DNS query metrics using the AWS CLI ](#hosted-zone-public-viewing-query-metrics-cli) ## Viewing DNS query metrics for a public hosted zone in the CloudWatch console To view DNS query metrics for public hosted zones in the CloudWatch console, perform the following procedure. **To view DNS query metrics for a public hosted zone on the CloudWatch console** 1. Sign in to the AWS Management Console and open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. In the navigation pane, choose **Metrics**. 1. On the AWS Region list in the upper right corner of the console, choose **US East (N. Virginia)**. Route 53 metrics aren't available if you choose any other AWS Region. 1. On the **All metrics** tab, choose **Route 53**. 1. Choose **Hosted Zone Metrics**. 1. Select the check box for one or more hosted zones that have the metric name **DNSQueries**. 1. On the **Graphed metrics** tab, change the applicable values to view the metrics in the format that you want. For **Statistic**, choose **Sum** or **SampleCount**; these statistics both display the same value. ## Getting DNS query metrics using the AWS CLI To get DNS query metrics using the AWS CLI, you use the [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html) command. Note the following: + You specify most values for the command in a separate JSON file. For more information, see [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html). + The command returns one value for each interval that you specify for `Period` in the JSON file. `Period` is in seconds, so if you specify a five-minute time period and specify `60` for `Period`, you get five values. If you specify a five-minute time period and specify `300` for `Period`, you get one value. + In the JSON file, you can specify any value for `Id`. + Either leave the AWS Region unspecified, or specify `us-east-1` as the Region. Route 53 metrics aren't available if you choose any other Region. For more information, see [Configuring the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) in the *AWS Command Line Interface User Guide*. Here's the AWS CLI command that you use to get DNS query metrics for the five-minute time period between 4:01 and 4:07 on May 1, 2019. The `metric-data-queries` parameter references the sample JSON file that follows the command. ``` aws cloudwatch get-metric-data --metric-data-queries file://./metric.json --start-time 2019-05-01T04:01:00Z --end-time 2019-05-01T04:07:00Z ``` Here's the sample JSON file: ``` [ { "Id": "my_dns_queries_id", "MetricStat": { "Metric": { "Namespace": "AWS/Route53", "MetricName": "DNSQueries", "Dimensions": [ { "Name": "HostedZoneId", "Value": "Z1D633PJN98FT9" } ] }, "Period": 60, "Stat": "Sum" }, "ReturnData": true } ] ``` Here's the output from this command. Note the following: + The start time and end time in the command cover a seven-minute time period, `2019-05-01T04:01:00Z` to `2019-05-01T04:07:00Z`. + There are only six return values. There's no value for `2019-05-01T04:05:00Z` because there were no DNS queries during that minute. + The value of `Period` specified in the JSON file is `60` (seconds), so the values are reported in one-minute intervals. ``` { "MetricDataResults": [ { "Id": "my_dns_queries_id", "StatusCode": "Complete", "Label": "DNSQueries", "Values": [ 101.0, 115.0, 103.0, 127.0, 111.0, 120.0 ], "Timestamps": [ "2019-05-01T04:07:00Z", "2019-05-01T04:06:00Z", "2019-05-01T04:04:00Z", "2019-05-01T04:03:00Z", "2019-05-01T04:02:00Z", "2019-05-01T04:01:00Z" ] } ] } ``` # Deleting a public hosted zone This section explains how to delete a public hosted zone using the Amazon Route 53 console. You can delete a hosted zone only if there are no records other than the default SOA and NS records. If your hosted zone contains other records, you must delete them before you can delete your hosted zone. This prevents you from accidentally deleting a hosted zone that still contains records. **Topics** + [ ## Preventing traffic from being routed to your domain ](#delete-public-hosted-zone-stop-routing) + [ ## Deleting public hosted zones that were created by another service ](#delete-public-hosted-zone-created-by-another-service) + [ ## Using the Route 53 console to delete a public hosted zone ](#delete-public-hosted-zone-procedure) ## Preventing traffic from being routed to your domain If you want to keep your domain registration but you want to stop routing internet traffic to your website or web application, we recommend that you delete *records* in the hosted zone instead of deleting the hosted zone. **Important** If you delete a hosted zone, you can't undelete it. You must create a new hosted zone and update the name servers for your domain registration, which can require up to 48 hours to take effect. In addition, if you delete a hosted zone, someone could hijack the domain and route traffic to their own resources using your domain name. If you delegated responsibility for a subdomain to a hosted zone and you want to delete the child hosted zone, you must also update the parent hosted zone by deleting the NS record that has the same name as the child hosted zone. For example, if you want to delete the hosted zone acme.example.com, you must also delete the NS record acme.example.com in the example.com hosted zone. We recommend that you delete the NS record first, and wait for the duration of the TTL on the NS record before you delete the child hosted zone. This ensures that someone can't hijack the child hosted zone during the period that DNS resolvers still have the name servers for the child hosted zone cached. If you want to avoid the monthly charge for the hosted zone, you can transfer DNS service for the domain to a free DNS service. When you transfer DNS service, you have to update the name servers for the domain registration. If the domain is registered with Route 53, see [Adding or changing name servers and glue records for a domain](domain-name-servers-glue-records.md) for information about how to replace Route 53 name servers with name servers for the new DNS service. If the domain is registered with another registrar, use the method provided by the registrar to update name servers for the domain registration. For more information, perform an internet search on "free DNS service." ## Deleting public hosted zones that were created by another service If a hosted zone was created by another service, you can't delete it using the Route 53 console. Instead, you need to use the applicable process for the other service: + **AWS Cloud Map** – To delete a hosted zone that AWS Cloud Map created when you created a public DNS namespace, delete the namespace. AWS Cloud Map deletes the hosted zone automatically. For more information, see [Deleting namespaces](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) in the *AWS Cloud Map Developer Guide*. + **Amazon Elastic Container Service (Amazon ECS) Service Discovery** – To delete a public hosted zone that Amazon ECS created when you created a service using service discovery, delete the Amazon ECS services that are using the namespace, and delete the namespace. For more information, see [Deleting a service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html) in the *Amazon Elastic Container Service Developer Guide*. ## Using the Route 53 console to delete a public hosted zone To use the Route 53 console to delete a public hosted zone, perform the following procedure. **To delete a public hosted zone using the Route 53 console** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **Hosted zones**, and choose the highlighted link for the hosted zone you want to delete. 1. Confirm that the hosted zone that you want to delete contains only an NS and an SOA record. If it contains additional records, delete them. You will also need to disable DNSSEC signing: **Note** If you attempt to delete the hosted zone without completing these requirements, Route 53 will return an error: If DNSSEC signing is enabled: The specified hosted zone contains DNSSEC Key Signing Keys and so cannot be deleted If other resource record sets exist (other than the default SOA and NS records): The specified hosted zone contains non-required resource record sets and so cannot be deleted 1. On the hosted zone detail page, in the **Records** list, if the list of records includes any records for which the value of the **Type** column is something other than NS or SOA, choose the row, and choose **Delete**. To select multiple, consecutive records, choose the first row, press and hold the **Shift** key, and choose the last row. To select multiple, non-consecutive records, choose the first row, press and hold the **Ctrl** key, and choose the remaining rows. **Note** If you created any NS records for subdomains in the hosted zone, delete those records, too. 1. Go back to the the **Hosted zones** page, and choose the row for the hosted zone that you want to delete. 1. Choose **Delete**. 1. Type the confirmation key and choose **Delete**. 1. If you want to make the domain unavailable on the internet, we recommend that you transfer DNS service to a free DNS service and then delete the Route 53 hosted zone. This prevents future DNS queries from possibly being misrouted. If the domain is registered with Route 53, see [Adding or changing name servers and glue records for a domain](domain-name-servers-glue-records.md) for information about how to replace Route 53 name servers with name servers for the new DNS service. If the domain is registered with another registrar, use the method provided by the registrar to change name servers for the domain. **Note** If you're deleting a hosted zone for a subdomain (acme.example.com), you don't need to change name servers for the domain (example.com). # Checking DNS responses from Route 53 If you created an Amazon Route 53 hosted zone for your domain, you can use the DNS checking tool in the console to see how Route 53 will respond to DNS queries if you configure your domain to use Route 53 as your DNS service. For geolocation, geoproximity, and latency records, you can also simulate queries from a particular DNS resolver and/or client IP address to find out what response Route 53 would return. **Important** The tool doesn't submit queries to the Domain Name System, it only responds based on the settings in the records in the hosted zone. The tool returns the same information regardless of whether the hosted zone is currently being used to route traffic for the domain. The DNS checking tool works only for public hosted zones. **Note** The DNS checking tool returns information similar to what you would expect from the answer section of the `dig` command. Therefore, if you query for the name servers of a subdomain that point to the parent name servers, those will not be returned. **Topics** + [ ## Using the checking tool to see how Amazon Route 53 responds to DNS queries ](#dns-test-how-route-53-responds) + [ ## Using the checking tool to simulate queries from specific IP addresses (geolocation and latency records only) ](#dns-test-simulate-requests) ## Using the checking tool to see how Amazon Route 53 responds to DNS queries You can use the tool to see what response Amazon Route 53 returns in response to a DNS query for a record. **To use the checking tool to see how Route 53 responds to DNS queries** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **Hosted Zones**. 1. On the **Hosted Zones** page, choose the name of a hosted zone. The console displays the list of records for that hosted zone. 1. To go directly to the **Check response from Route 53** page, choose **Test record**. 1. Specify the following values: + The name of the record, excluding the name of the hosted zone. For example, to check **www.example.com**, enter **www**. To check **example.com**, leave the **Record name** field blank. + The type of the record that you want to check, such as **A** or **CNAME**. 1. Choose **Get Response**. 1. The **Response returned by Route 53** section includes the following values: **DNS response code** A code that indicates whether the query was valid or not. The most common response code is **NOERROR**, meaning that the query was valid. If the response is not valid, Route 53 returns a response code that explains why not. For a list of possible response codes, see [DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) on the IANA website. **Protocol** The protocol that Amazon Route 53 used to respond to the query, either **UDP** or **TCP**. **Response returned by Route 53** The value that Route 53 would return to a web application. The value is one of the following: + For non-alias records, the response contains the value or values in the record. + For multiple records that have the same name and type, which includes weighted, latency, geolocation, and failover, the response contains the value from the appropriate record, based on the request. + For alias records that refer to AWS resources other than another record, the response contains an IP address or a domain name for the AWS resource, depending on the type of resource. + For alias records that refer to other records, the response contains the value or values from the referenced record. ## Using the checking tool to simulate queries from specific IP addresses (geolocation and latency records only) If you have created latency or geolocation records, you can use the checking tool to simulate queries from the IP address for a DNS resolver and a client. **To use the checking tool to simulate queries from specified IP addresses** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **Hosted Zones**. 1. On the **Hosted Zones** page, choose the name of a hosted zone. The console displays the list of records for that hosted zone. 1. To go directly to the **Check response from Route 53** page, choose **Test record set**. To go to the **Check response from Route 53** page for a specific record, choose the check box for that record and choose **Test record set**. 1. If you chose **Test record set** without first choosing a record, specify the following values: + The name of the record, excluding the name of the hosted zone. For example, to check **www.example.com**, enter **www**. To check **example.com**, leave the **Record name** field blank. + The type of the record that you want to check, such as **A** or **CNAME**. 1. Specify the applicable values: **Resolver IP address** Specify an IPv4 or IPv6 address to simulate the location of the DNS resolver that a client uses to make requests. This is useful for testing latency and geolocation records. If you omit this value, the tool uses the IP address of a DNS resolver in the AWS US East (N. Virginia) Region (us-east-1). **EDNS0 client subnet IP** If the resolver supports EDNS0, enter the client subnet IP for an IP address in the applicable geographic location, for example, **192.0.2.0** or **2001:db8:85a3::8a2e:370:7334**. **Subnet mask** If you specify an IP address for **EDNS0 client subnet IP**, you can optionally specify the number of bits of the IP address that you want the checking tool to include in the DNS query. For example, if you specify **192.0.2.44** for **EDNS0 client subnet IP** and **24** for **Subnet mask**, the checking tool will simulate a query from **192.0.2.0/24**. The default value is 24 bits for IPv4 addresses and 64 bits for IPv6 addresses. 1. Choose **Get Response**. 1. The **Response returned by Route 53** section includes the following values: **DNS query sent to Route 53** The query, in [BIND format](https://en.wikipedia.org/wiki/Zone_file), that the checking tool sent to Route 53. This is the same format that a web application would use to send a query. The three values are typically the name of the record, **IN** (for internet), and the type of the record. **DNS response code** A code that indicates whether the query was valid or not. The most common response code is **NOERROR**, meaning that the query was valid. If the response is not valid, Route 53 returns a response code that explains why not. For a list of possible response codes, see [DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) on the IANA website. **Protocol** The protocol that Amazon Route 53 used to respond to the query, either **UDP** or **TCP**. **Response returned by Route 53** The value that Route 53 would return to a web application. The value is one of the following: + For non-alias records, the response contains the value or values in the record. + For multiple records that have the same name and type, which includes weighted, latency, geolocation, and failover, the response contains the value from the appropriate record, based on the request. + For alias records that refer to AWS resources other than another record, the response contains an IP address or a domain name for the AWS resource, depending on the type of resource. + For alias records that refer to other records, the response contains the value or values from the referenced record. # Configuring white-label name servers Each Amazon Route 53 hosted zone is associated with four name servers, known collectively as a delegation set. By default, the name servers have names like ns-2048.awsdns-64.com. If you want the domain name of your name servers to be the same as the domain name of your hosted zone, for example, ns1.example.com, you can configure white-label name servers, also known as vanity name servers or private name servers. The following steps explain how to configure one set of four white-label name servers that you can reuse for multiple domains. For example, suppose you own the domains example.com, example.org, and example.net. With these steps, you can configure white-label name servers for example.com and reuse them for example.org and example.net. **Topics** + [ ## Step 1: Create a Route 53 reusable delegation set ](#white-label-name-servers-create-reusable-delegation-set) + [ ## Step 2: Create or recreate Amazon Route 53 hosted zones, and change the TTL for NS and SOA records ](#white-label-name-servers-create-hosted-zones) + [ ## Step 3: Recreate records for your hosted zones ](#white-label-name-servers-create-resource-record-sets) + [ ## Step 4: Get IP addresses ](#white-label-name-servers-get-ip-addresses) + [ ## Step 5: Create records for white-label name servers ](#white-label-name-servers-create-white-label-resource-record-sets) + [ ## Step 6: Update NS and SOA records ](#white-label-name-servers-update-ns-soa-records) + [ ## Step 7: Create glue records and change the registrar's name servers ](#white-label-name-servers-create-glue-records) + [ ## Step 8: Monitor traffic for the website or application ](#white-label-name-servers-monitor-traffic) + [ ## Step 9: Change TTLs back to their original values ](#white-label-name-servers-change-ttls-back) + [ ## Step 10: (Optional) contact recursive DNS services ](#white-label-name-servers-contact-recursive-dns-services) ## Step 1: Create a Route 53 reusable delegation set White-label name servers are associated with a Route 53 reusable delegation set. You can use white-label name servers for a hosted zone only if the hosted zone and the reusable delegation set were created by the same AWS account. To create a reusable delegation set, you can use the Route 53 API, the AWS CLI, or one of the AWS SDKs. For more information, see the following documentation: + **Route 53 API** – See [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html) in the *Amazon Route 53 API Reference* + **AWS CLI** – See [create-reusable-delegation-set](https://docs.aws.amazon.com/cli/latest/reference/route53/create-reusable-delegation-set.html) in the *AWS CLI Command Reference* + **AWS SDKs** See the applicable SDK documentation on the [AWS Documentation](https://docs.aws.amazon.com/) page ## Step 2: Create or recreate Amazon Route 53 hosted zones, and change the TTL for NS and SOA records Create or recreate Amazon Route 53 hosted zones: + **If you aren't currently using Route 53 as the DNS service for the domains for which you want to use white-label name servers** – Create the hosted zones and specify the reusable delegation set that you created in the previous step with each hosted zone. For more information, see [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html) in the *Amazon Route 53 API Reference*. + **If you are using Route 53 as the DNS service for the domains for which you want to use white-label name servers** – You must recreate the hosted zones for which you want to use white-label name servers, and specify the reusable delegation set that you created in the previous step for each hosted zone. **Important** You cannot change the name servers that are associated with an existing hosted zone. You can associate a reusable delegation set with a hosted zone only when you create the hosted zone. When you create the hosted zones and before you try to access the resources for the corresponding domains, change the following TTL values for each hosted zone: + Change the TTL for the NS record for the hosted zone to 60 seconds or less. + Change the minimum TTL for the SOA record for the hosted zone to 60 seconds or less. This is the last value in the SOA record. If you accidentally give your registrar the wrong IP addresses for your white-label name servers, your website will become unavailable and remain unavailable for the duration of the TTL after you correct the problem. By setting a low TTL, you reduce the amount of time that your website is unavailable. For more information about creating hosted zones and specifying a reusable delegation set for the name servers for the hosted zones, see [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html) in the *Amazon Route 53 API Reference*. ## Step 3: Recreate records for your hosted zones Create records in the hosted zones that you created in Step 2: + **If you're migrating DNS service for your domains to Amazon Route 53** – You might be able to create records by importing information about your existing records. For more information, see [Creating records by importing a zone file](resource-record-sets-creating-import.md). + **If you're replacing existing hosted zones so that you can use white-label name servers** – In the new hosted zones, recreate the records that appear in your current hosted zones. Route 53 doesn't provide a method of exporting records from a hosted zone, but some third-party vendors do. You can then use the Route 53 import feature to import non-alias records for which the routing policy is simple. There is no way to export and re-import alias records or records for which the routing policy is anything other than simple. For information about creating records by using the Route 53 API, see [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html) in the *Amazon Route 53 API Reference*. For information about creating records by using the Route 53 console, see [Working with records](rrsets-working-with.md). ## Step 4: Get IP addresses Get the IPv4 and IPv6 addresses of the name servers in the reusable delegation set, and fill in the following table. **** | Name of a name server in your reusable delegation set (example: Ns-2048.awsdns-64.com) | IPv4 and IPv6 addresses                                             | Name that you want to assign to the white-label name server (example: ns1.example.com) | | --- | --- | --- | |   | IPv4: IPv6: |   | |   | IPv4: IPv6: |   | |   | IPv4: IPv6: |   | |   | IPv4: IPv6: |   | For example, suppose the four name servers for your reusable delegation set are: + ns-2048.awsdns-64.com + ns-2049.awsdns-65.net + ns-2050.awsdns-66.org + ns-2051.awsdns-67.co.uk Here are the Linux and Windows commands that you'd run to get the IP addresses for the first of your four name servers: **dig commands for Linux** ``` % dig A ns-2048.awsdns-64.com +short 192.0.2.117 ``` ``` % dig AAAA ns-2048.awsdns-64.com +short 2001:db8:85a3::8a2e:370:7334 ``` **nslookup command for Windows** ``` c:\> nslookup ns-2048.awsdns-64.com Non-authoritative answer: Name: ns-2048.awsdns-64.com Addresses: 2001:db8:85a3::8a2e:370:7334 192.0.2.117 ``` ## Step 5: Create records for white-label name servers In the hosted zone that has the same name (such as example.com) as the domain name of the white-label name servers (such as ns1.example.com), create eight records: + One A record for each white-label name server + One AAAA record for each white-label name server **Important** If you're using the same white-label name servers for two or more hosted zones, do not perform this step for the other hosted zones. For each record, specify the following values. Refer to the table that you filled in for the previous step: **Routing policy** Specify **Simple routing**. **Record name** The name that you want to assign to one of your white-label name servers, for example, ns1.example.com. For the prefix (ns1 in this example), you can use any value that is valid in a domain name. **Value/Route traffic to** The IPv4 or IPv6 address of one of the Route 53 name servers in your reusable delegation set. If you specify the wrong IP addresses when you created records for your white-label name servers, your website or web application will become unavailable on the internet when you perform subsequent steps. Even if you correct the IP addresses immediately, your website or web application will remain unavailable for the duration of the TTL. **Record type** Specify **A** when you're creating records for the IPv4 addresses. Specify **AAAA** when you're creating records for the IPv6 addresses. **TTL (seconds)** This value is the amount of time that DNS resolvers cache the information in this record before forwarding another DNS query to Route 53. We recommend that you specify an initial value of 60 seconds or less, so that you can recover quickly if you accidentally specify incorrect values in these records. ## Step 6: Update NS and SOA records Update SOA and NS records in the hosted zones that you want to use white-label name servers for. Perform Step 6 through Step 8 for one hosted zone and the corresponding domain at a time, then repeat for another hosted zone and domain. **Important** Start with the Amazon Route 53 hosted zone that has the same domain name (such as example.com) as the white-label name servers (such as ns1.example.com). 1. Update the SOA record by replacing the name of the Route 53 name server with the name of one of your white-label name servers **Example** Replace the name of the Route 53 name server: `ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 60` with the name of one of your white-label name servers: `ns1.example.com. hostmaster.example.com. 1 7200 900 1209600 60` **Note** You changed the last value, the time to live (TTL), in [Step 2: Create or recreate Amazon Route 53 hosted zones, and change the TTL for NS and SOA records](#white-label-name-servers-create-hosted-zones). For information about updating records by using the Route 53 console, see [Editing records](resource-record-sets-editing.md). 1. In the NS record, make note of the names of the current name servers for the domain, so you can revert to these name servers if necessary. 1. Update the NS record. Replace the name of the Route 53 name servers with the names of your four white-label name servers, for example, `ns1.example.com`, `ns2.example.com`, `ns3.example.com`, and `ns4.example.com`. ## Step 7: Create glue records and change the registrar's name servers Use the method provided by the registrar to create glue records and change the registrar's name servers: 1. Add glue records: + **If you're updating the domain that has the same domain name as the white-label name servers** – Create four glue records for which the names and IP addresses match the values that you got in step 4. Include both the IPv4 and the IPv6 address for a white-label name server in the corresponding glue record, for example: **ns1.example.com** – IP addresses = 192.0.2.117 and 2001:db8:85a3::8a2e:370:7334 Registrars use a variety of terminology for glue records. You might also see this referred to as registering new name servers or something similar. + **If you're updating another domain** – If Route 53 is your DNS service, you must first complete the step in the previous bullet and create the glue records that match the domain name. Then skip to step 2 in this procedure. 1. Change the name servers for the domain to the names of your white-label name servers. If you're using Amazon Route 53 as your DNS service, see [Adding or changing name servers and glue records for a domain](domain-name-servers-glue-records.md). ## Step 8: Monitor traffic for the website or application Monitor the traffic for the website or application for which you created glue records and changed name servers in Step 7: + **If the traffic stops** – Use the method provided by the registrar to change the name servers for the domain back to the previous Route 53 name servers. These are the name servers that you made note of in step 6b. Then determine what went wrong. + **If the traffic is unaffected** – Repeat Step 6 through Step 8 for the rest of the hosted zones for which you want to use the same white-label name servers. ## Step 9: Change TTLs back to their original values For all of the hosted zones that are now using white-label name servers, change the following values: + Change the TTL for the NS record for the hosted zone to a more typical value for NS records, for example, 172800 seconds (two days). + Change the minimum TTL for the SOA record for the hosted zone to a more typical value for SOA records, for example, 900 seconds. This is the last value in the SOA record. ## Step 10: (Optional) contact recursive DNS services *Optional* If you're using Amazon Route 53 geolocation routing, contact the recursive DNS services that support the edns-client-subnet extension of EDNS0, and give them the names of your white-label name servers. This ensures that these DNS services will continue to route DNS queries to the optimal Route 53 location based on the approximate geographical location that the query came from. # NS and SOA records that Amazon Route 53 creates for a public hosted zone For each public hosted zone that you create, Amazon Route 53 automatically creates a name server (NS) record and a start of authority (SOA) record. You rarely need to change these records. **Topics** + [ ## The name server (NS) record ](#NSrecords) + [ ## The start of authority (SOA) record ](#SOArecords) ## The name server (NS) record Amazon Route 53 automatically creates a name server (NS) record that has the same name as your hosted zone. It lists the four name servers that are the authoritative name servers for your hosted zone. Except in rare circumstances, we recommend that you don't add, change, or delete name servers in this record. The following examples show the format for the names of Route 53 name servers (these are examples only; don't use them when you're updating your registrar's name server records): + *ns-2048.awsdns-64.com* + *ns-2049.awsdns-65.net* + *ns-2050.awsdns-66.org* + *ns-2051.awsdns-67.co.uk* To get the list of name servers for your hosted zone: 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, click **Hosted zones**. 1. On the **Hosted zones** page, choose the radio button (not the name) for the hosted zone, then choose **View details**. 1. On the details page for the hosted zone, choose **Hosted zone details**. 1. Make note of the four servers listed for **Name servers**. For information about migrating DNS service from another DNS service provider to Route 53, see [Making Amazon Route 53 the DNS service for an existing domainMaking Route 53 the DNS service for an existing domain](MigratingDNS.md). ## The start of authority (SOA) record The start of authority (SOA) record identifies the base DNS information about the domain, for example: ``` 1. ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 86400 ``` A SOA record includes the following elements: + The Route 53 name server that created the SOA record, for example, `ns-2048.awsdns-64.net`. + The email address of the administrator. The `@` symbol is replaced by a period, for example, `hostmaster.example.com`. The default value is an amazon.com email address that is not monitored. + A serial number that you can optionally increment whenever you update a record in the hosted zone. Route 53 doesn't increment the number automatically. (The serial number is used by DNS services that support secondary DNS.) In the example, this value is `1`. + A refresh time in seconds that secondary DNS servers wait before querying the primary DNS server's SOA record to check for changes. In the example, this value is `7200`. + The retry interval in seconds that a secondary server waits before retrying a failed zone transfer. Normally, the retry time is less than the refresh time. In the example, this value is `900` (15 minutes). + The time in seconds that a secondary server will keep trying to complete a zone transfer. If this time elapses before a successful zone transfer, the secondary server will stop answering queries because it considers its data too old to be reliable. In the example, this value is `1209600` (two weeks). + The minimum time to live (TTL). This value helps define the length of time that recursive resolvers should cache the following responses from Route 53: **NXDOMAIN** There is no record of any type with the name that is specified in the DNS query, such as example.com. There also are no records that are children of the name that is specified in the DNS query, such as zenith.example.com. **NODATA** There is at least one record with the name that is specified in the DNS query, but none of those records have the type (such as A) that is specified in the DNS query. When a DNS resolver caches an NXDOMAIN or NODATA response, this is referred to as *negative caching*. The duration of negative caching is the lesser of the following values: + This value—the minimum TTL in the SOA record. In the example, the value is `86400` (one day). + The value of the TTL for the SOA record. The default value is 900 seconds. For information about changing this value, see [Editing records](resource-record-sets-editing.md). When Route 53 responds to DNS queries with an NXDOMAIN or NODATA response (a negative response), you're charged the rate for standard queries. (See "Queries" in [Amazon Route 53 Pricing](https://aws.amazon.com/route53/pricing/). If you're concerned about the cost of negative responses, one option is to change the TTL for the SOA record, the minimum TTL in the SOA record (this value), or both. Note that increasing these TTLs, which apply to negative responses for the entire hosted zone, can have both positive and negative effects: + DNS resolvers on the internet cache the non-existence of records for longer periods, which reduces the number of queries that are forwarded to Route 53. This reduces the Route 53 charge for DNS queries. + However, if you ever erroneously delete a valid record and later recreate it, DNS resolvers will cache the negative response (this record doesn't exist) for a longer period. This lengthens the amount of time that your customers or users can't reach the corresponding resource, such as a web server for acme.example.com. **To find your SOA records in Route 53** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **Hosted zones**. 1. Select the linked name of the domain for which you want to view records. 1. On the **Records** section you can see all the records listed and you can also filter records to find your SOA value. # Enabling accelerated recovery for managing public DNS records Route 53 accelerated recovery for managing public DNS records is designed to achieve a 60-minute Recovery Time Objective (RTO) in the event of service unavailability in the US East (N. Virginia) Region. When enabled on a Route 53 public hosted zone, you will be able to resume making changes to DNS records in the public hosted zone within approximately 60 minutes after AWS detects that operations in the US East (N. Virginia) Region are impaired. **Important** Accelerated recovery is available only for public hosted zones. Private hosted zones are not supported. **Note** DNS query resolution from the Route 53 data plane continues to work normally during Regional service impairment. See [Resilience in Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/disaster-recovery-resiliency.html) for an understanding of data plane versus control plane operations. **Topics** + [ ## How accelerated recovery for public DNS records works ](#accelerated-recovery-how-it-works) + [ ## Resubmitting DNS changes after failover ](#accelerated-recovery-resubmit) + [ ## Failback to the US East (N. Virginia) Region ](#accelerated-recovery-failback) + [ ## Additional considerations ](#accelerated-recovery-considerations) + [ ## How to enable accelerated recovery for managing public DNS records ](#accelerated-recovery-enable) ## How accelerated recovery for public DNS records works When accelerated recovery is enabled, Route 53 will maintain a copy of your public hosted zone in the US West (Oregon) Region. If services in the US East (N. Virginia) Region become unavailable for an extended period, Route 53 will execute failover within 60 minutes, automatically redirecting control plane operations for your accelerated recovery enabled public hosted zones to the US West (Oregon) Region. You can then continue to make DNS changes programmatically via the CLI, SDK, and API. Note that a limited set of API methods will be available during failover. See the "Additional considerations" section for more details. When the region recovers, Route 53 will execute the failback procedure, automatically directing control plane operations back to the US East (N. Virginia) Region. **Note** Before any impairment to US East (N. Virginia) Region occurs, you must first enable accelerated recovery for managing public DNS records on your public hosted zone. This can be done via the Console, CLI, SDK, or API (see the section titled *How to enable accelerated recovery for managing public DNS records* on this page below). You cannot enable accelerated recovery for managing public DNS records after a failover occurs. ## Resubmitting DNS changes after failover Under normal conditions, changes to public hosted zones with accelerated recovery enabled will be accepted by the US East (N. Virginia) Region and will then be successfully replicated to the US West (Oregon) Region. However, when service disruption occurs in the US East (N. Virginia) Region, some changes may be accepted by the US East (N. Virginia) Region, but may not be replicated to the US West (Oregon) Region. These in-flight changes are referred to as "stranded changes". Once failover completes, Route 53 recommends that you resubmit stranded changes before resuming your DNS workflows. You can achieve this either by using the API, or by using AWS CloudFormation, which are described below. ### Using the API to track and submit DNS changes If you are using the Route 53 API, AWS CLI, or AWS SDKs to manage DNS records, then you will need to use the [ChangeResourceRecordSets API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) and the [GetChange API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) to submit and track DNS changes, respectively. When you use the ChangeResourceRecordSets API to make DNS changes, Route 53 returns an identifier (ID) for the change you made (see [ChangeInfo](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeInfo.html) for change response object details). You can provide this ID in a subsequent request to the GetChange API and observe the status of the change. DNS changes with INSYNC status have been replicated to the US West (Oregon) Region and propagated to all Route 53 DNS servers. There are no further actions you need to take on these changes before or after a failover. However, during impairment to the US East (N. Virginia) Region, GetChange may return PENDING, indicating your change may not have replicated to the US West (Oregon) Region. If that's the case, when failover completes, GetChange will return NoSuchChange, indicating that Route 53 could not replicate this DNS change. Therefore, after failover you can safely disregard these stranded DNS changes and resubmit them as new DNS changes. You will know the failover process has completed when Route 53 posts a message to the AWS Health Dashboard. ### Using AWS CloudFormation to track and submit changes AWS CloudFormation automatically tracks replication status for your DNS changes utilizing the GetChange API, and only completes an update after DNS changes are confirmed as INSYNC. If you are using CloudFormation to manage DNS records and the US East (N. Virginia) Region becomes unavailable, then the actions you take using CloudFormation will not complete successfully during the period of unavailability. However, you can simply retry the same actions to allow CloudFormation to resubmit DNS changes, once the Route 53 failover process completes. ## Failback to the US East (N. Virginia) Region Route 53 will fail back control plane operations for your public hosted zone to the US East (N. Virginia) Region once the region recovers. During the failback, you will not need to resubmit your DNS changes, as no stranded changes will be introduced during this process. ## Additional considerations There are a few additional considerations to be aware of related to the accelerated recovery feature: 1. You will not be able to create new hosted zones, delete existing hosted zones, enable DNSSEC signing, or disable DNSSEC signing during failover. 1. AWS PrivateLink connections will not work after failover, but will work once again after a failback to the US East (N. Virginia) Region. 1. [CloudFront flat-rate plans](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/flat-rate-pricing-plan.html) are not supported at this time. 1. Hosted zones with accelerated recovery enabled cannot be deleted. You must disable accelerated recovery before attempting to delete the hosted zone. 1. During failover, the following API methods will continue to be supported for public hosted zones with accelerated recovery enabled. However, all other Route 53 API methods will not be functional until a failback occurs. + `ChangeResourceRecordSets` + `GetChange` + `GetGeoLocation` + `GetHostedZone` + `GetHostedZoneCount` + `GetHostedZoneLimit` + `GetReusableDelegationSet` + `GetReusableDelegationSetLimit` + `ListGeoLocations` + `ListHostedZones` + `ListHostedZonesByName` + `ListResourceRecordSets` + `ListReusableDelegationSets` ## How to enable accelerated recovery for managing public DNS records You can enable accelerated recovery for managing public DNS records using the Route 53 console, API, CLI, or SDK. The time it takes to enable accelerated recovery will depend on the size of your public hosted zone and other factors. You should plan for the process of enabling accelerated recovery to take up to several hours. You can check on the status of the enablement process in the Accelerated recovery tab of your public hosted zone or via the `GetHostedZone` API. As the process finalizes, there will be a brief period of time lasting up to several minutes where DNS changes are not accepted. Once completed, DNS changes can proceed as normal. **To enable and disable accelerated recovery using the Route 53 console** 1. Open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **Hosted zones**. 1. Choose the public hosted zone for which you want to enable accelerated recovery. 1. In the **Accelerated recovery** tab, choose **Enable**. 1. Choose **Save changes**. 1. Monitor the hosted zone status. The status shows **Enabling accelerated recovery** during setup and changes to **Enabled** when complete. You can disable accelerated recovery using the same steps above, but instead choosing **Disable**. CLI example to enable ``` aws route53 update-hosted-zone-features --enable-accelerated-recovery --hosted-zone-id Z123456789 ``` CLI example to disable ``` aws route53 update-hosted-zone-features --no-enable-accelerated-recovery --hosted-zone-id Z123456789 ```