# Configuring Amazon Route 53 as your DNS service
<a name="dns-configuring"></a>

You can use Amazon Route 53 as the DNS service for your domain, such as example.com. When Route 53 is your DNS service, it routes internet traffic to your website by translating friendly domain names like www.example.com into numeric IP addresses, like 192.0.2.1, that computers use to connect to each other. When someone types your domain name in a browser or sends you an email, a DNS query is forwarded to Route 53, which responds with the appropriate value. For example, Route 53 might respond with the IP address for the web server for example.com.

**DNS hosting vs. domain registration**  
This chapter covers using Route 53 for *DNS hosting only*. This means your domain registration stays with your current registrar, and you'll continue paying them for domain renewals. Route 53 will only manage your DNS settings and handle DNS queries for your domain.  
If you want to transfer your domain registration to Route 53 as well (making Route 53 both your registrar and DNS service), see [Pre-transfer checklist for domain transfers](domain-transfer-checklist.md) and [Transferring registration for a domain to Amazon Route 53](domain-transfer-to-route-53.md).

In this chapter, we explain how to configure Route 53 to route your internet traffic to the right places. We also explain how to migrate DNS service to Route 53 if you're currently using another DNS service, and how to use Route 53 as the DNS service for a new domain. 

**Topics**
+ [

# Making Amazon Route 53 the DNS service for an existing domain
](MigratingDNS.md)
+ [

# Configuring DNS routing for a new domain
](dns-configuring-new-domain.md)
+ [

# Routing traffic to your resources
](dns-routing-traffic-to-resources.md)
+ [

# Working with hosted zones
](hosted-zones-working-with.md)
+ [

# Working with records
](rrsets-working-with.md)
+ [

# Configuring DNSSEC signing in Amazon Route 53
](dns-configuring-dnssec.md)
+ [

# Using AWS Cloud Map to create records and health checks
](autonaming.md)
+ [

# DNS constraints and behaviors
](DNSBehavior.md)
+ [

# Related topics
](dns-configuring-related-topics.md)

# Making Amazon Route 53 the DNS service for an existing domain
<a name="MigratingDNS"></a>

If you're transferring one or more domain registrations to Route 53, and you're currently using a domain registrar that doesn't provide paid DNS service, you need to migrate DNS service before you migrate the domain. Otherwise, the registrar will stop providing DNS service when you transfer your domains, and the associated websites and web applications will become unavailable on the internet. (You can also migrate DNS service from the current registrar to another DNS service provider. We don't require you to use Route 53 as the DNS service provider for domains that are registered with Route 53.)

The process depends on whether you're currently using the domain:
+ If the domain is currently getting traffic—for example, if your users are using the domain name to browse to a website or access a web application—see [Making Route 53 the DNS service for a domain that's in use](migrate-dns-domain-in-use.md).
+ If the domain isn't getting any traffic (or is getting very little traffic), see [Making Route 53 the DNS service for an inactive domain](migrate-dns-domain-inactive.md).

For both options, your domain should remain available during the entire migration process. However, in the unlikely event that there are issues, the first option lets you roll back the migration quickly. With the second option, your domain could be unavailable for a couple of days.

If you want to connect with an expert at AWS, visit [Sales support](https://aws.amazon.com/contact-us/sales-support/?pg=ln&sec=hs).

# Making Route 53 the DNS service for a domain that's in use
<a name="migrate-dns-domain-in-use"></a>

If you want to migrate DNS service to Amazon Route 53 for a domain that is currently getting traffic—for example, if your users are using the domain name to browse to a website or access a web application—perform the procedures in this section.

**Topics**
+ [

## Step 1: Get your current DNS configuration from the current DNS service provider (optional but recommended)
](#migrate-dns-get-zone-file)
+ [

## Step 2: Create a hosted zone
](#migrate-dns-create-hosted-zone)
+ [

## Step 3: Create records
](#migrate-dns-create-records)
+ [

## Step 4: Lower TTL settings
](#migrate-dns-lower-ttl)
+ [

## Step 5: (If you have DNSSEC configured) Remove the DS record from the parent zone
](#migrate-remove-ds)
+ [

## Step 6: Wait for the old TTL to expire
](#migrate-dns-wait-for-ttl)
+ [

## Step 7: Update the NS records to use Route 53 name servers
](#migrate-dns-change-name-servers-with-provider)
+ [

## Step 8: Monitor traffic for the domain
](#migrate-dns-monitor-traffic)
+ [

## Step 9: Change the TTL for the NS record back to a higher value
](#migrate-dns-change-ttl-back)
+ [

## Step 10: Transfer domain registration to Amazon Route 53
](#migrate-dns-transfer-domain-registration)
+ [

## Step 11: Re-enable DNSSEC signing (if required)
](#migrate-dns-re-enable-dnssec)

## Step 1: Get your current DNS configuration from the current DNS service provider (optional but recommended)
<a name="migrate-dns-get-zone-file"></a>

When you migrate DNS service from another provider to Route 53, you reproduce your current DNS configuration in Route 53. In Route 53, you create a hosted zone that has the same name as your domain, and you create records in the hosted zone. Each record indicates how you want to route traffic for a specified domain name or subdomain name. For example, when someone enters your domain name in a web browser, do you want traffic to be routed to a web server in your data center, to an Amazon EC2 instance, to a CloudFront distribution, or to some other location?

The process that you use depends on the complexity of your current DNS configuration:
+ **If your current DNS configuration is simple** – If you're routing internet traffic for just a few subdomains to a small number of resources, such as web servers or Amazon S3 buckets, then you can manually create a few records in the Route 53 console.
+ **If your current DNS configuration is more complex, and you just want to reproduce your current configuration** – You can simplify the migration if you can get a zone file from the current DNS service provider, and import the zone file into Route 53. (Not all DNS service providers offer zone files.) When you import a zone file, Route 53 automatically reproduces the existing configuration by creating the corresponding records in your hosted zone.

  Try asking customer support with your current DNS service provider how to get a *zone file* or a *records list*. For information about the required format of the zone file, see [Creating records by importing a zone file](resource-record-sets-creating-import.md).
+ **If your current DNS configuration is more complex, and you're interested in Route 53 routing features** – Review the following documentation to see whether you want to use Route 53 features that aren't available from other DNS service providers. If so, you can either create records manually, or you can import a zone file and then create or update records later:
  + [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md) explains the advantages of Route 53 alias records, which route traffic to some AWS resources, such as CloudFront distributions and Amazon S3 buckets, for no charge.
  + [Choosing a routing policy](routing-policy.md) explains the Route 53 routing options, for example, routing based on the location of your users, routing based on the latency between your users and your resources, routing based on whether your resources are healthy, and routing to resources based on weights that you specify.
**Note**  
You can also import a zone file and later change your configuration to take advantage of alias records and complex routing policies.

If you can't get a zone file or if you want to manually create records in Route 53, the records that you're likely to migrate include the following:
+ **A (Address) records** – associate a domain name or subdomain name with the IPv4 address (for example, 192.0.2.3) of the corresponding resource
+ **AAAA (Address) records** – associate a domain name or subdomain name with the IPv6 address (for example, 2001:0db8:85a3:0000:0000:abcd:0001:2345) of the corresponding resource
+ **Mail server (MX) records** – route traffic to mail servers
+ **CNAME records** – reroute traffic for one domain name (example.net) to another domain name (example.com)
+ **Records for other supported DNS record types** – For a list of supported record types, see [Supported DNS record types](ResourceRecordTypes.md).

## Step 2: Create a hosted zone
<a name="migrate-dns-create-hosted-zone"></a>

To tell Amazon Route 53 how you want to route traffic for your domain, you create a hosted zone that has the same name as your domain, and then you create records in the hosted zone. 

**Important**  
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.

When you create a hosted zone, 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 Route 53 associated with your hosted zone. To make Route 53 the DNS service for your domain, you update the registration for the domain to use these four name servers. 

**Important**  
Don't create additional name server (NS) or start of authority (SOA) records, and don't delete the existing NS and SOA records. <a name="migrate-dns-create-hosted-zone-procedure"></a>

**To create a 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. If you're new to Route 53, choose **Get started** under **DNS management**, and then choose **Create hosted zones**.

   If you're already using Route 53, choose **Hosted zones** in the navigation pane, and then choose **Create hosted zones**.

1. In the **Create hosted zone** pane, enter a domain name and, optionally, a comment. For more information about a setting, choose to open the help panel on the right side.

   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 hosted zone**.

## Step 3: Create records
<a name="migrate-dns-create-records"></a>

After you create a hosted zone, you create records in the hosted zone that define where you want to route traffic for a domain (example.com) or subdomain (www.example.com). For example, if you want to route traffic for example.com and www.example.com to a web server on an Amazon EC2 instance, you create two records, one named example.com and the other named www.example.com. In each record, you specify the IP address for your EC2 instance.

You can create records in a variety of ways:

**Import a zone file**  
This is the easiest method if you got a zone file from your current DNS service in [Step 1: Get your current DNS configuration from the current DNS service provider (optional but recommended)](#migrate-dns-get-zone-file). Amazon Route 53 can't predict when to create alias records or to use special routing types such as weighted or failover. As a result, if you import a zone file, Route 53 creates standard DNS records using the simple routing policy.  
For more information, see [Creating records by importing a zone file](resource-record-sets-creating-import.md).

**Create records individually in the console**  
If you didn't get a zone file and you just want to create a few records with a routing policy of Simple to get started, you can create the records in the Route 53 console. You can create both alias and non-alias records.  
For more information, see the following topics:  
+ [Choosing a routing policy](routing-policy.md)
+ [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md)
+ [Creating records by using the Amazon Route 53 console](resource-record-sets-creating.md)

**Create records programmatically**  
You can create records by using one of the AWS SDKs, the AWS CLI, or AWS Tools for Windows PowerShell. For more information, see [AWS Documentation](https://docs.aws.amazon.com/).  
If you're using a programming language that AWS doesn't provide an SDK for, you can also use the Route 53 API. For more information, see the [Amazon Route 53 API Reference](https://docs.aws.amazon.com/Route53/latest/APIReference/).

## Step 4: Lower TTL settings
<a name="migrate-dns-lower-ttl"></a>

The TTL (time to live) setting for a record specifies how long you want DNS resolvers to cache the record and use the cached information. When the TTL expires, a resolver sends another query to the DNS service provider for a domain to get the latest information.

The typical TTL setting for the NS record is 172800 seconds, or two days. The NS record lists the name servers that the Domain Name System (DNS) can use to get information about how to route traffic for your domain. Lowering the TTL for the NS record, both with your current DNS service provider and with Amazon Route 53, reduces downtime for your domain if you discover a problem while you're migrating DNS to Route 53. If you don't lower the TTL, your domain could be unavailable on the internet for up to two days if something goes wrong.

**Note**  
Some full resolvers may cache the TTL of the NS record of the parent authoritative server, therefore the TTL of NS records registered on the parent authoritative DNS server must also be reduced.

We recommend that you change the TTL on the following NS records:
+ On the NS record in the hosted zone for the current DNS service provider. (Your current provider might use different terminology.)
+ On the NS record in the hosted zone that you created in [Step 2: Create a hosted zone](#migrate-dns-create-hosted-zone).<a name="migrate-dns-lower-ttl-current-provider-procedure"></a>

**To lower the TTL setting on the NS record with the current DNS service provider**
+ Use the method provided by the current DNS service provider for the domain to change the TTL for the NS record in the hosted zone for your domain.<a name="migrate-dns-lower-ttl-route-53-procedure"></a>

**To lower the TTL setting on the NS record in a Route 53 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. Choose **Hosted Zones** in the navigation pane.

1. Choose the name of the hosted zone.

1. Choose the NS record, and choose **Edit**.

1. Change the value of **TTL (Seconds)**. We recommend that you specify a value between 60 seconds and 900 seconds (15 minutes).

1. Choose **Save changes**.

## Step 5: (If you have DNSSEC configured) Remove the DS record from the parent zone
<a name="migrate-remove-ds"></a>

If you've configured DNSSEC for your domain, remove the Delegation Signer (DS) record from the parent zone before you migrate your domain to Route 53. 

If the parent zone is hosted through Route 53 or another registrar, contact them to remove the DS record.

 Because it isn't currently possible to have DNSSEC signing enabled across two providers, you must remove any DS or DNSKEYs to deactivate DNSSEC. This temporarily signals to DNS resolvers to disable DNSSEC validation. In [step 11](#migrate-dns-re-enable-dnssec), you can re-enable DNSSEC validation if desired, after the transition to Route 53 is completed.

For more information, see [Deleting public keys for a domain](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys).

## Step 6: Wait for the old TTL to expire
<a name="migrate-dns-wait-for-ttl"></a>

If your domain is in use—for example, if your users are using the domain name to browse to a website or access a web application—then DNS resolvers have cached the names of the name servers that were provided by your current DNS service provider. A DNS resolver that cached that information a few minutes ago will save it for almost two more days.

To ensure that migrating DNS service to Route 53 happens all at one time, wait for two days after you lowered the TTL. After the two-day TTL expires and resolvers request the name servers for your domain, the resolvers will get the current name servers and will also get the new TTL that you specified in [Step 4: Lower TTL settings](#migrate-dns-lower-ttl).

## Step 7: Update the NS records to use Route 53 name servers
<a name="migrate-dns-change-name-servers-with-provider"></a>

To begin using Amazon Route 53 as the DNS service for a domain, use the method provided by the registrar, or the parent zone, to replace the current name servers in the NS record with Route 53 name servers.

**Note**  
When you update the NS record with the current DNS service provider to use Route 53 name servers, you're updating the DNS configuration for the domain. (This is comparable to updating the NS record in the Route 53 hosted zone for a domain except that you're updating the setting with the DNS service that you're migrating away from.) <a name="migrate-dns-change-name-servers-with-provider-procedure"></a>

**To update the NS record at the registrar, or the parent zone, to use Route 53 name servers**

1. In the Route 53 console, get the 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, choose **Hosted zones**.

   1. On the **Hosted zones** page, choose the name for the applicable hosted zone.

   1. Make note of the four names listed for **Name servers** in the **Hosted zone details** section.

1. Use the method that is provided by the current DNS service for the domain to update the NS record for the hosted zone. 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).The process depends on whether the current DNS service lets you delete name servers:

   **If you can delete name servers**
   + Make note of the names of the current name servers in the NS record for the hosted zone. If you need to revert to the current DNS configuration, these are the servers that you'll specify.
   + Delete the current name servers from the NS record. 
   + Update the NS record with the names of all four of the Route 53 name servers that you got in step 1 of this procedure.
**Note**  
When you're finished, the only name servers in the NS record will be the four Route 53 name servers.

   **If you cannot delete name servers**
   + Choose the option to use custom name servers.
   + Add all four Route 53 name servers that you got in step 1 of this procedure. 

## Step 8: Monitor traffic for the domain
<a name="migrate-dns-monitor-traffic"></a>

Monitor traffic for the domain, including website or application traffic, and email:
+ **If the traffic slows or stops** – Use the method provided by the previous DNS service to change the name servers for the domain back to the previous name servers. These are the name servers that you made note of in step 7 of [To update the NS record at the registrar, or the parent zone, to use Route 53 name servers](#migrate-dns-change-name-servers-with-provider-procedure). Then determine what went wrong.
+ **If the traffic is unaffected** – Continue to [Step 9: Change the TTL for the NS record back to a higher value](#migrate-dns-change-ttl-back).

## Step 9: Change the TTL for the NS record back to a higher value
<a name="migrate-dns-change-ttl-back"></a>

In the Amazon Route 53 hosted zone for the domain, change the TTL for the NS record to a more typical value, for example, 172800 seconds (two days). This improves latency for your users because they don't have to wait as often for DNS resolvers to send a query for the name servers for your domain.<a name="migrate-dns-change-ttl-back-procedure"></a>

**To change the TTL for the NS record in the Route 53 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. Choose **Hosted Zones** in the navigation pane.

1. Choose the name of the hosted zone.

1. In the list of records for the hosted zone, choose the NS record.

1. Choose **Edit**.

1. Change **TTL (Seconds)** to the number of seconds that you want DNS resolvers to cache the names of the name servers for your domain. We recommend a value of 172800 seconds.

1. Choose **Save changes**.

## Step 10: Transfer domain registration to Amazon Route 53
<a name="migrate-dns-transfer-domain-registration"></a>

Now that you've transferred DNS service for a domain to Amazon Route 53, you can optionally transfer registration for the domain to Route 53. For more information, see [Transferring registration for a domain to Amazon Route 53](domain-transfer-to-route-53.md).

## Step 11: Re-enable DNSSEC signing (if required)
<a name="migrate-dns-re-enable-dnssec"></a>

Now that you've transferred DNS service for a domain to Amazon Route 53, you can re-enable DNSSEC signing.

Enabling DNSSEC signing has two steps: 
+ Step 1: Enable DNSSEC signing for Route 53, and request that Route 53 create a key signing key (KSK) based on a customer managed key in AWS Key Management Service (AWS KMS).
+ Step 2: Create a chain of trust for the hosted zone by adding a Delegation Signer (DS) record to the parent zone, so DNS responses can be authenticated with trusted cryptographic signatures.

  For instructions, see [Enabling DNSSEC signing and establishing a chain of trust](dns-configuring-dnssec-enable-signing.md).

# Making Route 53 the DNS service for an inactive domain
<a name="migrate-dns-domain-inactive"></a>

If you want to migrate DNS service to Amazon Route 53 for a domain that isn't getting any traffic (or is getting very little traffic), perform the procedures in this section.

**Topics**
+ [

## Step 1: Get your current DNS configuration from the current DNS service provider (inactive domains)
](#migrate-dns-get-zone-file-domain-inactive)
+ [

## Step 2: Create a hosted zone (inactive domains)
](#migrate-dns-create-hosted-zone-domain-inactive)
+ [

## Step 3: Create records (inactive domains)
](#migrate-dns-create-records-domain-inactive)
+ [

## Step 4: Update the domain registration to use Amazon Route 53 name servers (inactive domains)
](#migrate-dns-update-domain-inactive)

## Step 1: Get your current DNS configuration from the current DNS service provider (inactive domains)
<a name="migrate-dns-get-zone-file-domain-inactive"></a>

When you migrate DNS service from another provider to Route 53, you reproduce your current DNS configuration in Route 53. In Route 53, you create a hosted zone that has the same name as your domain, and you create records in the hosted zone. Each record indicates how you want to route traffic for a specified domain name or subdomain name. For example, when someone enters your domain name in a web browser, do you want traffic to be routed to a web server in your data center, to an Amazon EC2 instance, to a CloudFront distribution, or to some other location?

The process that you use depends on the complexity of your current DNS configuration:
+ **If your current DNS configuration is simple** – If you're routing internet traffic for just a few subdomains to a small number of resources, such as web servers or Amazon S3 buckets, then you can manually create a few records in the Route 53 console.
+ **If your current DNS configuration is more complex, and you just want to reproduce your current configuration** – You can simplify the migration if you can get a zone file from the current DNS service provider, and import the zone file into Route 53. (Not all DNS service providers offer zone files.) When you import a zone file, Route 53 automatically reproduces the existing configuration by creating the corresponding records in your hosted zone.

  Try asking customer support with your current DNS service provider how to get a *zone file* or a *records list*. For information about the required format of the zone file, see [Creating records by importing a zone file](resource-record-sets-creating-import.md).
+ **If your current DNS configuration is more complex, and you're interested in Route 53 routing features** – Review the following documentation to see whether you want to use Route 53 features that aren't available from other DNS service providers. If so, you can either create records manually, or you can import a zone file and then create or update records later:
  + [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md) explains the advantages of Route 53 alias records, which route traffic to some AWS resources, such as CloudFront distributions and Amazon S3 buckets, for no charge.
  + [Choosing a routing policy](routing-policy.md) explains the Route 53 routing options, for example, routing based on the location of your users, routing based on the latency between your users and your resources, routing based on whether your resources are healthy, and routing to resources based on weights that you specify.
**Note**  
You can also import a zone file and later change your configuration to take advantage of alias records and complex routing policies.

If you can't get a zone file or if you want to manually create records in Route 53, the records that you're likely to migrate include the following:
+ **A (Address) records** – associate a domain name or subdomain name with the IPv4 address (for example, 192.0.2.3) of the corresponding resource
+ **AAAA (Address) records** – associate a domain name or subdomain name with the IPv6 address (for example, 2001:0db8:85a3:0000:0000:abcd:0001:2345) of the corresponding resource
+ **Mail server (MX) records** – route traffic to mail servers
+ **CNAME records** – reroute traffic for one domain name (example.net) to another domain name (example.com)
+ **Records for other supported DNS record types** – For a list of supported record types, see [Supported DNS record types](ResourceRecordTypes.md).

## Step 2: Create a hosted zone (inactive domains)
<a name="migrate-dns-create-hosted-zone-domain-inactive"></a>

To tell Amazon Route 53 how you want to route traffic for your domain, you create a hosted zone that has the same name as your domain, and then you create records in the hosted zone. 

**Important**  
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.

When you create a hosted zone, 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 Route 53 associated with your hosted zone. To make Route 53 the DNS service for your domain, you update the registration for the domain to use these four name servers. 

**Important**  
Don't create additional name server (NS) or start of authority (SOA) records, and don't delete the existing NS and SOA records. <a name="migrate-dns-create-hosted-zone-procedure"></a>

**To create a 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. If you're new to Route 53, choose **Get started**.

   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 a domain name and, optionally, a comment. For more information about a setting, pause the mouse pointer over its label to see a tool tip.

   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 **Record type**, accept the default value of **Public hosted zone**.

1. Choose **Create hosted zone**.

## Step 3: Create records (inactive domains)
<a name="migrate-dns-create-records-domain-inactive"></a>

After you create a hosted zone, you create records in the hosted zone that define where you want to route traffic for a domain (example.com) or subdomain (www.example.com). For example, if you want to route traffic for example.com and www.example.com to a web server on an Amazon EC2 instance, you create two records, one named example.com and the other named www.example.com. In each record, you specify the IP address for your EC2 instance.

You can create records in a variety of ways:

**Import a zone file**  
This is the easiest method if you got a zone file from your current DNS service in [Step 1: Get your current DNS configuration from the current DNS service provider (inactive domains)](#migrate-dns-get-zone-file-domain-inactive). Amazon Route 53 can't predict when to create alias records or to use special routing types such as weighted or failover. As a result, if you import a zone file, Route 53 creates standard DNS records using the simple routing policy.  
For more information, see [Creating records by importing a zone file](resource-record-sets-creating-import.md).

**Create records individually in the console**  
If you didn't get a zone file and you just want to create a few records with a routing policy of Simple to get started, you can create the records in the Route 53 console. You can create both alias and non-alias records.  
For more information, see the following topics:  
+ [Choosing a routing policy](routing-policy.md)
+ [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md)
+ [Creating records by using the Amazon Route 53 console](resource-record-sets-creating.md)

**Create records programmatically**  
You can create records by using one of the AWS SDKs, the AWS CLI, or AWS Tools for Windows PowerShell. For more information, see [AWS Documentation](https://docs.aws.amazon.com/).  
If you're using a programming language that AWS doesn't provide an SDK for, you can also use the Route 53 API. For more information, see the [Amazon Route 53 API Reference](https://docs.aws.amazon.com/Route53/latest/APIReference/).

## Step 4: Update the domain registration to use Amazon Route 53 name servers (inactive domains)
<a name="migrate-dns-update-domain-inactive"></a>

When you've finished creating records for the domain, you can change the DNS service for your domain to Amazon Route 53. Perform the following procedure to update settings with the domain registrar.<a name="migrate-dns-update-domain-inactive-procedure"></a>

**To update the name servers for the domain**

1. In the Route 53 console, get the name servers for your Route 53 hosted zone:

   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. 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**.

1. Use the method provided by the registrar for the domain to change the name servers for the domain to use the four Route 53 name servers that you got in step 2 of this procedure.

   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).

# Configuring DNS routing for a new domain
<a name="dns-configuring-new-domain"></a>

**A new domain you purchased from Route 53**  
When you register a domain with Route 53, we automatically make Route 53 the DNS service for the domain. Route 53 creates a hosted zone that has the same name as the domain, assigns four name servers to the hosted zone, and updates the domain to use those name servers.

**A new domain you purchased from another registrar**  
When you purchase a domain from another registrar, for example, because the top-level domain (TLD) isn't offered by Route 53, you have two options:
+ **Use Route 53 for DNS hosting only:** Keep your current registrar but delegate DNS management to Route 53. Follow the procedure below to create a hosted zone and update your registrar's name servers.
+ **Transfer the domain registration to Route 53:** Make Route 53 your registrar and DNS service. See [Pre-transfer checklist for domain transfers](domain-transfer-checklist.md) for prerequisites and [Transferring registration for a domain to Amazon Route 53](domain-transfer-to-route-53.md) for the transfer process.

For more information about TLDs supported by Route 53, see [Domains that you can register with Amazon Route 53](registrar-tld-list.md).

Follow these instructions to create a public hosted zone and then use the name servers created with the registrar:<a name="dns-configuring-create-hosted-zone-for-different-registrar"></a>

**To create a hosted zone for a non-Route 53 domain**

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 then choose **Create hosted zone**.

1. For the **Name**, enter the name of the domain you want to create a hosted zone for, Such as `example.com`, an optional description, choose **Public hosted zone** and then **Create hosted zone**.

1. After you create the hosted zone, note the four name server (NS) records that were created. Each will start with "ns-".

   At your domain registrar, enter the name servers from above to delegate the domain management to your Route 53 hosted zone.

**Route DNS traffic**  
To specify how you want Route 53 to route internet traffic for the domain, you create records in the hosted zone. For example, if you want to route requests for example.com to a web server that's running on an Amazon EC2 instance, you create a record in the example.com hosted zone, and you specify the Elastic IP address for the EC2 instance. For more information, see the following topics:
+ For information about how to create records in your hosted zone, see [Working with records](rrsets-working-with.md).
+ For information about how to route traffic to selected AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).
+ For information about how DNS works, see [How internet traffic is routed to your website or web application](welcome-dns-service.md).
+ To check DNS repose, see [Checking DNS responses from Route 53](dns-test.md).

# Routing traffic to your resources
<a name="dns-routing-traffic-to-resources"></a>

When users request your website or web application, for example, by entering the name of your domain in a web browser, Amazon Route 53 helps to route users to your resources, such as an Amazon S3 bucket or a web server in your data center. To configure Route 53 to route traffic to your resources, you do the following:

1. Create a hosted zone. You can create either a public hosted zone or a private hosted zone:  
**Public hosted zone**  
Create a public hosted zone if you want to route internet traffic to your resources, for example, so your customers can view the company website that you're hosting on EC2 instances. For more information, see [Working with public hosted zones](AboutHZWorkingWith.md).  
**Private hosted zone**  
Create a private hosted zone if you want to route traffic within an Amazon VPC. For more information, see [Working with private hosted zones](hosted-zones-private.md).

1. Create records in the hosted zone. Records define where you want to route traffic for each domain name or subdomain name. For example, to route traffic for www.example.com to a web server in your data center, you typically create a www.example.com record in the example.com hosted zone. 

   For more information, see the following topics:
   + [Working with records](rrsets-working-with.md)
   + [Routing traffic for subdomains](dns-routing-traffic-for-subdomains.md)
   + [Routing internet traffic to your AWS resources](routing-to-aws-resources.md)

# Routing traffic for subdomains
<a name="dns-routing-traffic-for-subdomains"></a>

When you want to route traffic to your resources for a subdomain, such as acme.example.com or zenith.example.com, you have two options:

**Create records in the hosted zone for the domain**  
Typically, to route traffic for a subdomain, you create a record in the hosted zone that has the same name as the domain. For example, to route internet traffic for acme.example.com to a web server in your data center, you create a record named acme.example.com in the example.com hosted zone. For more information, see the topic [Working with records](rrsets-working-with.md) and its subtopics.

**Create a hosted zone for the subdomain, and create records in the new hosted zone**  
You can also create a hosted zone for the subdomain. Using a separate hosted zone to route internet traffic for a subdomain is sometimes known as "delegating responsibility for a subdomain to a hosted zone" or "delegating a subdomain to other name servers" or some similar combination of terms. Here's an overview of how it works:  

1. You create a hosted zone that has the same name as the subdomain that you want to route traffic for, such as acme.example.com.

1. You create records in the new hosted zone that define how you want to route traffic for the subdomain (acme.example.com) and its subdomains, such as backend.acme.example.com. 

1. You get the name servers that Route 53 assigned to the new hosted zone when you created it.

1. You create a new NS record in the hosted zone for the domain (example.com). The NS record name must be the subdomain name (acme.example.com), and you specify the four name servers that you got in step 3 as the record values.
When you use a separate hosted zone to route traffic for a subdomain, you can use IAM permissions to restrict access to the hosted zone for the subdomain. If you have multiple subdomains that are managed by different groups, creating a hosted zone for each subdomain can significantly reduce the number of people who must have access to records in the hosted zone for the domain.  
To implement this delegation process, you need the following IAM permissions. For more information about Route 53 IAM policies, see [Identity and access management in Amazon Route 53](security-iam.md):    
**Parent account (owns example.com)**  
The user or role needs permissions to modify records in the parent domain's hosted zone:  
**Child account (creates acme.example.com)**  
The user or role needs permissions to create and manage the subdomain hosted zone:
Using a separate hosted zone for a subdomain also allows you to use different DNS services for the domain and the subdomain. For more information, see [Using Amazon Route 53 as the DNS service for subdomains without migrating the parent domain](creating-migrating.md).  
There's a small performance impact to this configuration for the first DNS query from each DNS resolver. The resolver must get information from the hosted zone for the root domain and then get information from the hosted zone for the subdomain. After the first DNS query for a subdomain, the resolver caches the information and doesn't need to get it again until the TTL expires and another client requests the subdomain from that resolver. For more information, see [TTL (seconds)](resource-record-sets-values-basic.md#rrsets-values-basic-ttl) in the section [Values that you specify when you create or edit Amazon Route 53 records](resource-record-sets-values.md).

**Topics**
+ [

## Creating another hosted zone to route traffic for a subdomain
](#dns-routing-traffic-for-subdomains-new-hosted-zone)
+ [

## Routing traffic for additional levels of subdomains
](#dns-routing-traffic-for-sub-subdomains)

## Creating another hosted zone to route traffic for a subdomain
<a name="dns-routing-traffic-for-subdomains-new-hosted-zone"></a>

One way to route traffic for a subdomain is to create a hosted zone for the subdomain, and then create records for the subdomain in the new hosted zone. (The more common option is to create records for the subdomain in the hosted zone for the domain.)

**Note**  
This procedure shows how to delegate a subdomain to Route 53. You can also delegate a subdomain to other DNS services by creating NS records that point to those services' name servers instead.

Here's an overview of the process:

1. Create a hosted zone for the subdomain. For more information, see [Creating a new hosted zone for a subdomain](#dns-routing-traffic-for-subdomains-creating-hosted-zone). 

1. Add records to the hosted zone for the subdomain. If the hosted zone for the domain contains any records that belong in the hosted zone for the subdomain, duplicate those records in the hosted zone for the subdomain. For more information, see [Creating records in the hosted zone for the subdomain](#dns-routing-traffic-for-subdomains-creating-records) 

1. Create an NS record for the subdomain in the hosted zone for the domain, which delegates responsibility for the subdomain to the name servers in the new hosted zone. If the hosted zone for the domain contains any records that belong in the hosted zone for the subdomain, delete the records from the hosted zone for the domain. (You created copies in the hosted zone for the subdomain in step 2.) For more information, see [Updating the hosted zone for the domain](#dns-routing-traffic-for-subdomains-delegating-responsibility).

### Creating a new hosted zone for a subdomain
<a name="dns-routing-traffic-for-subdomains-creating-hosted-zone"></a>

To create a hosted zone for a subdomain using the Route 53 console, perform the following procedure.

**To create a hosted zone for a subdomain (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**. 

   If you're already using Route 53, choose **Hosted zones** in the navigation pane. 

1. Choose **Create hosted zone**.

1. In the right pane, enter the name of the subdomain, such as acme.example.com. 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. At the bottom of the right pane, choose **Create hosted zone**.

### Creating records in the hosted zone for the subdomain
<a name="dns-routing-traffic-for-subdomains-creating-records"></a>

To define how you want Route 53 to route traffic for the subdomain (acme.example.com) and its subdomains (backend.acme.example.com), you create records in the hosted zone for the subdomain.

Note the following about creating records in the hosted zone for the subdomain:
+ Don't create additional name server (NS) or start of authority (SOA) records in the hosted zone for the subdomain, and don't delete the existing NS and SOA records.
+ Create all records for the subdomain in the hosted zone for the subdomain. For example, if you have hosted zones for example.com and for acme.example.com domain, create all records for the acme.example.com subdomain in the acme.example.com hosted zone. This includes records such as backend.acme.example.com and beta.backend.acme.example.com.
+ If the hosted zone for the domain (example.com) already contains records that belong in the hosted zone for the subdomain (acme.example.com), duplicate those records in the hosted zone for the subdomain. In the last step of the process, you delete the duplicate records from the hosted zone for the domain later.
**Important**  
If you have some records for the subdomain in both the hosted zone for the domain and the hosted zone for the subdomain, DNS behavior will be inconsistent. Behavior will depend on which name servers a DNS resolver has cached, the name servers for the domain hosted zone (example.com) or the name servers for the subdomain hosted zone (acme.example.com). In some cases, Route 53 will return NXDOMAIN (non-existent domain) when the record exists, but not in the hosted zone that DNS resolvers are submitting the query to.

For more information, see [Working with records](rrsets-working-with.md).

### Updating the hosted zone for the domain
<a name="dns-routing-traffic-for-subdomains-delegating-responsibility"></a>

When you create a hosted zone, Route 53 automatically assigns four name servers to the zone. The NS record for a hosted zone identifies the name servers that respond to DNS queries for the domain or subdomain. To start using the records in the hosted zone for the subdomain to route internet traffic, you create a new NS record in the hosted zone for the domain (example.com), and give it the name of the subdomain (acme.example.com). For the value of the NS record, you specify the names of the name servers from the hosted zone for the subdomain. 

Here's what happens when Route 53 receives a DNS query from a DNS resolver for the subdomain acme.example.com or one of its subdomains:

1. Route 53 looks in the hosted zone for the domain (example.com) and finds the NS record for the subdomain (acme.example.com).

1. Route 53 gets the name servers from the acme.example.com NS record in the hosted zone for the domain, example.com, and returns those name servers to the DNS resolver. 

1. The resolver resubmits the query for acme.example.com to the name servers for the acme.example.com hosted zone.

1. Route 53 responds to the query using a record in the acme.example.com hosted zone.

To configure Route 53 to route traffic for the subdomain using the hosted zone for the subdomain and to delete any duplicate records from the hosted zone for the domain, perform the following procedure:

**To configure Route 53 to use the hosted zone for the subdomain (console)**

1. In the Route 53 console, get the name servers for the hosted zone for the subdomain:

   1. In the navigation pane, choose **Hosted zones**. 

   1. On the **Hosted zones** page, choose the name for the hosted zone for the subdomain.

   1. In the right pane, copy the names of the four servers listed for **Name servers** in the **Hosted zones details** section.

1. Choose the name of the hosted zone for the domain (example.com), not for the subdomain.

1. Choose **Create record**.

1. Choose **Simple routing** and choose **Next**.

1. Choose **Define simple record**.

1. Specify the following values:  
**Name**  
Enter the name of the subdomain (for example, `acme.example.com`). This must match exactly the name of the subdomain hosted zone you created.  
**Value/Route traffic to**  
Choose **IP address or another value depending on the record type**, and paste the names of the name servers that you copied in step 1.  
**Record type**  
Choose **NS – Name servers for a hosted zone**.  
**TTL (Seconds)**  
Change to a more common value for an NS record, such as 172800 seconds.

1. Choose **Define simple record**, and choose **Create records**.

1. If the hosted zone for the domain contains any records that you recreated in the hosted zone for the subdomain, delete those records from the hosted zone for the domain. For more information, see [Deleting records](resource-record-sets-deleting.md).

   When you're finished, all records for the subdomain should be in the hosted zone for the subdomain.

## Routing traffic for additional levels of subdomains
<a name="dns-routing-traffic-for-sub-subdomains"></a>

You route traffic to a subdomain of a subdomain, such as backend.acme.example.com, the same way that you route traffic to a subdomain, such as acme.example.com. Either you create records in the hosted zone for the domain, or you create a hosted zone for the lower-level subdomain, and then you create records in that new hosted zone.

If you choose to create a separate hosted zone for the lower-level subdomain, create the NS record for the lower-level subdomain in the hosted zone for the subdomain that is one level closer to the domain name. This helps to ensure that traffic is correctly routed to your resources. For example, suppose you want to route traffic for the following subdomains:
+ subdomain1.example.com
+ subdomain2.subdomain1.example.com

To use another hosted zone to route traffic for subdomain2.subdomain1.example.com, you do the following:

1. Create a hosted zone named subdomain2.subdomain1.example.com. 

1. Create records in the subdomain2.subdomain1.example.com hosted zone. For more information, see [Creating records in the hosted zone for the subdomain](#dns-routing-traffic-for-subdomains-creating-records).

1. Copy the names of the name servers for the subdomain2.subdomain1.example.com hosted zone. 

1. In the subdomain1.example.com hosted zone, create an NS record named subdomain2.subdomain1.example.com, and paste in the names of the name servers for the subdomain2.subdomain1.example.com hosted zone. 

   In addition, delete any duplicate records from the subdomain1.example.com. For more information, see [Updating the hosted zone for the domain](#dns-routing-traffic-for-subdomains-delegating-responsibility). 

   After you create this NS record, Route 53 starts to use the subdomain2.subdomain1.example.com hosted zone to route traffic for the subdomain2.subdomain1.example.com subdomain.

# Working with hosted zones
<a name="hosted-zones-working-with"></a>

A hosted zone is a container for records, and records contain information about how you want to route traffic for a specific domain, such as example.com, and its subdomains (acme.example.com, zenith.example.com). A hosted zone and the corresponding domain have the same name. There are two types of hosted zones:
+ *Public hosted zones* contain records that specify how you want to route traffic on the internet. For more information, see [Working with public hosted zones](AboutHZWorkingWith.md).
+ *Private hosted zones* contain records that specify how you want to route traffic in an Amazon VPC. For more information, see [Working with private hosted zones](hosted-zones-private.md).

# Working with public hosted zones
<a name="AboutHZWorkingWith"></a>

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
<a name="hosted-zone-public-considerations"></a>

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 name="CreatingHostedZone"></a>

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
<a name="GetInfoAboutHostedZone"></a>

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
<a name="ListInfoOnHostedZone"></a>

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
<a name="hosted-zone-public-viewing-query-metrics"></a>

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
<a name="hosted-zone-public-viewing-query-metrics-console"></a>

To view DNS query metrics for public hosted zones in the CloudWatch console, perform the following procedure.<a name="hosted-zone-public-viewing-query-metrics-console-procedure"></a>

**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
<a name="hosted-zone-public-viewing-query-metrics-cli"></a>

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
<a name="DeleteHostedZone"></a>

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
<a name="delete-public-hosted-zone-stop-routing"></a>

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
<a name="delete-public-hosted-zone-created-by-another-service"></a>

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
<a name="delete-public-hosted-zone-procedure"></a>

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
<a name="dns-test"></a>

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
<a name="dns-test-how-route-53-responds"></a>

You can use the tool to see what response Amazon Route 53 returns in response to a DNS query for a record.<a name="dns-test-how-route-53-responds-procedure"></a>

**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)
<a name="dns-test-simulate-requests"></a>

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.<a name="dns-test-simulate-requests-procedure"></a>

**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
<a name="white-label-name-servers"></a>

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
<a name="white-label-name-servers-create-reusable-delegation-set"></a>

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
<a name="white-label-name-servers-create-hosted-zones"></a>

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
<a name="white-label-name-servers-create-resource-record-sets"></a>

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
<a name="white-label-name-servers-get-ip-addresses"></a>

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
<a name="white-label-name-servers-create-white-label-resource-record-sets"></a>

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
<a name="white-label-name-servers-update-ns-soa-records"></a>

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
<a name="white-label-name-servers-create-glue-records"></a>

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
<a name="white-label-name-servers-monitor-traffic"></a>

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
<a name="white-label-name-servers-change-ttls-back"></a>

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
<a name="white-label-name-servers-contact-recursive-dns-services"></a>

*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
<a name="SOA-NSrecords"></a>

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
<a name="NSrecords"></a>

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
<a name="SOArecords"></a>

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. <a name="get-soa-records-in-route-53-procedure"></a>

**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
<a name="accelerated-recovery"></a>

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
<a name="accelerated-recovery-how-it-works"></a>

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
<a name="accelerated-recovery-resubmit"></a>

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
<a name="accelerated-recovery-api"></a>

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
<a name="accelerated-recovery-cloudformation"></a>

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
<a name="accelerated-recovery-failback"></a>

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
<a name="accelerated-recovery-considerations"></a>

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
<a name="accelerated-recovery-enable"></a>

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
```

# Working with private hosted zones
<a name="hosted-zones-private"></a>

A *private hosted zone* is a container that holds information about how you want Amazon Route 53 to respond to DNS queries for a domain and its subdomains within one or more VPCs that you create with the Amazon VPC service. Here's how private hosted zones work:

1. You create a private hosted zone, such as example.com, and specify the VPC that you want to associate with the hosted zone. After you create the hosted zone you can associate more VPCs with it.

1. You create records in the hosted zone that determine how Route 53 responds to DNS queries for your domain and subdomains within and among your VPCs. For example, suppose you have a database server that runs on an EC2 instance in the VPC that you associated with your private hosted zone. You create an A or AAAA record, such as db.example.com, and you specify the IP address of the database server. 

   For more information about records, see [Working with records](rrsets-working-with.md). For information about the Amazon VPC requirements for using private hosted zones, see [Using private hosted zones](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones) in the *Amazon VPC User Guide*.

1. When an application submits a DNS query for db.example.com, Route 53 returns the corresponding IP address. To get an answer from a private hosted zone you also have to be running an EC2 instance in one of the associated VPCs (or have an inbound endpoint from a hybrid setup.) If you try to query a private hosted zone from outside the VPCs or your hybrid setup, the query will be recursively resolved on the internet.

1. The application uses the IP address that it got from Route 53 to establish a connection with the database server.

When you create a private hosted zone, the following name servers are used:
+ ns-0.awsdns-00.com
+ ns-512.awsdns-00.net
+ ns-1024.awsdns-00.org
+ ns-1536.awsdns-00.co.uk

These name servers are used because the DNS protocol requires that every hosted zone must have an NS record set. These name servers are reserved and never used by Route 53 public hosted zones. You can only query those zones via VPC Resolver in a VPC that has been associated to the hosted zone by using an inbound endpoint connected to the VPCs specified in the private hosted zone.

 While the name servers are visible on the internet, VPC Resolver doesn't connect to the name server addresses. Further, the private hosted zone information is not returned if you directly query the name servers over the internet. Instead, the VPC Resolver detects that queries are within a private namespace based on VPC to hosted zone associations and uses direct, private connectivity to reach the private DNS servers.

**Note**  
You can change the NS record set in a private hosted zone if you want and private DNS resolution will still work. We don't recommend doing so, but if you choose to, you should use reserved domain names which are not used by public DNS servers.

If you want to route traffic for your domain on the internet, you use a Route 53 *public* hosted zone. For more information, see [Working with public hosted zones](AboutHZWorkingWith.md).

**Topics**
+ [

# Considerations when working with a private hosted zone
](hosted-zone-private-considerations.md)
+ [

# Creating a private hosted zone
](hosted-zone-private-creating.md)
+ [

# Listing private hosted zones
](hosted-zone-private-listing.md)
+ [

# Associating more VPCs with a private hosted zone
](hosted-zone-private-associate-vpcs.md)
+ [

# Associating an Amazon VPC and a private hosted zone that you created with different AWS accounts
](hosted-zone-private-associate-vpcs-different-accounts.md)
+ [

# Disassociating VPCs from a private hosted zone
](hosted-zone-private-disassociate-vpcs.md)
+ [

# Deleting a private hosted zone
](hosted-zone-private-deleting.md)
+ [

# VPC permissions
](hosted-zone-private-vpc-permissions.md)

# Considerations when working with a private hosted zone
<a name="hosted-zone-private-considerations"></a>

When using private hosted zones, note the following considerations.
+ [Amazon VPC settings](#hosted-zone-private-considerations-vpc-settings)
+ [Route 53 health checks](#hosted-zone-private-considerations-health-checks)
+ [Supported routing policies for records in a private hosted zone](#hosted-zone-private-considerations-routing-policies)
+ [Split-view DNS](#hosted-zone-private-considerations-split-view-dns)
+ [Public and private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-public-private-overlapping)
+ [Private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-private-overlapping)
+ [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules)
+ [Delegating responsibility for a subdomain](#hosted-zone-private-considerations-delegating-subdomain)
+ [Custom DNS servers](#hosted-zone-private-considerations-custom-dns)
+ [Required IAM permissions](#hosted-zone-private-considerations-required-permissions)

**Amazon VPC settings**  
To use private hosted zones, you must set the following Amazon VPC settings to `true`:  
+ `enableDnsHostnames`
+ `enableDnsSupport`
For more information, see [View and update DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns-updating.html) in the *Amazon VPC User Guide*.

**Route 53 health checks**  
In a private hosted zone, you can associate Route 53 health checks only with failover, multivalue answer, weighted, latency, geolocation, and geoproximity records records. For information about associating health checks with failover records, see [Configuring failover in a private hosted zone](dns-failover-private-hosted-zones.md).

**Supported routing policies for records in a private hosted zone**  
You can use the following routing policies when you create records in a private hosted zone:  
+ [Simple routing](routing-policy-simple.md)
+ [Failover routing](routing-policy-failover.md)
+ [Multivalue answer routing](routing-policy-multivalue.md)
+ [Weighted routing](routing-policy-weighted.md)
+ [Latency-based routing](routing-policy-latency.md)
+ [Geolocation routing](routing-policy-geo.md)
+ [Geoproximity routing](routing-policy-geoproximity.md)
Creating records in a private hosted zone using other routing policies is not supported.

**Split-view DNS**  
You can use Route 53 to configure split-view DNS, also known as split-horizon DNS. In split-view DNS, you use the same domain name (example.com) for internal uses (accounting.example.com) and external uses, such as your public website (www.example.com). You might also want to use the same subdomain name internally and externally, but serve different content or require different authentication for internal and external users.  
To configure split-view DNS, you perform the following steps:  

1. Create public and private hosted zones that have the same name. (Split-view DNS still works if you're using another DNS service for the public hosted zone.)

1. Associate one or more Amazon VPCs with the private hosted zone. Route 53 VPC Resolver uses the private hosted zone to route DNS queries in the specified VPCs.

1. Create records in each hosted zone. Records in the public hosted zone control how internet traffic is routed, and records in the private hosted zone control how traffic is routed in your Amazon VPCs.
If you need to perform name resolution of both your VPC and on-premises workloads, you can use Route 53 VPC Resolver. For more information, see [What is Route 53 VPC Resolver?](resolver.md).

**Public and private hosted zones that have overlapping namespaces**  
If you have private and public hosted zones that have overlapping namespaces, such as example.com and accounting.example.com, VPC Resolver routes traffic based on the most specific match. When users are logged into an EC2 instance in an Amazon VPC that you have associated with the private hosted zone, here's how Route 53 VPC Resolver handles DNS queries:  

1. VPC Resolver evaluates whether the name of the private hosted zone matches the domain name in the request, such as accounting.example.com. A match is defined as either of the following:
   + An identical match
   + The name of the private hosted zone is a parent of the domain name in the request. For example, suppose the domain name in the request is the following:

     **seattle.accounting.example.com**

     The following hosted zones match because they're parents of seattle.accounting.example.com:
     + **accounting.example.com**
     + **example.com**

   If there's no matching private hosted zone, then VPC Resolver forwards the request to a public DNS resolver, and your request is resolved as a regular DNS query.

1. If there's a private hosted zone name that matches the domain name in the request, the hosted zone is searched for a record that matches the domain name and DNS type in the request, such as an A record for accounting.example.com.
**Note**  
If there's a matching private hosted zone but there's no record that matches the domain name and type in the request, VPC Resolver doesn't forward the request to a public DNS resolver. Instead, it returns NXDOMAIN (non-existent domain) to the client.

**Private hosted zones that have overlapping namespaces**  
If you have two or more private hosted zones that have overlapping namespaces, such as example.com and accounting.example.com, VPC Resolver routes traffic based on the most specific match.   
If you have a private hosted zone (example.com) and a Route 53 VPC Resolver rule that routes traffic to your network for the same domain name, the VPC Resolver rule takes precedence. See [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules).
When users are logged into an EC2 instance in an Amazon VPC that you have associated with all of the private hosted zones, here's how VPC Resolver handles DNS queries:  

1. VPC Resolver evaluates whether the domain name in the request, such as accounting.example.com, matches the name of one of the private hosted zones.

1. If there is no hosted zone that exactly matches the domain name in the request, VPC Resolver checks for a hosted zone that has a name that is the parent of the domain name in the request. For example, suppose the domain name in the request is the following:

   `seattle.accounting.example.com`

   The following hosted zones match because they're parents of `seattle.accounting.example.com`:
   + `accounting.example.com`
   + `example.com`

   VPC Resolver chooses `accounting.example.com` because it's more specific than `example.com`.

1. VPC Resolver searches the `accounting.example.com` hosted zone for a record that matches the domain name and DNS type in the request, such as an A record for `seattle.accounting.example.com`.

   If there's no record that matches the domain name and type in the request, VPC Resolver returns NXDOMAIN (non-existent domain) to the client.

**Private hosted zones and Route 53 VPC Resolver rules**  
If you have a private hosted zone (example.com) and a VPC Resolver rule that routes traffic to your network for the same domain name, the VPC Resolver rule takes precedence.   
For example, suppose you have the following configuration:  
+ You have a private hosted zone called example.com, and you associate it with a VPC.
+ You create a Route 53 VPC Resolver rule that forwards traffic for example.com to your network, and you associate the rule with the same VPC.
In this configuration, the VPC Resolver rule takes precedence over the private hosted zone. DNS queries are forwarded to your network instead of being resolved based on the records in the private hosted zone.

**Delegating responsibility for a subdomain**  
You can now create NS records in a private hosted zone to delegate responsibility for a subdomain. For more information, see [Resolver delegation rules tutorial](outbound-delegation-tutorial.md).

**Custom DNS servers**  
If you have configured custom DNS servers on Amazon EC2 instances in your VPC, you must configure those DNS servers to route your private DNS queries to the IP address of the Amazon-provided DNS servers for your VPC. This IP address is the IP address at the base of the VPC network range "plus two." For example, if the CIDR range for your VPC is 10.0.0.0/16, the IP address of the DNS server is 10.0.0.2.  
If you want to route DNS queries between VPCs and your network, you can use VPC Resolver. For more information, see [What is Route 53 VPC Resolver?](resolver.md).

**Required IAM permissions**  
To create private hosted zones, you need to grant IAM permissions for Amazon EC2 actions in addition to permissions for Route 53 actions. For more information, see [Actions, resources, and condition keys for Route 53](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html) in the *Service Authorization Reference*.

# Creating a private hosted zone
<a name="hosted-zone-private-creating"></a>

A private hosted zone is a container for records for a domain that you host in one or more Amazon virtual private clouds (VPCs). You create a hosted zone for a domain (such as example.com), and then you create records to tell Amazon Route 53 how you want traffic to be routed for that domain within and among your VPCs.

**Important**  
When you create a private hosted zone, you must associate a VPC with the hosted zone, and the VPC that you specify must have been created by using the same account that you're using to create the hosted zone. After you create the hosted zone, you can associate additional VPCs with it, including VPCs that you created by using a different AWS account.  
To associate VPCs that you created by using one account with a private hosted zone that you created by using a different account, you must authorize the association and then make the association programmatically. For more information, see [Associating an Amazon VPC and a private hosted zone that you created with different AWS accounts](hosted-zone-private-associate-vpcs-different-accounts.md).

For information about creating a private hosted zone by using the Route 53 API, see the [Amazon Route 53 API Reference](https://docs.aws.amazon.com/Route53/latest/APIReference/).

**To create a private hosted zone using the Route 53 console**

1. For each VPC that you want to associate with the Route 53 hosted zone, change the following VPC settings to `true`:
   + `enableDnsHostnames`
   + `enableDnsSupport`

   For more information, see [Updating DNS support for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) in the *Amazon VPC User Guide*.

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**

   If you're already using Route 53, choose **Hosted zones** in the navigation pane.

1. Choose **Create hosted zone**.

1. In the **Create private hosted zone** pane, enter a domain name and, optionally, 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. In the **Type** list, choose **Private hosted zone**.

1. In the **VPC ID** list, choose the VPC that you want to associate with the hosted zone.
**Note**  
If the console displays the following message, you're trying to associate a hosted zone that uses the same name space as that of another hosted zone within the same VPC:  
"A conflicting domain is already associated with the given VPC or Delegation Set."  
For example, if hosted zone A and hosted zone B both have the same domain name, such as `example.com`, you can't associate both hosted zones with the same VPC.

1. Choose **Create hosted zone**.

# Listing private hosted zones
<a name="hosted-zone-private-listing"></a>

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 hosted zones associated with an AWS account**

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 **Hosted Zones** page automatically displays a list of all of the hosted zones that were created using the current AWS account. The **Type** column indicates whether a hosted zone is private or public. Choose the column heading to group all private hosted zones and all public hosted zones.

# Associating more VPCs with a private hosted zone
<a name="hosted-zone-private-associate-vpcs"></a>

You can use the Amazon Route 53 console to associate more VPCs with a private hosted zone if you created the hosted zone and the VPCs by using the same AWS account.

**Important**  
If you want to associate VPCs that you created by using one account with a private hosted zone that you created by using a different account, you first must authorize the association. In addition, you can't use the AWS console either to authorize the association or associate the VPCs with the hosted zone. For more information, see [Associating an Amazon VPC and a private hosted zone that you created with different AWS accounts](hosted-zone-private-associate-vpcs-different-accounts.md).

For information about how to associate more VPCs with a private hosted zone using the Route 53 API, see [AssociateVPCWithHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html) in the *Amazon Route 53 API Reference*.

**To associate additional VPCs with a private 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**.

1. Choose the radio button for the private hosted zone that you want to associate more VPCs with.

1. Choose **Edit**.

1. Choose **Add VPC**.

1. Choose the Region and the ID of the VPC that you want to associate with this hosted zone.

1. To associate more VPCs with this hosted zone, repeat steps 5 and 6.

1. Choose **Save changes**.

# Associating an Amazon VPC and a private hosted zone that you created with different AWS accounts
<a name="hosted-zone-private-associate-vpcs-different-accounts"></a>

If you want to associate a VPC that you created with one AWS account with a private hosted zone that you created with a different account, perform the following procedure: 

**To associate an Amazon VPC and a private hosted zone that you created with different AWS accounts**

1. Using the account that created the hosted zone, authorize the association of the VPC with the private hosted zone by using one of the following methods:
   + **AWS CLI** – See [create-vpc-association-authorization](https://docs.aws.amazon.com/cli/latest/reference/route53/create-vpc-association-authorization.html) in the *AWS CLI Command Reference*
   + ** AWSSDK** or **AWS Tools for Windows PowerShell** – See the applicable documentation on the [AWSDocumentation](https://docs.aws.amazon.com/) page 
   + **Amazon Route 53 API** – See [CreateVPCAssociationAuthorization](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html) in the *Amazon Route 53 API Reference*

   Note the following:
   + If you want to associate multiple VPCs that you created with one account with a hosted zone that you created with a different account, you must submit one authorization request for each VPC.
   + When you authorize the association, you must specify the hosted zone ID, so the private hosted zone must already exist.
   + You can't use the Route 53 console either to authorize the association of a VPC with a private hosted zone or to make the association.

1. Using the account that created the VPC, associate the VPC with the hosted zone. As with authorizing the association, you can use the AWS SDK, Tools for Windows PowerShell, the AWS CLI, or the Route 53 API. If you're using the API, use the [AssociateVPCWithHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html) action. 

1. *Recommended* – Delete the authorization to associate the VPC with the hosted zone. Deleting the authorization does not affect the association, it just prevents you from reassociating the VPC with the hosted zone in the future. If you want to reassociate the VPC with the hosted zone, you'll need to repeat steps 1 and 2 of this procedure.
**Important**  
The `ListHostedZonesByVPC` returns the hosted zones given a VPC and `GetHostedZone` API returns the VPCs associated to the hosted zone. These APIs only consider the hosted zone to VPC association that are created by `AssociateVPCWithHostedZone` API or when the private hosted zone is created. If you want a complete list of hosted zone associations to a VPC, also call [ListProfileResourceAssociations](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53profiles_ListProfileResourceAssociations.html).
**Note**  
For the maximum number of authorizations that you can create, see [Quotas on entities](DNSLimitations.md#limits-api-entities).

# Disassociating VPCs from a private hosted zone
<a name="hosted-zone-private-disassociate-vpcs"></a>

You can use the Amazon Route 53 console to disassociate VPCs from a private hosted zone. This causes Route 53 to stop routing traffic using records in the hosted zone for DNS queries that originate in the VPC. For example, if the example.com hosted zone is associated with a VPC and you disassociate the hosted zone from that VPC, Route 53 stops resolving DNS queries for example.com or any of the other records in the example.com hosted zone. 

**Note**  
You can't disassociate the last VPC from a private hosted zone. If you want to disassociate that VPC, you must first associate another VPC with the hosted zone.

**To disassociate VPCs from a private 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, choose **Hosted zones**.

1. Choose the radio button for the private hosted zone that you want to disassociate one or more VPCs from.

1. Choose **Edit**.

1. Choose **Remove VPC** next to the VPC that you want to disassociate from this hosted zone.

1. Choose **Save changes**.

# Deleting a private hosted zone
<a name="hosted-zone-private-deleting"></a>

This section explains how to delete a private hosted zone using the Amazon Route 53 console.

You can delete a private 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**
+ [

## Deleting private hosted zones that were created by another service
](#delete-private-hosted-zone-created-by-another-service)
+ [

## Using the Route 53 console to delete a private hosted zone
](#delete-private-hosted-zone-procedure)

## Deleting private hosted zones that were created by another service
<a name="delete-private-hosted-zone-created-by-another-service"></a>

If a private 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 private 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 private 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 private hosted zone
<a name="delete-private-hosted-zone-procedure"></a>

To use the Route 53 console to delete a private hosted zone, perform the following procedure.

**To delete a private 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. 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:

   1. Choose the name of the hosted zone that you want to delete.

   1. On the **Record** page, 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. 

1. On the Hosted Zones page, choose the row for the hosted zone that you want to delete.

1. Choose **Delete**.

1. Type the confirmation key and choose **Delete**.

# VPC permissions
<a name="hosted-zone-private-vpc-permissions"></a>

VPC permissions use Identity and Access management (IAM) policy condition to allow you to set granular permissions for VPCs when using [AssociateVPCWithHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html), [DisassociateVPCFromHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisassociateVPCFromHostedZone.html), [CreateVPCAssociationAuthorization](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html), [DeleteVPCAssociationAuthorization](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteVPCAssociationAuthorization.html), [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html), and [ListHostedZonesByVPC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZonesByVPC.html) APIs.

With the IAM policy condition, `route53:VPCs`, you can grant granular administrative rights to other AWS users. This allows you to grant someone permissions to associate hosted zone with, disassociate hosted zone from, create VPC association authorization for, delete VPC association authorization for, create hosted zone with or list hosted zones for:
+ A single VPC.
+ Any VPCs within the same Region.
+ Multiple VPCs.

For more information about VPC permissions, see [Using IAM policy conditions for fine-grained access control](specifying-conditions-route53.md).

To learn how to authenticate AWS users, see [Authenticating with identities](security-iam.md#security_iam_authentication) and to learn how to control access to Route 53 resources, see [Access control](security-iam.md#access-control).

# Migrating a hosted zone to a different AWS account
<a name="hosted-zones-migrating"></a>

When migrating a hosted zone to a different AWS account, follow these recommended steps.

These steps are most suitable for hosted zones with infrequent record changes. For hosted zones with frequent record updates, consider the following: 
+ Don't update any resource records during migration.
+ Publish resource record changes in both old and new hosted zones after the delegation has been transferred.

**Prerequisites**  
Install or upgrade the AWS CLI:

For information about downloading, installing, and configuring the AWS CLI, see the [AWS Command Line Interface User Guide](https://docs.aws.amazon.com/cli/latest/userguide/).

**Note**  
Configure the CLI so that you can use it when you're using both the account that created the hosted zone and the account that you're migrating the hosted zone to. For more information, see [Configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) in the *AWS Command Line Interface User Guide*

If you're already using the AWS CLI, we recommend that you upgrade to the latest version of the CLI so that the CLI commands support the latest Route 53 features.

**Topics**
+ [

## Step 1: Prepare for migration
](#hosted-zones-migrating-prepare)
+ [

## Step 2: Create the new hosted zone
](#hosted-zones-migrating-create-hosted-zone)
+ [

## Step 3: (Optional) Migrate health checks
](#hosted-zones-migrating-health-checks)
+ [

## Step 4: Migrate records from the old hosted zone to the new hosted zone
](#hosted-zones-migrating-old-to-new)
+ [

## Step 5: Compare records in the old and new hosted zones
](#hosted-zones-migrating-compare)
+ [

## Step 6: Update the domain registration to use name servers for the new hosted zone
](#hosted-zones-migrating-update-domain)
+ [

## Step 7: Change the TTL for the NS record back to a higher value
](#hosted-zones-migrating-change-ttl)
+ [

## Step 8: Re-enable DNSSEC signing and establish the chain of trust (if required)
](#hosted-zones-migrating-enable-dnssec)
+ [

## Step 9: (Optional) delete the old hosted zone
](#hosted-zones-migrating-delete-old-hosted-zone)

## Step 1: Prepare for migration
<a name="hosted-zones-migrating-prepare"></a>

The preparation steps help you minimize the risks associated with migrating a hosted zone.

**1. Monitor zone availability**  
You can monitor the zone for the availability of your domain names. This can help you address any issues that might lead to rolling back the migration. You can monitor for your domain names with most traffic by using CloudWatch or query logging. For more information about setting up query logging, see [Monitoring Amazon Route 53](monitoring-overview.md).

The monitoring can be done through a shell script, or through a third party service. It shouldn't, however, be the only signal to determine if a rollback is required as you might also get feedback from your customers due to a domain not being available.

**2. Lower the TTL setting**  
The TTL (time to live) setting for a record specifies how long you want DNS resolvers to cache the record and use the cached information. When the TTL expires, a resolver sends another query to the DNS service provider for a domain to get the latest information.

The typical TTL setting for the NS record is 172800 seconds, or two days. The NS record lists the name servers that the Domain Name System (DNS) can use to get information about how to route traffic for your domain. Lowering the TTL for the NS record, both with your current DNS service provider and with Route 53, reduces downtime for your domain if you discover a problem while you're migrating DNS to Route 53. If you don't lower the TTL, your domain could be unavailable on the internet for up to two days if something goes wrong.

**To lower the TTL**

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. Choose **Hosted zones** in the navigation pane.

1. Choose the name of the hosted zone.

1. Choose the NS record, and and in the **Record details** pane, choose **Edit record**.

1. Change the value of **TTL (Seconds)**. We recommend that you specify a value between 60 seconds and 900 seconds (15 minutes).

1. Choose **Save**.

**3. Remove the DS record from the parent zone (If you have DNSSEC configured)**  
If you've configured DNSSEC for your domain, remove the Delegation Signer (DS) record from the parent zone before you migrate your domain to Route 53.

If the parent zone is hosted through Route 53, see [Deleting public keys for a domain](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys) for more information. If the parent zone is hosted on another registrar, contact them to remove the DS record.

Route 53 does not currently support migrating the DNSSEC setting. As such, you will need to disable DNSSEC validation performed against your domain prior to the migration by removing the DS record from the parent zone. After the migration, you can re-enable DNSSEC validation by configuring DNSSEC on the new hosted zone and adding the respective DS record to the parent zone.

**4. Make sure there are no other ongoing operations relying on the migrating hosted zone**  
Some operations will rely on DNS resolution in the migrating hosted zone, for example, the TLS/SSL certificate renewal process may require making DNS record changes and the provider will try to resolve the DNS record as the validation method. Before the migration, you should make sure there is no other operation happening, in order to avoid unexpected impact from the hosted zone migration.

## Step 2: Create the new hosted zone
<a name="hosted-zones-migrating-create-hosted-zone"></a>

Create the new hosted zone in the account you want to migrate the hosted zone to.

Choose the tab for the instructions for either the AWS CLI or console.
+ [CLI](#migrate-hz-cli)
+ [Console](#migrate-hz-console)

------
#### [ CLI ]

Enter the following command:

```
aws route53 create-hosted-zone \ 
            --name $hosted_zone_name \ 
            --caller-reference $unique_string
```

For more information, see [create-hosted-zone](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/route53/create-hosted-zone.html).

------
#### [ Console ]<a name="hosted-zones-migrating-create-hosted-zone-procedure"></a>

**To create the new hosted zone using a different account**

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/).

   Sign in with the account credentials for the account that you want to migrate the hosted zone to.

1. Create a hosted zone. For more information, see [Creating a public hosted zone](CreatingHostedZone.md).

1. Make note of the hosted zone ID. In some cases, you'll need this information later in the process.

1. Log out of the Route 53 console.

Lower the NS TTL in the new zone as well, similar to Lower TTL setting in preparation Step 1, Lower the TTL setting.

------

## Step 3: (Optional) Migrate health checks
<a name="hosted-zones-migrating-health-checks"></a>

You can associate DNS records in the new account with Route 53 health checks from the account you're migrating from. To migrate a Route 53 health check, you need to create new health checks in your new account with the same configuration as your existing ones. For more information, see [Creating Amazon Route 53 health checks](dns-failover.md).

## Step 4: Migrate records from the old hosted zone to the new hosted zone
<a name="hosted-zones-migrating-old-to-new"></a>

You can migrate records from an AWS account to another by using the console or the AWS CLI.

------
#### [ Console ]

If your zone contains just a few records, you can consider to use Route 53 console to list the records in your old zone, note them down, and create them in the new zone. If you have migrated the health check in [Step 3: (Optional) Migrate health checks](#hosted-zones-migrating-health-checks), when you create the records in the new hosted zone, you should specify the new health check ID. For more information, see the following topics:
+ [Listing records](resource-record-sets-listing.md)
+ [Creating records by using the Amazon Route 53 console](resource-record-sets-creating.md)
+ [Configuring DNS failover](dns-failover-configuring.md)

You should lower the NS TTL in the new zone as well, similar to Lower TTL setting in Step 1.

------
#### [ CLI ]

If your zone contains a large number of records, you can export the records you want to migrate to a file, edit the file, and then use the edited file to create records in the new hosted zone. The following procedure uses AWS CLI commands, though third-party tools are also available for this purpose.<a name="hosted-zones-migrating-create-file-procedure"></a>

****

1. Run the following command: 

   ```
   aws route53 list-resource-record-sets --hosted-zone-id hosted-zone-id > path-to-output-file
   ```

   Note the following:
   + For *hosted-zone-id*, specify the ID of the old hosted zone that contains the records you want to migrate. 
   + For *path-to-output-file*, specify the directory path and file name that you want to save the output in. 
   + The `>` character sends the output to the specified file.
   + The AWS CLI automatically handles pagination for hosted zones that contain more than 100 records. For more information, see [Using the AWS Command Line Interface's pagination options](https://docs.aws.amazon.com/cli/latest/userguide/pagination.html) in the *AWS Command Line Interface User Guide*. 

     If you use another programmatic method to list records, such as one of the AWS SDKs, you can get a maximum of 100 records per page of results. If the hosted zone contains more than 100 records, you must submit multiple requests to list all records.

   Make a copy of this output. After you create records in the new hosted zone, we recommend that you run the AWS CLI `list-resource-record-sets` command on the new hosted zone and compare the two outputs to ensure that all the records were created.

1. Edit the records that you want to migrate.

   Edit the exported file before you can use it with the `change-resource-record-sets` command. You can make these changes using the search and replace function in a text editor. 
**Note**  
The following steps describe manual editing using a text editor. Advanced users can automate these transformations using programmatic tools such as jq, Python, or other scripting languages.

   Open a copy of the file that you created in step 1 of this procedure that contains the records that you want to migrate, and make the following changes:
   + Replace the ResourceRecordSets element at the top of the file with `Changes` element.
   + Optional – add a `Comment` element.
   + Delete the lines related to the NS and SOA records of the hosted zone name. The new hosted zone already has those records.
   + For each record, add an `Action` and a `ResourceRecordSets` element, add opening and closing brackets ( `{ }` ) as required to make the JSON code valid.
**Note**  
You can use a JSON validator to verify that you have all the braces and brackets in the correct places. To find an online JSON validator, search "JSON validator" in your browser.
   + If the hosted zone contains any aliases that refer to other records in the same hosted zone, make the following changes:
     + Change the hosted zone ID to the ID of the new hosted zone.
**Important**  
If the alias record is pointing to another resource, for example, a load balancer, do not change the hosted zone ID to the hosted zone ID of the domain. If you change the hosted zone ID accidentally, rollback the hosted zone ID to the hosted zone id of the resource itself, not the hosted zone ID of the domain. The resource hosted zone ID can be found in the AWS console where the resource was created.
     + Move the alias records to the bottom of the file. Route 53 must create the record that an alias record refers to before it can create the alias record.
**Important**  
If one or more alias records refer to other alias records, the records that are the alias target must appear in the file before the referencing alias records. For example, if `alias.example.com` is the alias target for `alias.alias.example.com`, `alias.example.com` must appear first in the file.
     + Delete any alias records that route traffic to a traffic policy instance. Make note of the records so you can recreate them later.
   + If you migrated health checks in [Step 3: (Optional) Migrate health checks](#hosted-zones-migrating-health-checks), change the records to associate with the newly created health check IDs.

   The following example shows the edited version of records for a hosted zone for example.com. The red, italicized text is new:

   ```
   {
       "Comment": "string",
       "Changes": [
           {
               "Action": "CREATE",
               "ResourceRecordSet":{
                   "ResourceRecords": [
                       {
                           "Value": "192.0.2.4"
                       }, 
                       {
                           "Value": "192.0.2.5"
                       }, 
                       {
                           "Value": "192.0.2.6"
                       }
                   ], 
                   "Type": "A", 
                   "Name": "route53documentation.com.", 
                   "TTL": 300
               }
           },
           {
               "Action": "CREATE",
               "ResourceRecordSet":{
                   "AliasTarget": {
                       "HostedZoneId": "Z3BJ6K6RIION7M",
                       "EvaluateTargetHealth": false,
                       "DNSName": "s3-website-us-west-2.amazonaws.com."
                   },
                   "Type": "A",
                   "Name": "www.route53documentation.com."
               }
           }
       ]
   }
   ```

1. Split large files into smaller files

   If you have a lot of records or if you have records that have a lot of values (for example, a lot of IP addresses), you might need to split the file into smaller files. The max values are:
   + Each file can contain a maximum of 1,000 records.
   + The maximum combined length of the values in all `Value` elements is 32,000 bytes.

1. Create records in the new hosted zone

   Enter the following CLI:

   ```
   aws route53 change-resource-record-sets \
               --hosted-zone-id new-hosted-zone-id \
               --change-batch file://path-to-file-that-contains-records
   ```

   Specify the following values:
   + For `new-hosted-zone-id`, specify the ID of the new hosted zone.
   + For `path-to-file-that-contains-records`, specify the directory path and file name that you edited in the previous steps.

   If you deleted any alias records that route traffic to a traffic policy instance, recreate them using the Route 53 console. For more information, see [Creating records by using the Amazon Route 53 console](resource-record-sets-creating.md).

------

## Step 5: Compare records in the old and new hosted zones
<a name="hosted-zones-migrating-compare"></a>

To confirm that you successfully created all of your records in the new hosted zone, enter the following CLI command to list the records in the new hosted zone and compare the output with the list of records from the old hosted zone. 

```
aws route53 list-resource-record-sets \
            --hosted-zone-id new-hosted-zone-id \
            --output json > path-to-output-file
```

Specify the following values:
+ For `new-hosted-zone-id`, specify the ID of the new hosted zone.
+ For `path-to-output-file`, specify the directory path and file name that you want to save the output in. Use a file name that is different from the file name that you used in Step 4.

  The `>` character sends the output to the specified file.

Compare the output with the output from Step 4. Other than the values of the NS and SOA records and any changes that you made in Step 4 (such as different hosted zone IDs or domain names), the two outputs should be identical.

If the records in the new hosted zone don't match the records in the old hosted zone, do one of the following:
+ Make minor corrections using the Route 53 console. For more information, see [Editing records](resource-record-sets-editing.md).
+ Delete all the records except the NS and SOA records in the new hosted zone, and repeat the procedure in Step 4.

## Step 6: Update the domain registration to use name servers for the new hosted zone
<a name="hosted-zones-migrating-update-domain"></a>

When you finish migrating the records to the new hosted zone, change the name servers for the domain registration to use the name servers for the new hosted zone. For more information, see Making Amazon Route 53 the DNS service for an existing domain.

If your hosted zone is in use - for example, if your users are using the domain name to browse to a website or access a web application - you should continue monitoring traffic and availability of the hosted zone, including website or application traffic, email, etc. 
+ **If the traffic slows or stops** – Change the name service for the domain registration back to the previous name servers of the old hosted zone. Then determine what went wrong.
+ **If the traffic is unaffected** – Continue to the next step.

## Step 7: Change the TTL for the NS record back to a higher value
<a name="hosted-zones-migrating-change-ttl"></a>

In the new hosted zone, change the TTL for the NS record to a more typical value, for example, 172800 seconds (two days). This improves latency for your users because they don't have to wait as often for DNS resolvers to send a query for the name servers for your domain.<a name="change-ttl-back-procedure"></a>

**To change the TTL**

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. Choose **Hosted zones** in the navigation pane.

1. Choose the name of the hosted zone.

1. Choose the NS record, and and in the **Record details** pane, choose **Edit record**.

1. Change the value of **TTL (Seconds)** to the number of seconds that you want DNS resolvers to cache the names of the name servers for your domain. We recommend a value of 172800 seconds. 

1. Choose **Save**.

## Step 8: Re-enable DNSSEC signing and establish the chain of trust (if required)
<a name="hosted-zones-migrating-enable-dnssec"></a>

You can re-enable DNSSEC signing in two steps: 

1.  Enable DNSSEC signing for Route 53, and request that Route 53 create a key signing key (KSK) based on a customer managed key in AWS Key Management Service.

1. Create a chain of trust for the hosted zone by adding a Delegation Signer (DS) record to the parent zone, so DNS responses can be authenticated with trusted cryptographic signatures.

For instructions, see [Enabling DNSSEC signing and establishing a chain of trust](dns-configuring-dnssec-enable-signing.md).

## Step 9: (Optional) delete the old hosted zone
<a name="hosted-zones-migrating-delete-old-hosted-zone"></a>

When you're confident that you don't need the old hosted zone any longer, you can optionally delete it. For instructions, see [Deleting a public hosted zone](DeleteHostedZone.md).

**Important**  
Don't delete the old hosted zone or any records in that hosted zone for at least 48 hours after you update the domain registration to use name servers for the new hosted zone. If you delete the old hosted zone before DNS resolvers stop using the records in that hosted zone, your domain could be unavailable on the internet until resolvers start using the new hosted zone.

# Working with records
<a name="rrsets-working-with"></a>

After you create a hosted zone for your domain, such as example.com, you create records to tell the Domain Name System (DNS) how you want traffic to be routed for that domain.

For example, you might create records that cause DNS to do the following:
+ Route internet traffic for example.com to the IP address of a host in your data center.
+ Route email for that domain (ichiro@example.com) to a mail server (mail.example.com).
+ Route traffic for a subdomain called operations.tokyo.example.com to the IP address of a different host. 

Each record includes the name of a domain or a subdomain, a record type (for example, a record with a type of MX routes email), and other information applicable to the record type (for MX records, the host name of one or more mail servers and a priority for each server). For information about the different record types, see [Supported DNS record types](ResourceRecordTypes.md).

The name of each record in a hosted zone must end with the name of the hosted zone. For example, the example.com hosted zone can contain records for www.example.com and accounting.tokyo.example.com subdomains, but cannot contain records for a www.example.ca subdomain. 

**Note**  
To create records for complex routing configurations, you can also use the Traffic Flow visual editor and save the configuration as a traffic policy. You can then associate the traffic policy with one or more domain names (such as example.com) or subdomain names (such as www.example.com), in the same hosted zone or in multiple hosted zones. In addition, you can roll back the updates if the new configuration isn't performing as you expected it to. For more information, see [Using Traffic Flow to route DNS traffic](traffic-flow.md).

Amazon Route 53 doesn't charge for the records that you add to a hosted zone. For information about the maximum number of records that you can create in a hosted zone, see [Quotas](DNSLimitations.md). 

**Topics**
+ [

# Choosing a routing policy
](routing-policy.md)
+ [

# Choosing between alias and non-alias records
](resource-record-sets-choosing-alias-non-alias.md)
+ [

# Supported DNS record types
](ResourceRecordTypes.md)
+ [

# Creating records by using the Amazon Route 53 console
](resource-record-sets-creating.md)
+ [

# Resource record set permissions
](resource-record-sets-permissions.md)
+ [

# Values that you specify when you create or edit Amazon Route 53 records
](resource-record-sets-values.md)
+ [

# Creating records by importing a zone file
](resource-record-sets-creating-import.md)
+ [

# Editing records
](resource-record-sets-editing.md)
+ [

# Deleting records
](resource-record-sets-deleting.md)
+ [

# Listing records
](resource-record-sets-listing.md)

# Choosing a routing policy
<a name="routing-policy"></a>

When you create a record, you choose a routing policy, which determines how Amazon Route 53 responds to queries: 
+ **Simple routing policy** – Use for a single resource that performs a given function for your domain, for example, a web server that serves content for the example.com website. You can use simple routing to create records in a private hosted zone.
+ **Failover routing policy** – Use when you want to configure active-passive failover. You can use failover routing to create records in a private hosted zone.
+ **Geolocation routing policy** – Use when you want to route traffic based on the location of your users. You can use geolocation routing to create records in a private hosted zone.
+ **Geoproximity routing policy** – Use when you want to route traffic based on the location of your resources and, optionally, shift traffic from resources in one location to resources in another location. You can use geoproximity routing to create records in a private hosted zone.
+ **Latency routing policy** – Use when you have resources in multiple AWS Regions and you want to route traffic to the Region that provides the best latency. You can use latency routing to create records in a private hosted zone.
+ **IP-based routing policy** – Use when you want to route traffic based on the location of your users, and have the IP addresses that the traffic originates from.
+ **Multivalue answer routing policy** – Use when you want Route 53 to respond to DNS queries with up to eight healthy records selected at random. You can use multivalue answer routing to create records in a private hosted zone.
+ **Weighted routing policy** – Use to route traffic to multiple resources in proportions that you specify. You can use weighted routing to create records in a private hosted zone.

**Topics**
+ [

# Simple routing
](routing-policy-simple.md)
+ [

# Failover routing
](routing-policy-failover.md)
+ [

# Geolocation routing
](routing-policy-geo.md)
+ [

# Geoproximity routing
](routing-policy-geoproximity.md)
+ [

# Latency-based routing
](routing-policy-latency.md)
+ [

# IP-based routing
](routing-policy-ipbased.md)
+ [

# Multivalue answer routing
](routing-policy-multivalue.md)
+ [

# Weighted routing
](routing-policy-weighted.md)
+ [

# How Amazon Route 53 uses EDNS0 to estimate the location of a user
](routing-policy-edns0.md)

# Simple routing
<a name="routing-policy-simple"></a>

Simple routing lets you configure standard DNS records, with no special Route 53 routing such as weighted or latency. With simple routing, you typically route traffic to a single resource, for example, to a web server for your website. 

You can use simple routing policy for records in a private hosted zone.

If you choose the simple routing policy in the Route 53 console, you can't create multiple records that have the same name and type, but you can specify multiple values in the same record, such as multiple IP addresses. (If you choose the simple routing policy for an alias record, you can specify only one AWS resource or one record in the current hosted zone.) If you specify multiple values in a record, Route 53 returns all values to the recursive resolver in random order, and the resolver returns the values to the client (such as a web browser) that submitted the DNS query. The client then chooses a value and resubmits the query. With simple routing policy, although you can specify multiple IP addresses, these IP addresses are not health checked.

For information about values that you specify when you use the simple routing policy to create records, see the following topics:
+ [Values specific for simple records](resource-record-sets-values-basic.md)
+ [Values specific for simple alias records](resource-record-sets-values-alias.md)
+ [Values that are common for all routing policies](resource-record-sets-values-shared.md)
+ [Values that are common for alias records for all routing policies](resource-record-sets-values-alias-common.md)

# Failover routing
<a name="routing-policy-failover"></a>

Failover routing lets you route traffic to a resource when the resource is healthy or to a different resource when the first resource is unhealthy. The primary and secondary records can route traffic to anything from an Amazon S3 bucket that is configured as a website to a complex tree of records. For more information, see [Active-passive failover](dns-failover-types.md#dns-failover-types-active-passive).

You can use failover routing policy for records in a private hosted zone.

For information about values that you specify when you use the failover routing policy to create records, see the following topics:
+ [Values specific for failover records](resource-record-sets-values-failover.md)
+ [Values specific for failover alias records](resource-record-sets-values-failover-alias.md)
+ [Values that are common for all routing policies](resource-record-sets-values-shared.md)
+ [Values that are common for alias records for all routing policies](resource-record-sets-values-alias-common.md)

# Geolocation routing
<a name="routing-policy-geo"></a>

Geolocation routing lets you choose the resources that serve your traffic based on the geographic location of your users, meaning the location that DNS queries originate from. For example, you might want all queries from Europe to be routed to an Elastic Load Balancing load balancer in the Frankfurt Region. 

When you use geolocation routing, you can localize your content and present some or all of your website in the language of your users. You can also use geolocation routing to restrict distribution of content to only the locations in which you have distribution rights. Another possible use is for balancing load across endpoints in a predictable, easy-to-manage way, so that each user location is consistently routed to the same endpoint. 

You can specify geographic locations by continent, by country, or by state in the United States. If you create separate records for overlapping geographic regions—for example, one record for North America and one for Canada—priority goes to the smallest geographic region. This allows you to route some queries for a continent to one resource and to route queries for selected countries on that continent to a different resource. (For a list of the countries on each continent, see [Location](resource-record-sets-values-geo.md#rrsets-values-geo-location).)

Geolocation works by mapping IP addresses to locations. However, some IP addresses aren't mapped to geographic locations, so even if you create geolocation records that cover all seven continents, Amazon Route 53 will receive some DNS queries from locations that it can't identify. You can create a default record that handles both queries from IP addresses that aren't mapped to any location and queries that come from locations that you haven't created geolocation records for. If you don't create a default record, Route 53 returns a "no answer" response for queries from those locations.

You can use geolocation routing for records in both public and private hosted zones.

For more information, see [How Amazon Route 53 uses EDNS0 to estimate the location of a user](routing-policy-edns0.md).

For information about values that you specify when you use the geolocation routing policy to create records, see the following topics:
+ [Values specific for geolocation records](resource-record-sets-values-geo.md)
+ [Values specific for geolocation alias records](resource-record-sets-values-geo-alias.md)
+ [Values that are common for all routing policies](resource-record-sets-values-shared.md)
+ [Values that are common for alias records for all routing policies](resource-record-sets-values-alias-common.md)

# Geolocation routing in private hosted zones
<a name="routing-policy-geo-phz"></a>

For private hosted zones, Route 53 responds to DNS queries based on the AWS Region of the VPC that the query originated from. For the list of AWS Regions, see [Regions and zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) in the *Amazon EC2 user guide*.

If the DNS query originates from an on-premises part of a hybrid network, it will be considered as having originated from the AWS Region that the VPC is located in.

If you include health checks, you can create default records for:
+ IP addresses that aren't mapped to geographic locations.
+ DNS queries that come from locations that you haven't created geolocation records for.

If the geolocation record for the DNS query's region is unhealthy, the default record will be returned (if it is healthy).

In the example configuration in the following figure, DNS queries coming from an us-east-1 AWS Region (Virginia) will be routed to the 1.1.1.1 endpoint.

![\[A screenshot that shows a geolocation record for a private hosted zone.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/geolocation-phz.png)


# Geoproximity routing
<a name="routing-policy-geoproximity"></a>

Geoproximity routing lets Amazon Route 53 route traffic to your resources based on the geographic location of your users and your resources. It routes traffic to the closest resource that is available. You can also optionally choose to route more traffic or less traffic to a given resource by specifying a value, known as a *bias*. A bias expands or shrinks the size of the geographic region from which traffic is routed to a resource.

You create geoproximity rules for your resources and specify one of the following values for each rule:
+ If you're using AWS resources, specify the AWS Region or Local Zone Group that you created the resource in.
+ If you're using non-AWS resources, specify the latitude and longitude of the resource.

To use AWS Local Zones, you have to first enable them. For more information, see [Getting started with Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html) in the *AWS Local Zones User Guide*.

To learn about the difference between AWS Regions and Local Zones, see [Regions and Zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) in the *Amazon EC2 User Guide*.

To optionally change the size of the geographic region from which Route 53 routes traffic to a resource, specify the applicable value for the bias:
+ To expand the size of the geographic region from which Route 53 routes traffic to a resource, specify a positive integer from 1 to 99 for the bias. Route 53 shrinks the size of adjacent regions. 
+ To shrink the size of the geographic region from which Route 53 routes traffic to a resource, specify a negative bias of -1 to -99. Route 53 expands the size of adjacent regions. 

**Note**  
We're updating the Traffic Flow console for Route 53. During the transition period, you can continue to use the old console.

Choose the tab for the console you are using.
+ [New console](#traffic-flow-geoprox-routing-map-new)
+ [Old console](#traffic-flow-geoprox-routing-map-old)

------
#### [ New console ]

The following map shows four AWS Regions (numbered 1 through 5):

1. US West (Oregon)

1. Europe (Frankfurt)

1. Asia Pacific (Tokyo)

1. Africa (Cape Town)

1. Middle East (Bahrain)

**Note**  
The maps are available only with Traffic Flow.

![\[A map of the world that shows how traffic is routed when you have geoproximity records for resources in the AWS Regions in US West (Oregon), Europe (Frankfurt), Asia Pacific (Tokyo), Africa (Cape Town) and Middle East (Bahrain).\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-no-bias-new.png)


The following map shows what happens if you add a bias of \$125 for the US West (Oregon) Region (number **1** on the map). Traffic is routed to the resource in that Region from a larger portion of North America and from all of South America than previously.

![\[A map of the world that shows how traffic is routed when you add a bias of +25 in the US East (Northern Virginia) Region.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-plus25-new.png)


The following map shows what happens if you change the bias to -25 for the US West (Oregon) Region. Traffic is routed to the resource in that Region from smaller portions of North and South America than previously, and more traffic is routed to resources in the adjacent regions **2**, **3**, and **4**. 

![\[A map of the world that shows how traffic is routed when you add a bias of -25 in the US West (Oregon) Region.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-minus25-new.png)


------
#### [ Old console ]

The following map shows four AWS Regions (numbered 1 through 4) and a location in Johannesburg, South Africa that is specified by latitude and longitude (5).

**Note**  
The maps are available only with Traffic Flow.

![\[A map of the world that shows how traffic is routed when you have geoproximity records for resources in the AWS Regions in US West (Oregon), US East (N. Virginia), Europe (Paris), and Asia Pacific (Tokyo), and you have a record for a non-AWS resource in Johannesburg, South Africa.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-no-bias.png)


The following map shows what happens if you add a bias of \$125 for the US East (N. Virginia) Region (number **2** on the map). Traffic is routed to the resource in that Region from a larger portion of North America than previously, and from all of South America.

![\[A map of the world that shows how traffic is routed when you add a bias of +25 in the US East (Northern Virginia) Region.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-plus-25.png)


The following map shows what happens if you change the bias to -25 for the US East (N. Virginia) Region. Traffic is routed to the resource in that Region from smaller portions of North and South America than previously, and more traffic is routed to resources in the adjacent regions **1**, **3**, and **5**. 

![\[A map of the world that shows how traffic is routed when you add a bias of -25 in the US East (N. Virginia) Region.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-minus-25.png)


------

The effect of changing the bias for your resources depends on a number of factors, including the following:
+ The number of resources that you have.
+ How close the resources are to one another.
+ The number of users that you have near the border area between geographic regions. For example, suppose you have resources in the AWS Regions US East (N. Virginia) and US West (Oregon), and you have a lot of users in Dallas, Austin, and San Antonio, Texas, USA. Those cities are approximately equidistant between your resources, so a small change in bias could result in a large swing in traffic from resources in one AWS Region to another.

We recommend that you change the bias in small increments to prevent overwhelming your resources, due to an unanticipated swing in traffic.

For more information, see [How Amazon Route 53 uses EDNS0 to estimate the location of a user](routing-policy-edns0.md).

## How Amazon Route 53 uses bias to route traffic
<a name="routing-policy-geoproximity-bias"></a>

Here's the formula that Amazon Route 53 uses to determine how to route traffic:

**Bias**  
`Biased distance = actual distance * [1 - (bias/100)]`

When the value of the bias is positive, Route 53 treats the source of a DNS query and the resource that you specify in a geoproximity record (such as an EC2 instance in an AWS Region) as if they were closer together than they really are. For example, suppose you have the following geoproximity records:
+ A record for web server A, which has a positive bias of 50
+ A record for web server B, which has no bias

When a geoproximity record has a positive bias of 50, Route 53 halves the distance between the source of a query and the resource for that record. Then Route 53 calculates which resource is closer to the source of the query. Suppose web server A is 150 kilometers from the source of a query and web server B is 100 kilometers from the source of the query. If neither record had a bias, Route 53 would route the query to web server B because it's closer. However, because the record for web server A has a positive bias of 50, Route 53 treats web server A as if it's 75 kilometers from the source of the query. As a result, Route 53 routes the query to web server A. 

Here's the calculation for a positive bias of 50:

```
Bias = 50
Biased distance = actual distance * [1 - (bias/100)]

Biased distance = 150 kilometers * [1 - (50/100)]
Biased distance = 150 kilometers * (1 - .50)
Biased distance = 150 kilometers * (.50)
Biased distance = 75 kilometers
```

# Latency-based routing
<a name="routing-policy-latency"></a>

If your application is hosted in multiple AWS Regions, you can improve performance for your users by serving their requests from the AWS Region that provides the lowest latency. 

**Note**  
Data about the latency between users and your resources is based entirely on traffic between users and AWS data centers. If you aren't using resources in an AWS Region, the actual latency between your users and your resources can vary significantly from AWS latency data. This is true even if your resources are located in the same city as an AWS Region.

To use latency-based routing, you create latency records for your resources in multiple AWS Regions. When Route 53 receives a DNS query for your domain or subdomain (example.com or acme.example.com), it determines which AWS Regions you've created latency records for, determines which Region gives the user the lowest latency, and then selects a latency record for that Region. Route 53 responds with the value from the selected record, such as the IP address for a web server. 

For example, suppose you have Elastic Load Balancing load balancers in the US West (Oregon) Region and in the Asia Pacific (Singapore) Region. You create a latency record for each load balancer. Here's what happens when a user in London enters the name of your domain in a browser:

1. DNS routes the query to a Route 53 name server.

1. Route 53 refers to its data on latency between London and the Singapore Region and between London and the Oregon Region. 

1. If latency is lower between the London and Oregon Regions, Route 53 responds to the query with the IP address for the Oregon load balancer. If latency is lower between London and the Singapore Region, Route 53 responds with the IP address for the Singapore load balancer. 

Latency between hosts on the internet can change over time as a result of changes in network connectivity and routing. Latency-based routing is based on latency measurements taken over a period of time, and the measurements reflect these changes. A request that is routed to the Oregon Region this week might be routed to the Singapore Region next week.

**Note**  
When a browser or other viewer uses a DNS resolver that supports the edns-client-subnet extension of EDNS0, the DNS resolver sends Route 53 a truncated version of the user's IP address. If you configure latency-based routing, Route 53 considers this value when routing traffic to your resources. For more information, see [How Amazon Route 53 uses EDNS0 to estimate the location of a user](routing-policy-edns0.md).

You can use latency routing policy for records in a private hosted zone.

For information about values that you specify when you use the latency routing policy to create records, see the following topics:
+ [Values specific for latency records](resource-record-sets-values-latency.md)
+ [Values specific for latency alias records](resource-record-sets-values-latency-alias.md)
+ [Values that are common for all routing policies](resource-record-sets-values-shared.md)
+ [Values that are common for alias records for all routing policies](resource-record-sets-values-alias-common.md)

# Latency-based routing in private hosted zones
<a name="routing-policy-latency-phz"></a>

For private hosted zones, Route 53 answers DNS queries with an endpoint that is in the same AWS Region, or is closest in distance to the AWS Region of the VPC that the query originated from.

**Note**  
If you have an outbound endpoint forwarded to an inbound endpoint, the record will resolve based on where the inbound endpoint is, not the outbound endpoint.

If you include health checks, and the record with the lowest latency to the query's origin is unhealthy, a healthy endpoint with the next lowest latency is returned.

In the example configuration in the following figure, DNS queries coming from a us-east-1 AWS Region, or closest to it, will be routed to the 1.1.1.1 endpoint. DNS queries from us-west-2, or closest to it, will be routed to the 2.2.2.2 endpoint.

![\[A screenshot that shows two latency records for a private hosted zone.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/latency-phz.png)


# IP-based routing
<a name="routing-policy-ipbased"></a>

With IP-based routing in Amazon Route 53, you can fine-tune your DNS routing by using your understanding of your network, applications, and clients to make the best DNS routing decisions for your end users. IP-based routing gives you granular control to optimize performance or reduce network costs by uploading your data to Route 53 in the form of user-IP-to-endpoint mappings.

Geolocation and latency-based routing is based on data that Route 53 collects and keeps up to date. This approach works well for the majority of customers, but IP-based routing offers you the additional ability to optimize routing based on specific knowledge of your customer base. For example, a global video content provider might want to route end users from a particular internet service provider (ISP).

Some common use cases for IP-based routing are the following:
+ You want to route end users from certain ISPs to specific endpoints so you can optimize network transit costs or performance.
+ You want to add overrides to existing Route 53 routing types, such as geolocation routing, based on your knowledge of your clients' physical locations.

**Managing IP ranges and associating them to a resource record set (RRSet)**  
 For IPv4, you can use CIDR blocks between 1 and 24 bits of length, inclusive, while for IPv6, you can use CIDR blocks between 1 and 48 bits of length, inclusive. To define a zero bit CIDR block (0.0.0.0/0 or ::/0), use the default ("\$1") location.

For DNS queries with a CIDR longer than the one specified in the CIDR collection, Route 53 will match it to the shorter CIDR. For example, if you specify 2001:0DB8::/32 as the CIDR block in your CIDR collection and a query originates from 2001:0DB8:0000:1234::/48, it will match. If, on the other hand, you specify 2001:0DB8:0000:1234::/48 in your CIDR collection and a query originates from 2001:0DB8::/32, this will not match and Route 53 will answer with the record for the default ("\$1") location.

You can group sets of CIDR blocks (or IP ranges) into CIDR locations, which are in turn grouped into reusable entities called CIDR collections:

**CIDR block**  
An IP range in CIDR notation, for example, 192.0.2.0/24 or 2001:DB8::/32.

**CIDR location**  
A named list of CIDR blocks. For example, example-isp-seattle = [192.0.2.0/24, 203.0.113.0/22, 198.51.100.0/24, 2001:DB8::/32 ]. The blocks in a CIDR location list don't have to be adjacent or the same range.   
A single location can have both IPv4 and IPv6 blocks, and this location can be associated to both A and AAAA record sets, respectively.   
The location name is often a location by convention, but can be any string, for example, *Company-A*.

**CIDR collection**  
A named collection of locations. For example, mycollection = [example-isp-seattle, example-isp-tokyo].  
IP-based routing resource record sets reference a location in a collection, and all resource record sets for the same record set name and type must reference the same collection. For example, if you create websites in two Regions and want to direct DNS queries from two different CIDR locations to a specific website based on the originating IP addresses, then both of those locations must be listed in the same CIDR collection.

You cannot use IP-based routing policy for records in a private hosted zone.

For information about values that you specify when you use the IP-based routing policy to create records, see the following topics:
+ [Values specific for IP-based records](resource-record-sets-values-ipbased.md)
+ [Values specific for IP-based alias records](resource-record-sets-values-ipbased-alias.md)
+ [Values that are common for all routing policies](resource-record-sets-values-shared.md)
+ [Values that are common for alias records for all routing policies](resource-record-sets-values-alias-common.md)

**Topics**
+ [

# Creating a CIDR collection with CIDR locations and blocks
](resource-record-sets-creating-cidr-collection.md)
+ [

# Working with CIDR locations and blocks
](resource-record-sets-working-with-cidr-locations.md)
+ [

# Deleting a CIDR collection
](resource-record-sets-delete-cidr-collection.md)
+ [

# Moving a geolocation to IP-based routing
](resource-record-sets-move-geolocation-to-cidr.md)

# Creating a CIDR collection with CIDR locations and blocks
<a name="resource-record-sets-creating-cidr-collection"></a>



To get started, create a CIDR collection and add CIDR blocks and locations to it.<a name="CIDR-collection-creating-procedure"></a>

**To create a CIDR collection 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 **IP-based routing**, and then **CIDR collections**.

1. Select **Create CIDR collection**.

1. In the **Create CIDR collection** pane, under **Details**, enter a name for the collection.

1. Choose **Create collection** to create an empty collection.

   - or -

   In the **Create CIDR locations** section, enter a name for the CIDR location in the **CIDR location** box. The location name can be any identifying string, for example **company 1**, or **Seattle**. It doesn't have to be an actual geographic location.
**Important**  
The CIDR location name has a maximum length of 16 characters.

   Enter the CIDR blocks in the **CIDR blocks** box one per line. These can be IPv4 or IPv6 addresses ranging from /0 to /24 for IPv4 and /0 to /48 for IPv6.

1. After you have entered the CIDR blocks, choose **Create CIDR collection**, or **Add another location** to keep entering locations and CIDR block. You can enter multiple CIDR locations per collection.

1. After you have entered CIDR locations, choose **Create CIDR collection**.

# Working with CIDR locations and blocks
<a name="resource-record-sets-working-with-cidr-locations"></a>

<a name="CIDR-locations-work-with-procedure"></a>

**To work with CIDR locations by 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 **IP-based routing**, **CIDR collections** and then, in the **CIDR collections** section, click on a link to a CIDR collection in the **Collection name** list.

   On the **CIDR locations** page, you can create a CIDR location, delete it, or edit a location and its blocks.
   + To create a location, choose **Create CIDR location**. 
   + In the **Create CIDR location** pane, enter a name for the location, the CIDR blocks associated with the location, and then choose **Create**.
   + To view a CIDR location and the blocks within, choose the radio button next to a location to display its name and CIDR blocks in the location pane.

     In this pane, you can also choose **Edit** to update the name of the location or its CIDR blocks. Choose **Save** when you have finished editing.
   + To delete a CIDR location and the blocks within, choose the radio button next to the location you want to delete, and then choose **Delete**. To confirm deletion, enter the location name in the text input field and choose **Delete** again.
**Important**  
Deleting a CIDR location can't be undone. If you have any DNS records associated with the location, your domain might become unreachable.

# Deleting a CIDR collection
<a name="resource-record-sets-delete-cidr-collection"></a>

<a name="CIDR-collection-delete-procedure"></a>

**To delete a CIDR collection, its locations, and blocks by 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 **IP-based routing** and then **CIDR collections**.

1. In the **CIDR collections** section, click the linked name of the collection that you want to delete.

1. On the **CIDR locations** page, select each location one at a time, choose **Delete**, enter its name in the dialog box, and then choose **Delete**. You must delete each location associated with a CIDR collection before you can delete the collection.

1. After the deletion of each CIDR location is complete, on the **CIDR locations** page, choose the radio button next to the collection you want to delete, and then choose **Delete**.

# Moving a geolocation to IP-based routing
<a name="resource-record-sets-move-geolocation-to-cidr"></a>

If you are using either geolocation or geoproximity routing policies, and you’re consistently seeing specific clients routed to an endpoint that isn’t optimal based on their physical location or network topology, you can better target these clients’ public IP ranges by using IP-based routing.

The following table contains an example geolocation configuration for an existing geolocation routing that we will fine-tune for California IP ranges.


| Record set name | Routing policy and origin | IP address of the application endpoint  | 
| --- | --- | --- | 
|  example.com  |  Geolocation-routing (US)  |  `198.51.100.1`  | 
|  example.com  |  Geolocation-routing (EU)   |  `198.51.100.2`  | 

To override IP ranges from California to go to a new application endpoint, first recreate the geolocation routing under a new record set name.


| Record set name | Routing policy and origin | IP address of the application endpoint  | 
| --- | --- | --- | 
|  geo.example.com  |  Geolocation-routing (US)  |  `198.51.100.1`  | 
|  geo.example.com  |  Geoloaction-routing (EU)   |  `198.51.100.2`  | 

Then, create IP-based routing records and a default record that points to your recently recreated geolocation routing recordset. 


| Record set name | Routing policy and origin | IP address of the application endpoint  | 
| --- | --- | --- | 
|  example.com  |  IP-based routing (default)   |  Alias record to geo.example.com application endpoint that you want to be the default. For example, `198.51.100.1`.  | 
|  example.com  |  IP-based routing (California IP ranges)   |  `198.51.100.3`  | 

# Multivalue answer routing
<a name="routing-policy-multivalue"></a>

Multivalue answer routing lets you configure Amazon Route 53 to return multiple values, such as IP addresses for your web servers, in response to DNS queries. You can specify multiple values for almost any record, but multivalue answer routing also lets you check the health of each resource, so Route 53 returns only values for healthy resources. It's not a substitute for a load balancer, but the ability to return multiple health-checkable IP addresses is a way to use DNS to improve availability and load balancing.

To route traffic approximately randomly to multiple resources, such as web servers, you create one multivalue answer record for each resource and, optionally, associate a Route 53 health check with each record. Route 53 responds to DNS queries with up to eight healthy records and gives different answers to different DNS resolvers. If a web server becomes unavailable after a resolver caches a response, client software can try another IP address in the response.

Note the following:
+ If you associate a health check with a multivalue answer record, Route 53 responds to DNS queries with the corresponding IP address only when the health check is healthy.
+ If you don't associate a health check with a multivalue answer record, Route 53 always considers the record to be healthy.
+ If you have eight or fewer healthy records, Route 53 responds to all DNS queries with all the healthy records.
+ When all records are unhealthy, Route 53 responds to DNS queries with up to eight unhealthy records.

You can use multivalue answer routing policy for records in a private hosted zone.

For information about values that you specify when you use the multivalue answer routing policy to create records, see [Values specific for multivalue answer records](resource-record-sets-values-multivalue.md) and [Values that are common for all routing policies](resource-record-sets-values-shared.md).

# Weighted routing
<a name="routing-policy-weighted"></a>

Weighted routing lets you associate multiple resources with a single domain name (example.com) or subdomain name (acme.example.com) and choose how much traffic is routed to each resource. This can be useful for a variety of purposes, including load balancing and testing new versions of software.

To configure weighted routing, you create records that have the same name and type for each of your resources. You assign each record a relative weight that corresponds with how much traffic you want to send to each resource. Amazon Route 53 sends traffic to a resource based on the weight that you assign to the record as a proportion of the total weight for all records in the group: 

![\[Formula for how much traffic is routed to a given resource: weight for a specified record / sum of the weights for all records.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/WRR_calculation.png)


For example, if you want to send a tiny portion of your traffic to one resource and the rest to another resource, you might specify weights of 1 and 255. The resource with a weight of 1 gets 1/256th of the traffic (1/(1\$1255)), and the other resource gets 255/256ths (255/(1\$1255)). You can gradually change the balance by changing the weights. If you want to stop sending traffic to a resource, you can change the weight for that record to 0.

For information about values that you specify when you use the weighted routing policy to create records, see the following topics:
+ [Values specific for weighted records](resource-record-sets-values-weighted.md)
+ [Values specific for weighted alias records](resource-record-sets-values-weighted-alias.md)
+ [Values that are common for all routing policies](resource-record-sets-values-shared.md)
+ [Values that are common for alias records for all routing policies](resource-record-sets-values-alias-common.md)

You can use weighted routing policy for records in a private hosted zone.

## Health checks and weighted routing
<a name="routing-policy-weighted-healthchecks"></a>

If you add health checks to all the records in a group of weighted records, but you give nonzero weights to some records and zero weights to others, health checks work the same as when all records have nonzero weights with the following exceptions:
+ Route 53 initially considers only the nonzero weighted records, if any.
+ If all the records that have a weight greater than 0 are unhealthy, then Route 53 considers the zero-weighted records.

The following table details the behavior when the 0-weight record includes a health check:


|   | Record 1 | Record 2 | Record 3 | 
| --- |--- |--- |--- |
|  Weight  |  1  |  1  |  0  | 
|  Includes health check?  |  Yes  |  Yes  |  Yes  | 
|  | 
| --- |
|  Health check status  |  Unhealthy  |  Unhealthy  |  Healthy  | 
|  DNS query answered?  |  No  |  No  |  Yes  | 
|  | 
| --- |
|  Health check status  |  Unhealthy  |  Unhealthy  |  Unhealthy  | 
| DNS query answered? |  Yes  |  Yes  |  No  | 
|  | 
| --- |
|  Health check status  |  Unhealthy  |  Healthy  |  Unhealthy  | 
|  DNS query answered?  |  No  |  Yes  |  No  | 
|  | 
| --- |
|  Health check status  |  Healthy  |  Healthy  |  Unhealthy  | 
|  DNS query answered?  |  Yes  |  Yes  |  No  | 
|  | 
| --- |
|  Health check status  |  Healthy  |  Healthy  |  Healthy  | 
|  DNS query answered?  |  Yes  |  Yes  |  No  | 

The following table details the behavior when the 0-weight record doesn't include a health check:


|   | Record 1 | Record 2 | Record 3 | 
| --- |--- |--- |--- |
|  Weight  |  1  |  1  |  0  | 
|  Includes health check?  |  Yes  |  Yes  |  No  | 
|  | 
| --- |
|  Health check status  |  Healthy  |  Healthy  | N/A | 
| DNS query answered? | Yes |  Yes  | No | 
|  | 
| --- |
|  Health check status  |  Unhealthy  |  Unhealthy  |  N/A  | 
|  DNS query answered?  |  No  |  No  |  Yes  | 
|  | 
| --- |
|  Health check status  |  Unhealthy  |  Healthy  |  N/A  | 
| DNS query answered? |  No  |  Yes  |  No  | 

# How Amazon Route 53 uses EDNS0 to estimate the location of a user
<a name="routing-policy-edns0"></a>

To improve the accuracy of geolocation, geoproximity, IP-based, and latency routing, Amazon Route 53 supports the edns-client-subnet extension of EDNS0. (EDNS0 adds several optional extensions to the DNS protocol.) Route 53 can use edns-client-subnet only when DNS resolvers support it:
+ When a browser or other viewer uses a DNS resolver that does not support edns-client-subnet, Route 53 uses the source IP address of the DNS resolver to approximate the location of the user and responds to geolocation queries with the DNS record for the resolver's location.
+ When a browser or other viewer uses a DNS resolver that does support edns-client-subnet, the DNS resolver sends Route 53 a truncated version of the user's IP address. Route 53 determines the location of the user based on the truncated IP address rather than the source IP address of the DNS resolver; this typically provides a more accurate estimate of the user's location. Route 53 then responds to geolocation queries with the DNS record for the user's location.
+ EDNS0 is not applicable to private hosted zones. For private hosted zones Route 53 uses data from the VPC Resolvers in the AWS Region that the private hosted zone is in to make geolocation and latency routing decisions.

For more information about edns-client-subnet, see the EDNS Client Subnet RFC, [Client Subnet in DNS Requests](https://www.rfc-editor.org/rfc/rfc7871).

# Choosing between alias and non-alias records
<a name="resource-record-sets-choosing-alias-non-alias"></a>

Amazon Route 53 *alias records* provide a Route 53–specific extension to DNS functionality. Alias records let you route traffic to selected AWS resources, including but not limited to, CloudFront distributions and Amazon S3 buckets. They also let you route traffic from one record in a hosted zone to another record. 

Unlike a CNAME record, you can create an alias record at the top node of a DNS namespace, also known as the *zone apex*. For example, if you register the DNS name example.com, the zone apex is example.com. You can't create a CNAME record for example.com, but you can create an alias record for example.com that routes traffic to www.example.com (as long as the record type for www.example.com is not of type CNAME).

When Route 53 receives a DNS query for an alias record, Route 53 responds with the applicable value for that resource:
+ **An Amazon API Gateway custom regional API or edge-optimized API** – Route 53 responds with one or more IP addresses for your API.
+ **An Amazon VPC interface endpoint** – Route 53 responds with one or more IP addresses for your interface endpoint.
+ **A CloudFront distribution** – Route 53 responds with one or more IP addresses for CloudFront edge servers that can serve your content.
+ **App Runner service** – Route 53 responds with one or more IP addresses.
+ **An Elastic Beanstalk environment** – Route 53 responds with one or more IP addresses for the environment.
+ **An Elastic Load Balancing load balancer** – Route 53 responds with one or more IP addresses for the load balancer. This includes Application Load Balancer, Classic Load Balancer and, Network Load Balancer.
+ **An AWS Global Accelerator accelerator** – Route 53 responds with the IP addresses for the accelerator. 
+ **An OpenSearch Service** – Route 53 responds with one or more IP addresses for the OpenSearch Service custom domain.
+ **An Amazon S3 bucket that is configured as a static website** – Route 53 responds with one IP address for the Amazon S3 bucket.
+ **Another Route 53 record of the same type in the same hosted zone** – Route 53 responds as if the query is for the record that is referenced by the alias record (see [Comparison of alias and CNAME records](#resource-record-sets-choosing-alias-non-alias-comparison)).
+ **AWS AppSync domain name** – Route 53 responds with one or more IP addresses for your interface endpoint.

For more information, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

When you use an alias record to route traffic to an AWS resource, Route 53 automatically recognizes changes in the resource. For example, suppose an alias record for example.com points to an Elastic Load Balancing load balancer at lb1-1234.us-east-2.elb.amazonaws.com. If the IP address of the load balancer changes, Route 53 automatically starts to respond to DNS queries using the new IP address.

If an alias record points to an AWS resource, you can't set the time to live (TTL); Route 53 uses the default TTL for the resource. If an alias record points to another record in the same hosted zone, Route 53 uses the TTL of the record that the alias record points to. For more information about the current TTL value for Elastic Load Balancing, go to [Request routing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#request-routing) in the *Elastic Load Balancing User Guide* and search for "ttl".

For information about creating records by using the Route 53 console, see [Creating records by using the Amazon Route 53 console](resource-record-sets-creating.md). For information about the values that you specify for alias records, see the applicable topic in [Values that you specify when you create or edit Amazon Route 53 records](resource-record-sets-values.md):
+ [Values specific for simple alias records](resource-record-sets-values-alias.md)
+ [Values specific for weighted alias records](resource-record-sets-values-weighted-alias.md)
+ [Values specific for latency alias records](resource-record-sets-values-latency-alias.md)
+ [Values specific for failover alias records](resource-record-sets-values-failover-alias.md)
+ [Values specific for geolocation alias records](resource-record-sets-values-geo-alias.md)
+ [Values specific for geoproximity alias records](resource-record-sets-values-geoprox-alias.md)
+ [Values that are common for alias records for all routing policies](resource-record-sets-values-alias-common.md)

## Comparison of alias and CNAME records
<a name="resource-record-sets-choosing-alias-non-alias-comparison"></a>

Alias records are similar to CNAME records, but there are some important differences. The following list compares alias records and CNAME records.

**Resources that you can redirect queries to**    
**Alias records**  
An alias record can only redirect queries to selected AWS resources, including but not limited to the following:  
+ Amazon S3 buckets
+ CloudFront distributions
+ Another record in the same Route 53 hosted zone
For example, you can create an alias record named acme.example.com that redirects queries to an Amazon S3 bucket that is also named acme.example.com. You can also create an acme.example.com alias record that redirects queries to a record named zenith.example.com in the example.com hosted zone.  
**CNAME records**  
A CNAME record can redirect DNS queries to any DNS record. For example, you can create a CNAME record that redirects queries from acme.example.com to zenith.example.com or to acme.example.org. You don't need to use Route 53 as the DNS service for the domain that you're redirecting queries to.

**Creating records that have the same name as the domain (records at the zone apex)**    
**Alias records**  
In most configurations, you can create an alias record that has the same name as the hosted zone (the zone apex). The one exception is when you want to redirect queries from the zone apex (such as example.com) to a record in the same hosted zone that has a type of CNAME (such as zenith.example.com). The alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record.  
**CNAME records**  
You can't create a CNAME record that has the same name as the hosted zone (the zone apex). This is true both for hosted zones for domain names (example.com) and for hosted zones for subdomains (zenith.example.com).

**Pricing for DNS queries**    
**Alias records**  
Route 53 doesn't charge for alias queries to AWS resources. For more information, see [Amazon Route 53 Pricing](https://aws.amazon.com/route53/pricing/).  
**CNAME records**  
Route 53 charges for CNAME queries.  
If you create a CNAME record that redirects to the name of another record in a Route 53 hosted zone (the same hosted zone or another hosted zone), each DNS query is charged as two queries:  
+ Route 53 responds to the first DNS query with the name of the record that you want to redirect to.
+ Then the DNS resolver must submit another query for the record in the first response to get information about where to direct traffic, for example, the IP address of a web server.
If the CNAME record redirects to the name of a record that is hosted with another DNS service, Route 53 charges for one query. The other DNS service might charge for the second query.

**Record type specified in the DNS query**    
**Alias records**  
Route 53 responds to a DNS query only when the name of the alias record (such as acme.example.com) and the type of the alias record (such as A or AAAA) match the name and type in the DNS query.  
**CNAME records**  
A CNAME record redirects DNS queries for a record name regardless of the record type specified in the DNS query, such as A or AAAA.

**How records are listed in dig or nslookup queries**    
**Alias records**  
In the response to a dig or nslookup query, an alias record is listed as the record type that you specified when you created the record, such as A or AAAA. (The record type that you specify for an alias record depends on the resource that you're routing traffic to. For example, to route traffic to an S3 bucket, you specify A for the type.) The alias property is visible only in the Route 53 console or in the response to a programmatic request, such as an AWS CLI `list-resource-record-sets` command.  
**CNAME records**  
A CNAME record is listed as a CNAME record in response to dig or nslookup queries.

# Supported DNS record types
<a name="ResourceRecordTypes"></a>

Amazon Route 53 supports the DNS record types that are listed in this section. Each record type also includes an example of how to format the `Value` element when you are accessing Route 53 using the API.

**Note**  
For record types that include a domain name, enter a fully qualified domain name, for example, *www.example.com*. The trailing dot is optional; Route 53 assumes that the domain name is fully qualified. This means that Route 53 treats *www.example.com* (without a trailing dot) and *www.example.com.* (with a trailing dot) as identical.

Route 53 provides an extension to DNS functionality known as alias records. Similar to CNAME records, alias records let you route traffic to selected AWS resources, such as CloudFront distributions and Amazon S3 buckets. For more information, including a comparison of alias and CNAME records, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [

## A record type
](#AFormat)
+ [

## AAAA record type
](#AAAAFormat)
+ [

## CAA record type
](#CAAFormat)
+ [

## CNAME record type
](#CNAMEFormat)
+ [

## DS record type
](#DSFormat)
+ [

## HTTPS record type
](#HTTPSFormat)
+ [

## MX record type
](#MXFormat)
+ [

## NAPTR record type
](#NAPTRFormat)
+ [

## NS record type
](#NSFormat)
+ [

## PTR record type
](#PTRFormat)
+ [

## SOA record type
](#SOAFormat)
+ [

## SPF record type
](#SPFFormat)
+ [

## SRV record type
](#SRVFormat)
+ [

## SSHFP record type
](#SSHFPFormat)
+ [

## SVCB record type
](#SVCBFormat)
+ [

## TLSA record type
](#TLSAFormat)
+ [

## TXT record type
](#TXTFormat)

## A record type
<a name="AFormat"></a>

You use an A record to route traffic to a resource, such as a web server, using an IPv4 address in dotted decimal notation.

**Example for the Amazon Route 53 console**

```
192.0.2.1
```

**Example for the Route 53 API**

```
<Value>192.0.2.1</Value>
```

## AAAA record type
<a name="AAAAFormat"></a>

You use an AAAA record to route traffic to a resource, such as a web server, using an IPv6 address in colon-separated hexadecimal format.

**Example for the Amazon Route 53 console**

```
2001:0db8:85a3:0:0:8a2e:0370:7334
```

**Example for the Route 53 API**

```
<Value>2001:0db8:85a3:0:0:8a2e:0370:7334</Value>
```

## CAA record type
<a name="CAAFormat"></a>

A CAA record specifies which certificate authorities (CAs) are allowed to issue certificates for a domain or subdomain. Creating a CAA record helps to prevent the wrong CAs from issuing certificates for your domains. A CAA record isn't a substitute for the security requirements that are specified by your certificate authority, such as the requirement to validate that you're the owner of a domain.

You can use CAA records to specify the following:
+ Which certificate authorities (CAs) can issue SSL/TLS certificates, if any
+ The email address or URL to contact when a CA issues a certificate for the domain or subdomain

When you add a CAA record to your hosted zone, you specify three settings separated by spaces:

`flags tag "value"`

Note the following about the format for CAA records:
+ The value of `tag` can contain only the characters A-Z, a-z, and 0-9.
+ Always enclose `value` in quotation marks ("").
+ Some CAs allow or require additional values for `value`. Specify additional values as name-value pairs, and separate them with semicolons (;), for example:

  `0 issue "ca.example.net; account=123456"`
+ If a CA receives a request for a certificate for a subdomain (such as www.example.com) and if no CAA record for the subdomain exists, the CA submits a DNS query for a CAA record for the parent domain (such as example.com). If a record for the parent domain exists and if the certificate request is valid, the CA issues the certificate for the subdomain.
+ We recommend that you consult with your CA to determine what values to specify for a CAA record.
+ You can't create a CAA record and a CNAME record that have the same name because DNS doesn't allow using the same name for both a CNAME record and any other type of record.

**Topics**
+ [

### Authorize a CA to issue a certificate for a domain or subdomain
](#CAAFormat-issue)
+ [

### Authorize a CA to issue a wildcard certificate for a domain or subdomain
](#CAAFormat-issue-wild)
+ [

### Prevent any CA from issuing a certificate for a domain or subdomain
](#CAAFormat-prevent-issue)
+ [

### Request that any CA contacts you if the CA receives an invalid certificate request
](#CAAFormat-contact)
+ [

### Use another setting that is supported by the CA
](#CAAFormat-custom-setting)
+ [

### Examples
](#CAAFormat-examples)

### Authorize a CA to issue a certificate for a domain or subdomain
<a name="CAAFormat-issue"></a>

To authorize a CA to issue a certificate for a domain or subdomain, create a record that has the same name as the domain or subdomain, and specify the following settings:
+ **flags** – `0`
+ **tag** – `issue`
+ **value** – the code for the CA that you authorize to issue a certificate for the domain or subdomain

For example, suppose you want to authorize ca.example.net to issue a certificate for example.com. You create a CAA record for example.com with the following settings:

```
0 issue "ca.example.net"
```

For information about how to authorize AWS Certificate Manager to issue a certificate, see [Configure a CAA record](https://docs.aws.amazon.com/acm/latest/userguide/setup-caa.html) in the *AWS Certificate Manager User Guide*.

### Authorize a CA to issue a wildcard certificate for a domain or subdomain
<a name="CAAFormat-issue-wild"></a>

To authorize a CA to issue a wildcard certificate for a domain or subdomain, create a record that has the same name as the domain or subdomain, and specify the following settings. A wildcard certificate applies to the domain or subdomain and all of its subdomains.
+ **flags** – `0`
+ **tag** – `issuewild`
+ **value** – the code for the CA that you authorize to issue a certificate for a domain or subdomain, and its subdomains

For example, suppose you want to authorize ca.example.net to issue a wildcard certificate for example.com, which applies to example.com and all of its subdomains. You create a CAA record for example.com with the following settings:

```
0 issuewild "ca.example.net"
```

When you want to authorize a CA to issue a wildcard certificate for a domain or subdomain, create a record that has the same name as the domain or subdomain, and specify the following settings. A wildcard certificate applies to the domain or subdomain and all of its subdomains.

### Prevent any CA from issuing a certificate for a domain or subdomain
<a name="CAAFormat-prevent-issue"></a>

To prevent any CA from issuing a certificate for a domain or subdomain, create a record that has the same name as the domain or subdomain, and specify the following settings:
+ **flags** – `0`
+ **tag** – `issue`
+ **value** – `";"`

For example, suppose you don't want any CA to issue a certificate for example.com. You create a CAA record for example.com with the following settings:

`0 issue ";"`

If you don't want any CA to issue a certificate for example.com or its subdomains, you create a CAA record for example.com with the following settings: 

`0 issuewild ";"`

**Note**  
If you create a CAA record for example.com and specify both of the following values, a CA that is using the value ca.example.net can issue the certificate for example.com:  

```
0 issue ";"
0 issue "ca.example.net"
```

### Request that any CA contacts you if the CA receives an invalid certificate request
<a name="CAAFormat-contact"></a>

If you want any CA that receives an invalid request for a certificate to contact you, specify the following settings:
+ **flags** – `0`
+ **tag** – `iodef`
+ **value** – the URL or email address that you want the CA to notify if the CA receives an invalid request for a certificate. Use the applicable format:

  `"mailto:email-address"`

  `"http://URL"`

  `"https://URL"`

For example, if you want any CA that receives an invalid request for a certificate to send email to admin@example.com, you create a CAA record with the following settings:

```
0 iodef "mailto:admin@example.com"
```

### Use another setting that is supported by the CA
<a name="CAAFormat-custom-setting"></a>

If your CA supports a feature that isn't defined in the RFC for CAA records, specify the following settings:
+ **flags** – 128 (This value prevents the CA from issuing a certificate if the CA doesn't support the specified feature.)
+ **tag** – the tag that you authorize the CA to use
+ **value** – the value that corresponds with the value of tag

For example, suppose your CA supports sending a text message if the CA receives an invalid certificate request. (We aren't aware of any CAs that support this option.) Settings for the record might be the following:

```
128 exampletag "15555551212"
```

### Examples
<a name="CAAFormat-examples"></a>

**Example for the Route 53 console**

```
0 issue "ca.example.net"
0 iodef "mailto:admin@example.com"
```

**Example for the Route 53 API**

```
<ResourceRecord>
   <Value>0 issue "ca.example.net"</Value>
   <Value>0 iodef "mailto:admin@example.com"</Value>
</ResourceRecord>
```

## CNAME record type
<a name="CNAMEFormat"></a>

A CNAME record maps DNS queries for the name of the current record, such as acme.example.com, to another domain (example.com or example.net) or subdomain (acme.example.com or zenith.example.org). 

**Important**  
The DNS protocol does not allow you to create a CNAME record for the top node of a DNS namespace, also known as the zone apex. For example, if you register the DNS name example.com, the zone apex is example.com. You cannot create a CNAME record for example.com, but you can create CNAME records for www.example.com, newproduct.example.com, and so on.  
In addition, if you create a CNAME record for a subdomain, you cannot create any other records for that subdomain. For example, if you create a CNAME for www.example.com, you cannot create any other records for which the value of the **Name** field is www.example.com.

Amazon Route 53 also supports alias records, which allow you to route queries to selected AWS resources, such as CloudFront distributions and Amazon S3 buckets. Aliases are similar in some ways to the CNAME record type; however, you can create an alias for the zone apex. For more information, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Example for the Route 53 console**

```
hostname.example.com
```

**Example for the Route 53 API**

```
<Value>hostname.example.com</Value>
```

## DS record type
<a name="DSFormat"></a>

A delegation signer (DS) record refers a zone key for a delegated subdomain zone. You might create a DS record when you establish a chain of trust when you configure DNSSEC signing. For more information about configuring DNSSEC in Route 53, see [Configuring DNSSEC signing in Amazon Route 53](dns-configuring-dnssec.md).

The first three values are decimal numbers representing the key tag, algorithm, and digest type. The fourth value is the digest of the zone key. For more information about the DS record format, see [RFC 4034](https://www.ietf.org/rfc/rfc4034.txt).

**Example for the Route 53 console**

```
123 4 5 1234567890abcdef1234567890absdef
```

**Example for the Route 53 API**

```
<Value>123 4 5 1234567890abcdef1234567890absdef</Value>
```

## HTTPS record type
<a name="HTTPSFormat"></a>

An HTTPS resource record is a form of the Service Binding (SVCB) DNS record that provides extended configuration information, enabling a client to easily and securely connect to a service with an HTTP protocol. The configuration information is provided in parameters that allow the connection in one DNS query, rather than necessitating multiple DNS queries. 

The format for an HTTPS resource record is:

`SvcPriority TargetName SvcParams(optional)`

The following parameters are described in [RFC 9460, section 9.1](https://www.rfc-editor.org/rfc/rfc9460.html#section-9.1).

**SvcPriority**  
An integer that represents the priority. 0 priority means alias mode, and is generally intended for aliasing at the zone apex. This value is an integer 0-32767 for Route 53 of which 1-32767 are service mode records. Lower the priority, higher the preference. 

**TargetName**  
The domain name of either the alias target (for alias mode) or the alternate endpoint (for ServiceMode).

**SvcParams (optional)**  
 A whitespace-separated list, with each parameter consisting of a Key=Value pair or a standalone key. If there is more than one value, they are presented as a comma-separated list. The following are the defined SvcParams:  
+ `1:alpn` – Application Layer Protocol Negotiation Protocol IDs. Default is HTTP/1.1, `h2` is HTTP/2 over TLS, and `h3` is HTTP/3 (HTTP over QUIC protocol). 
+ `2:no-default-alpn` – The default is not supported and you must provide an `alpn` parameter.
+ `3:port` – the alternate endpoint, or the port where the service can be reached. 
+ `4:ipv4hint` – IPv4 address hints.
+ `5:ech` – Encrypted Client Hello.
+ `6:ipv6hint` – IPv6 address hints.
+ `7:dohpath` – DNS over HTTPS template
+ `8:ohttp` – The service operates an Oblivious HTTP target

**Example for the Amazon Route 53 console for alias mode**

```
0 example.com
```

**Example for the Amazon Route 53 console for service mode**

```
16 example.com alpn="h2,h3" port=808
```

**Example for the Amazon Route 53 API for alias mode**

```
<Value>0 example.com</Value>
```

**Example for the Route 53 API for service mode**

```
<Value>16 example.com alpn="h2,h3" port=808</Value>
```

For more information, see [RFC 9460, Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)](https://datatracker.ietf.org/doc/html/rfc9460).

**Note**  
Route 53 does not support the arbitrary unknown-key presentation format `keyNNNNN`

## MX record type
<a name="MXFormat"></a>

An MX record specifies the names of your mail servers and, if you have two or more mail servers, the priority order. Each value for an MX record contains two values, priority and domain name.

**Priority**  
An integer that represents the priority for an email server. If you specify only one server, the priority can be any integer between 0 and 65535. If you specify multiple servers, the value that you specify for the priority indicates which email server you want email to be routed to first, second, and so on. The server with the lowest value for the priority takes precedence. For example, if you have two email servers and you specify values of 10 and 20 for the priority, email always goes to the server with a priority of 10 unless it's unavailable. If you specify values of 10 and 10, email is routed to the two servers approximately equally.

**Domain name**  
The domain name of the email server. Specify the name (such as mail.example.com) of an A or AAAA record. In [RFC 2181, Clarifications to the DNS Specification](https://tools.ietf.org/html/rfc2181), section 10.3 forbids specifying the name of a CNAME record for the domain name value. (When the RFC mentions "alias," it means a CNAME record, not a Route 53 alias record.)

**Example for the Amazon Route 53 console**

```
10 mail.example.com
```

**Example for the Route 53 API**

```
<Value>10 mail.example.com</Value>
```

## NAPTR record type
<a name="NAPTRFormat"></a>

A Name Authority Pointer (NAPTR) is a type of record that is used by Dynamic Delegation Discovery System (DDDS) applications to convert one value to another or to replace one value with another. For example, one common use is to convert phone numbers into SIP URIs. 

The `Value` element for an NAPTR record consists of six space-separated values:

**Order**  
When you specify more than one record, the sequence that you want the DDDS application to evaluate records in. Valid values: 0-65535.

**Preference**  
When you specify two or more records that have the same **Order**, your preference for the sequence that those records are evaluated in. For example, if two records have an **Order** of 1, the DDDS application first evaluates the record that has the lower **Preference**. Valid values: 0-65535.

**Flags**  
A setting that is specific to DDDS applications. Values currently defined in [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt) are uppercase- and lowercase letters **"A"**, **"P"**, **"S"**, and **"U"**, and the empty string, **""**. Enclose **Flags** in quotation marks. 

**Service**  
A setting that is specific to DDDS applications. Enclose **Service** in quotation marks.  
For more information, see the applicable RFCs:  
+ **URI DDDS application** – [https://tools.ietf.org/html/rfc3404\$1section-4.4](https://tools.ietf.org/html/rfc3404#section-4.4)
+ **S-NAPTR DDDS application** – [https://tools.ietf.org/html/rfc3958\$1section-6.5](https://tools.ietf.org/html/rfc3958#section-6.5)
+ **U-NAPTR DDDS application** – [https://tools.ietf.org/html/rfc4848\$1section-4.5](https://tools.ietf.org/html/rfc4848#section-4.5)

**Regexp**  
A regular expression that the DDDS application uses to convert an input value into an output value. For example, an IP phone system might use a regular expression to convert a phone number that is entered by a user into a SIP URI. Enclose **Regexp** in quotation marks. Specify either a value for **Regexp** or a value for **Replacement**, but not both.  
The regular expression can include any of the following printable ASCII characters:  
+ a-z
+ 0-9
+ - (hyphen)
+ (space)
+ \$1 \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ ] ^ \$1 ` \$1 \$1 \$1 \$1 .
+ " (quotation mark). To include a literal quote in a string, precede it with a \$1 character: \$1".
+ \$1 (backslash). To include a backslash in a string, precede it with a \$1 character: \$1\$1.
Specify all other values, such as internationalized domain names, in octal format.  
For the syntax for **Regexp**, see [RFC 3402, section 3.2, Substitution Expression Syntax](https://tools.ietf.org/html/rfc3402#section-3.2)

**Replacement**  
The fully qualified domain name (FQDN) of the next domain name that you want the DDDS application to submit a DNS query for. The DDDS application replaces the input value with the value that you specify for **Replacement**, if any. Specify either a value for **Regexp** or a value for **Replacement**, but not both. If you specify a value for **Regexp**, specify a dot (**.**) for **Replacement**.  
The domain name can include a-z, 0-9, and - (hyphen).

For more information about DDDS applications and about NAPTR records, see the following RFCs:
+ [RFC 3401](https://www.ietf.org/rfc/rfc3401.txt)
+ [RFC 3402](https://www.ietf.org/rfc/rfc3402.txt)
+ [RFC 3403](https://www.ietf.org/rfc/rfc3403.txt)
+ [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt)

**Example for the Amazon Route 53 console**

```
100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .
100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .
100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .
```

**Example for the Route 53 API**

```
<ResourceRecord>
   <Value>100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .</Value>
   <Value>100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .</Value>
   <Value>100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .</Value>
</ResourceRecord>
```

## NS record type
<a name="NSFormat"></a>

An NS record identifies the name servers for the hosted zone. Note the following:
+ The most common use for an NS record is to control how internet traffic is routed for a domain. To use the records in a hosted zone to route traffic for a domain, you update the domain registration settings to use the four name servers in the default NS record. (This is the NS record that has the same name as the hosted zone.)
+ You can create a separate hosted zone for a subdomain (acme.example.com) and use that hosted zone to route internet traffic for the subdomain and its subdomains (subdomain.acme.example.com). You set up this configuration, known as "delegating responsibility for a subdomain to a hosted zone" by creating another NS record in the hosted zone for the root domain (example.com). For more information, see [Routing traffic for subdomains](dns-routing-traffic-for-subdomains.md).
+ You also use NS records to configure white-label name servers. For more information, see [Configuring white-label name servers](white-label-name-servers.md).
+ Another use for an NS record is for private hosted zones when you create a delegate rule to delegate the authority for a subdomain to your on-premises resolver. You must create this NS record before you create a delegate rule. For more information, see [How Resolver endpoints forward DNS queries from your VPCs to your network](resolver-overview-forward-vpc-to-network.md).

For more information about NS records, see [NS and SOA records that Amazon Route 53 creates for a public hosted zone](SOA-NSrecords.md).

**Example for the Amazon Route 53 console**

```
ns-1.example.com
```

**Example for the Route 53 API**

```
<Value>ns-1.example.com</Value>
```

## PTR record type
<a name="PTRFormat"></a>

A PTR record maps an IP address to the corresponding domain name.

**Example for the Amazon Route 53 console**

```
hostname.example.com
```

**Example for the Route 53 API**

```
<Value>hostname.example.com</Value>
```

## SOA record type
<a name="SOAFormat"></a>

A start of authority (SOA) record provides information about a domain and the corresponding Amazon Route 53 hosted zone. For information about the fields in an SOA record, see [NS and SOA records that Amazon Route 53 creates for a public hosted zone](SOA-NSrecords.md).

**Example for the Route 53 console**

```
ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60
```

**Example for the Route 53 API**

```
<Value>ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60</Value>
```

## SPF record type
<a name="SPFFormat"></a>

SPF records were formerly used to verify the identity of the sender of email messages. However, we no longer recommend that you create records for which the record type is SPF. RFC 7208, *Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1*, has been updated to say, "...[I]ts existence and mechanism defined in [RFC4408] have led to some interoperability issues. Accordingly, its use is no longer appropriate for SPF version 1; implementations are not to use it." In RFC 7208, see section 14.1, [The SPF DNS Record Type](http://tools.ietf.org/html/rfc7208#section-14.1).

Instead of an SPF record, we recommend that you create a TXT record that contains the applicable value. For more information about valid values, see the Wikipedia article [Sender Policy Framework](https://en.wikipedia.org/wiki/Sender_Policy_Framework).

**Example for the Amazon Route 53 console**

```
"v=spf1 ip4:192.168.0.1/16 -all"
```

**Example for the Route 53 API**

```
<Value>"v=spf1 ip4:192.168.0.1/16 -all"</Value>
```

## SRV record type
<a name="SRVFormat"></a>

An SRV record `Value` element consists of four space-separated values. The first three values are decimal numbers representing priority, weight, and port. The fourth value is a domain name. SRV records are used for accessing services, such as a service for email or communications. For information about SRV record format, refer to the documentation for the service that you want to connect to.

**Example for the Amazon Route 53 console**

```
10 5 80 hostname.example.com
```

**Example for the Route 53 API**

```
<Value>10 5 80 hostname.example.com</Value>
```

## SSHFP record type
<a name="SSHFPFormat"></a>

A Secure Shell fingerprint record (SSHFP) identifies SSH keys associated with the domain name. SSHFP records must be secured with DNSSEC for a chain of trust to be established. For more information about DNSSEC, see [Configuring DNSSEC signing in Amazon Route 53](dns-configuring-dnssec.md)

The format for an SSHFP resource record is:

`[Key Algorithm] [Hash Type] Fingerprint`

The following parameters are defined in [RFC 4255](https://datatracker.ietf.org/doc/html/rfc4255).

**Key Algorithm**  
Algorithm type:  
+ `0` – Reserved and not used.
+ `1: RSA` – Rivest–Shamir–Adleman algorithm is one of the first public-key cryptosystems and is still in use for secure data transmission.
+ `2: DSA` – Digital Signature Algorithm is a Federal Information Processing Standard for digital signatures. DSA is based on modular exponentiation and the discrete logarithm mathematical models.
+ `3: ECDSA` – Elliptic Curve Digital Signature Algorithm is a variant of the DSA that uses elliptic curve cryptography.
+ `4: Ed25519` – Ed25519 algorithm is the EdDSA signature scheme that uses SHA-512 (SHA-2) and Curve25519.
+ `6: Ed448` – Ed448 is the EdDSA signature scheme that uses SHAKE256 and Curve448.

**Hash Type**  
Algorithm used to create the public key hash:  
+ `0` –Reserved and not used.
+ `1: SHA-1`
+ `2: SHA-256`

**Fingerprint**  
Hexadecimal representation of the hash.

**Example for the Amazon Route 53 console**

```
1 1 09F6A01D2175742B257C6B98B7C72C44C4040683
```

**Example for the Route 53 API**

```
<Value>1 1 09F6A01D2175742B257C6B98B7C72C44C4040683</Value>
```

For more information, see [RFC 4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints](https://datatracker.ietf.org/doc/html/rfc4255).

## SVCB record type
<a name="SVCBFormat"></a>

You use an SVCB record to deliver configuration information for accessing service endpoints. The SVCB is a generic DNS record and can be used to negotiate parameters for a variety of application protocols.

The format for an SVCB resource record is:

`SvcPriority TargetName SvcParams(optional)`

The following parameters are described in [RFC 9460, section 2.3](https://www.rfc-editor.org/rfc/rfc9460.html#section-2.3).

**SvcPriority**  
An integer that represents the priority. 0 priority means alias mode, and is generally intended for aliasing at the zone apex. Lower the priority, higher the preference. 

**TargetName**  
The domain name of either the alias target (for alias mode) or the alternate endpoint (for ServiceMode).

**SvcParams (optional)**  
 A whitespace-separated list, with each parameter consisting of a Key=Value pair or a standalone key. If there is more than one value, they are presented as a comma-separated list. This value is an integer 0-32767 for Route 53 of which 1-32767 are service mode records. The following are the defined SvcParams:  
+ `1:alpn` – Application Layer Protocol Negotiation Protocol IDs. Default is HTTP/1.1, `h2` is HTTP/2 over TLS, and `h3` is HTTP/3 (HTTP over QUIC protocol). 
+ `2:no-default-alpn` – The default is not supported and you must provide an `alpn` parameter.
+ `3:port` – the port for the alternate endpoint where the service can be reached. 
+ `4:ipv4hint` – IPv4 address hints.
+ `5:ech` – Encrypted Client Hello.
+ `6:ipv6hint` – IPv6 address hints.
+ `7:dohpath` – DNS over HTTPS template
+ `8:ohttp` – The service operates an Oblivious HTTP target

**Example for the Amazon Route 53 console for alias mode**

```
0 example.com
```

**Example for the Amazon Route 53 console for service mode**

```
16 example.com alpn="h2,h3" port=808
```

**Example for the Amazon Route 53 API for alias mode**

```
<Value>0 example.com</Value>
```

**Example for the Route 53 API for service mode**

```
<Value>16 example.com alpn="h2,h3" port=808</Value>
```

For more information, see [RFC 9460, Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)](https://datatracker.ietf.org/doc/html/rfc9460).

**Note**  
Route 53 does not support the arbitrary unknown-key presentation format `keyNNNNN`

## TLSA record type
<a name="TLSAFormat"></a>

You use a TLSA record to use DNS-Based Authentication of Named Entities (DANE). A TLSA record associates a certificate/public key with a Transport Layer Security (TLS) endpoint, and clients can validate the certificate/public key using a TLSA record signed with DNSSEC.

TLSA records can only be trusted if DNSSEC is enabled on your domain. For more information about DNSSEC, see [Configuring DNSSEC signing in Amazon Route 53](dns-configuring-dnssec.md)

The format for a TLSA resource record is:

`[Certificate usage] Selector [Matching type] [Certificate association data]`

The following parameters are specified in [RFC 6698, section 3](https://datatracker.ietf.org/doc/html/rfc6698#section-3).

**Certificate usage**  
Specifies the provided association that will be used to match the certificate presented in the TLS handshake:  
+ 0: CA Constraint – The certificate or public key must be found in any of the Public Key Infrastructure (PKIX) certification paths for the end entity certificate provided by the server in TLS. This constraint limits which CAs can be used to issue certificates for a specified service.
+ 1: Service Certificate Constraint – Specifies an end entity certificate (or the public key) that must match with the end entity certificate given by the server in TLS. This certification limits which end entity certificate can be used by a specified service on a host.
+ 2: A trust Anchor Assertion – Specifies a certificate (or the public key) that must be used as the “trust anchor” when validating the end entity certificate given by the server in TLS. Allows a domain administrator to specify a trust anchor.
+ 3: Domain-Issued Certification – Specifies a certificate (or the public key) that must match the end entity certificate given by the server in TLS. This certification allows for a domain administrator to issue certificates for a domain without involving a third-party CA. This certificate does not need to pass PKIX validation.

**Selector**  
Specifies which part of the certificate presented by the server in the handshake is matched against the association value:  
+ 0: The entire certificate must be matched.
+ 1: The Subject Public Key, or the DER-encoded binary structure, must be matched.

**Matching type**  
Specifies the presentation (as determined by the Selector field) of the certificate match:  
+ 0: Exact match of the content.
+ 1: SHA-256 hash.
+ 2: SHA-512 hash.

**Certificate association data**  
The data to be matched based on the settings of the other fields.

**Example for the Amazon Route 53 console**

```
0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971
```

**Example for the Route 53 API**

```
<Value>0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971</Value>
```

For more information, see [RFC 6698, The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA](https://datatracker.ietf.org/doc/html/rfc6698).

## TXT record type
<a name="TXTFormat"></a>

A TXT record contains one or more strings that are enclosed in double quotation marks (`"`). When you use the simple [routing policy](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html), include all values for a domain (example.com) or subdomain (www.example.com) in the same TXT record.

**Topics**
+ [

### Entering TXT record values
](#TXTformat-limits)
+ [

### Special characters in a TXT record value
](#TXTformat-special-characters)
+ [

### Uppercase and lowercase in a TXT record value
](#TXTformat-case)
+ [

### Examples
](#TXTformat-examples)

### Entering TXT record values
<a name="TXTformat-limits"></a>

A single string can include up to 255 characters, including the following:
+ a-z
+ A-Z
+ 0-9
+ Space
+ - (hyphen)
+ \$1 " \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ \$1 ] ^ \$1 ` \$1 \$1 \$1 \$1 . 

If you need to enter a value longer than 255 characters, break the value into strings of 255 characters or fewer, and enclose each string in double quotation marks (`"`). In the console, list all the strings on the same line:

```
"String 1" "String 2" "String 3"
```

For the API, include all the strings in the same `Value` element:

```
<Value>"String 1" "String 2" "String 3"</Value>
```

The maximum length of a value in a TXT record is 4,000 characters. 

To enter more than one TXT value, enter one value per row.

### Special characters in a TXT record value
<a name="TXTformat-special-characters"></a>

If your TXT record contains any of the following characters, you must specify the characters by using escape codes in the format `\`*three-digit octal code*:
+ Characters 000 to 040 octal (0 to 32 decimal, 0x00 to 0x20 hexadecimal)
+ Characters 177 to 377 octal (127 to 255 decimal, 0x7F to 0xFF hexadecimal)

For example, if the value of your TXT record is `"exämple.com"`, you specify `"ex\344mple.com"`.

For a mapping between ASCII characters and octal codes, perform an internet search for "ASCII octal codes." One useful reference is [ASCII Code - The extended ASCII table](https://www.ascii-code.com/). 

To include a quotation mark (`"`) in a string, put a backslash (`\`) character before the quotation mark: `\"`. 

### Uppercase and lowercase in a TXT record value
<a name="TXTformat-case"></a>

Case is preserved, so `"Ab"` and `"aB"` are different values.

### Examples
<a name="TXTformat-examples"></a>

**Example for the Amazon Route 53 console**

Put each value on a separate line:

```
"This string includes \"quotation marks\"."
"The last character in this string is an accented e specified in octal format: \351"
"v=spf1 ip4:192.168.0.1/16 -all"
```

**Example for the Route 53 API**

Put each value in a separate `Value` element:

```
<Value>"This string includes \"quotation marks\"."</Value>
<Value>"The last character in this string is an accented e specified in octal format: \351"</Value>
<Value>"v=spf1 ip4:192.168.0.1/16 -all"</Value>
```

# Creating records by using the Amazon Route 53 console
<a name="resource-record-sets-creating"></a>

The following procedure explains how to create records using the Amazon Route 53 console. For information about how to create records using the Route 53 API, see [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) in the *Amazon Route 53 API Reference*.

**Note**  
To create records for complex routing configurations, you can also use the Traffic Flow visual editor and save the configuration as a traffic policy. You can then associate the traffic policy with one or more domain names (such as example.com) or subdomain names (such as www.example.com), in the same hosted zone or in multiple hosted zones. In addition, you can roll back the updates if the new configuration isn't performing as you expected it to. For more information, see [Using Traffic Flow to route DNS traffic](traffic-flow.md).<a name="resource-record-sets-creating-procedure"></a>

**To create a record using the Route 53 console**

1. If you're not creating an alias record, go to step 2. 

   Also go to step 2 if you're creating an alias record that routes DNS traffic to an AWS resource other than an Elastic Load Balancing load balancer or another Route 53 record.

   If you're creating an alias record that routes traffic to an Elastic Load Balancing load balancer, and if you created your hosted zone and your load balancer using different accounts, perform the procedure [Getting the DNS name for an Elastic Load Balancing load balancer](#resource-record-sets-elb-dns-name-procedure) to get the DNS name for the load balancer. 

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. If you already have a hosted zone for your domain, skip to step 5. If you don't, perform the applicable procedure to create a hosted zone:
   + To route internet traffic to your resources, such as Amazon S3 buckets or Amazon EC2 instances, see [Creating a public hosted zone](CreatingHostedZone.md).
   + To route traffic in your VPC, see [Creating a private hosted zone](hosted-zone-private-creating.md).

1. On the **Hosted zones** page, choose the name of the hosted zone that you want to create records in.

1. Choose **Create record**.

1. Choose and define the applicable routing policy and values. For more information, see the topic for the kind of record that you want to create:
   + [Values that are common for all routing policies](resource-record-sets-values-shared.md)
   + [Values that are common for alias records for all routing policies](resource-record-sets-values-alias-common.md)
   + [Values specific for simple records](resource-record-sets-values-basic.md)
   + [Values specific for simple alias records](resource-record-sets-values-alias.md)
   + [Values specific for failover records](resource-record-sets-values-failover.md)
   + [Values specific for failover alias records](resource-record-sets-values-failover-alias.md)
   + [Values specific for geolocation records](resource-record-sets-values-geo.md)
   + [Values specific for geolocation alias records](resource-record-sets-values-geo-alias.md)
   + [Values specific for geoproximity records](resource-record-sets-values-geoprox.md)
   + [Values specific for geoproximity alias records](resource-record-sets-values-geoprox-alias.md)
   + [Values specific for latency records](resource-record-sets-values-latency.md)
   + [Values specific for latency alias records](resource-record-sets-values-latency-alias.md)
   + [Values specific for IP-based records](resource-record-sets-values-ipbased.md)
   + [Values specific for IP-based alias records](resource-record-sets-values-ipbased-alias.md)
   + [Values specific for multivalue answer records](resource-record-sets-values-multivalue.md)
   + [Values specific for weighted records](resource-record-sets-values-weighted.md)
   + [Values specific for weighted alias records](resource-record-sets-values-weighted-alias.md)

1. Choose **Create records**.
**Note**  
Your new records take time to propagate to the Route 53 DNS servers. Currently, the only way to verify that changes have propagated is to use the [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API action. Changes generally propagate to all Route 53 name servers within 60 seconds.

1. If you're creating multiple records, repeat steps 7 through 8.<a name="resource-record-sets-elb-dns-name-procedure"></a>

**Getting the DNS name for an Elastic Load Balancing load balancer**

1. Sign in to the AWS Management Console using the AWS account that was used to create the Classic, Application, or Network Load Balancer that you want to create an alias record for.

1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. In the navigation pane, choose **Load Balancers**.

1. In the list of load balancers, select the load balancer for which you want to create an alias record.

1. On the **Description** tab, get the value of **DNS name**.

1. If you want to create alias records for other Elastic Load Balancing load balancers, repeat steps 4 and 5. 

1. Sign out of the AWS Management Console.

1. Sign in to the AWS Management Console again using the AWS account that you used to create the Route 53 hosted zone.

1. Return to step 3 of the procedure [Creating records by using the Amazon Route 53 console](#resource-record-sets-creating).

# Resource record set permissions
<a name="resource-record-sets-permissions"></a>

Resource record set permissions use Identity and Access management (IAM) policy conditions to allow you to set granular permissions for actions on the Route 53 console or for using the [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) API.

A resource record set is defined as multiple resource records with the same name and type (and class, but for most purposes the class is always IN, or internet), but they contain different data. For example, if you choose geolocation routing, you can have multiple A or AAAA records pointing to different endpoints for the same domain. All of these A or AAAA records combine to form a resource record set. For more information about DNS terminology, see [RFC 7719](https://datatracker.ietf.org/doc/html/rfc7719).

With the IAM policy conditions, `route53:ChangeResourceRecordSetsNormalizedRecordNames`, `route53:ChangeResourceRecordSetsRecordTypes`, and `route53:ChangeResourceRecordSetsActions`, you can grant granular administrative rights to other AWS users in any other AWS account. This allows you to grant someone permissions to:
+ A single resource record set.
+ All resource record sets of a specific DNS record type.
+ Resource record sets where the names contain a specific string.
+ Perform any, or all of the `CREATE | UPSERT | DELETE `actions when using the [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) API, or the Route 53 console.

You can also create access permissions that combine any of the Route 53 policy conditions. For example, you can grant someone permissions to modify the A record data for marketing-example.com, but not allow that user to delete any records. 

For more information about resource record set permissions and examples of how to use them, see [Using IAM policy conditions for fine-grained access control](specifying-conditions-route53.md).

To learn how to authenticate AWS users, see [Authenticating with identities](security-iam.md#security_iam_authentication) and to learn how to control access to Route 53 resources, see [Access control](security-iam.md#access-control).

# Values that you specify when you create or edit Amazon Route 53 records
<a name="resource-record-sets-values"></a>

When you create records using the Amazon Route 53 console, the values that you specify depend on the routing policy that you want to use and on whether you're creating alias records, which route traffic to AWS resources.

Alias records that route traffic to certain AWS resources for which you specify the target resource (for example, Elastic Load Balancing, CloudFront distribution, Amazon S3 bucket). You can also optionally associate health checks and configure target health evaluation. The following topics provide detailed information on the values required for each routing policy and record type, helping you configure your Route 53 records effectively.

**Topics**
+ [

# Values that are common for all routing policies
](resource-record-sets-values-shared.md)
+ [

# Values that are common for alias records for all routing policies
](resource-record-sets-values-alias-common.md)
+ [

# Values specific for simple records
](resource-record-sets-values-basic.md)
+ [

# Values specific for simple alias records
](resource-record-sets-values-alias.md)
+ [

# Values specific for failover records
](resource-record-sets-values-failover.md)
+ [

# Values specific for failover alias records
](resource-record-sets-values-failover-alias.md)
+ [

# Values specific for geolocation records
](resource-record-sets-values-geo.md)
+ [

# Values specific for geolocation alias records
](resource-record-sets-values-geo-alias.md)
+ [

# Values specific for geoproximity records
](resource-record-sets-values-geoprox.md)
+ [

# Values specific for geoproximity alias records
](resource-record-sets-values-geoprox-alias.md)
+ [

# Values specific for latency records
](resource-record-sets-values-latency.md)
+ [

# Values specific for latency alias records
](resource-record-sets-values-latency-alias.md)
+ [

# Values specific for IP-based records
](resource-record-sets-values-ipbased.md)
+ [

# Values specific for IP-based alias records
](resource-record-sets-values-ipbased-alias.md)
+ [

# Values specific for multivalue answer records
](resource-record-sets-values-multivalue.md)
+ [

# Values specific for weighted records
](resource-record-sets-values-weighted.md)
+ [

# Values specific for weighted alias records
](resource-record-sets-values-weighted-alias.md)

# Values that are common for all routing policies
<a name="resource-record-sets-values-shared"></a>

These are the common values that you can specify when you create or edit Amazon Route 53 records. These values are used by all routing policies.



**Topics**
+ [

## Record name
](#rrsets-values-common-name)
+ [

## Value/Route traffic to
](#rrsets-values-common-value)
+ [

## TTL (seconds)
](#rrsets-values-common-ttl)

## Record name
<a name="rrsets-values-common-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Name** field. 

**CNAME records**  
If you're creating a record that has a value of **CNAME** for **Record type**, the name of the record can't be the same as the name of the hosted zone.

**Special characters**  
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).

**Wildcard characters**  
You can use an asterisk (\$1) character in the name. DNS treats the \$1 character either as a wildcard or as the \$1 character (ASCII 42), depending on where it appears in the name. For more information, see [Using an asterisk (\$1) in the names of hosted zones and records](DomainNameFormat.md#domain-name-format-asterisk).  
You can't use the \$1 wildcard for resource records sets that have a type of **NS**.

## Value/Route traffic to
<a name="rrsets-values-common-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

**A — IPv4 address**  
An IP address in IPv4 format, for example, **192.0.2.235**.

**AAAA — IPv6 address**  
An IP address in IPv6 format, for example, **2001:0db8:85a3:0:0:8a2e:0370:7334**.

**CAA — Certificate Authority Authorization**  
Three space-separated values that control which certificate authorities are allowed to issue certificates or wildcard certificates for the domain or subdomain that is specified by **Record name**. You can use CAA records to specify the following:  
+ Which certificate authorities (CAs) can issue SSL/TLS certificates, if any
+ The email address or URL to contact when a CA issues a certificate for the domain or subdomain

**CNAME — Canonical name**  
The fully qualified domain name (for example, *www.example.com*) that you want Route 53 to return in response to DNS queries for this record. A trailing dot is optional; Route 53 assumes that the domain name is fully qualified. This means that Route 53 treats *www.example.com* (without a trailing dot) and *www.example.com.* (with a trailing dot) as identical.

**MX — Mail exchange**  
A priority and a domain name that specifies a mail server, for example, **10 mailserver.example.com**. The trailing dot is treated as optional.

**NAPTR — Name Authority Pointer**  
Six space-separated settings that are used by Dynamic Delegation Discovery System (DDDS) applications to convert one value to another or to replace one value with another. For more information, see [NAPTR record type](ResourceRecordTypes.md#NAPTRFormat).

**PTR — Pointer**  
The domain name that you want Route 53 to return.

**NS — Name server**  
The domain name of a name server, for example, **ns1.example.com**.  
You can specify an NS record with only simple routing policy.

**SPF — Sender Policy Framework**  
An SPF record enclosed in quotation marks, for example, **"v=spf1 ip4:192.168.0.1/16-all"**. SPF records are not recommended. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

**SRV — Service locator**  
An SRV record. SRV records are used for accessing services, such as a service for email or communications. For information about SRV record format, refer to the documentation for the service that you want to connect to. Trailing dot is treated as optional.  
The format of an SRV record is:  
**[priority] [weight] [port] [server host name]**  
For example:  
**1 10 5269 xmpp-server.example.com.**

**TXT — Text**  
A text record. Enclose text in quotation marks, for example, **"Sample text entry"**. 

## TTL (seconds)
<a name="rrsets-values-common-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

# Values that are common for alias records for all routing policies
<a name="resource-record-sets-values-alias-common"></a>

These are the common alias values that you can specify when you create or edit Amazon Route 53 records. These values are used by all routing policies.

**Topics**
+ [

## Record name
](#rrsets-values-common-alias-name)
+ [

## Value/route traffic to
](#rrsets-values-alias-common-target)

## Record name
<a name="rrsets-values-common-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Name** field. 

**CNAME records**  
If you're creating a record that has a value of **CNAME** for **Type**, the name of the record can't be the same as the name of the hosted zone.

**Aliases to CloudFront distributions and Amazon S3 buckets**  
The value that you specify depends in part on the AWS resource that you're routing traffic to:  
+ **CloudFront distribution** – Your distribution must include an alternate domain name that matches the name of the record. For example, if the name of the record is **acme.example.com**, your CloudFront distribution must include **acme.example.com** as one of the alternate domain names. For more information, see [Using alternate domain names (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) in the *Amazon CloudFront Developer Guide*. 
+ **Amazon S3 bucket** – The name of the record must match the name of your Amazon S3 bucket. For example, if the name of your bucket is **acme.example.com**, the name of this record must also be **acme.example.com**.

  In addition, you must configure the bucket for website hosting. For more information, see [Configure a bucket for website hosting](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) in the *Amazon Simple Storage Service User Guide*. 

**Special characters**  
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).

**Wildcard characters**  
You can use an asterisk (\$1) character in the name. DNS treats the \$1 character either as a wildcard or as the \$1 character (ASCII 42), depending on where it appears in the name. For more information, see [Using an asterisk (\$1) in the names of hosted zones and records](DomainNameFormat.md#domain-name-format-asterisk).

## Value/route traffic to
<a name="rrsets-values-alias-common-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

**Important**  
If you used the same AWS account to create your hosted zone and the resource that you're routing traffic to, and if your resource doesn't appear in the **Endpoint** list, check the following:  
Confirm that you chose a supported value for **Record type**. Supported values are specific to the resource that you're routing traffic to. For example, to route traffic to an S3 bucket, you must choose **A — IPv4 address** for **Record type**.
Confirm that the account has the IAM permissions that are required to list the applicable resources. For example, for CloudFront distributions to appear in the **Endpoint** list, the account must have permission to perform the following action: `cloudfront:ListDistributions`.  
For an example IAM policy, see [Permissions required to use the Amazon Route 53 console](access-control-managing-permissions.md#console-required-permissions).
If you used different AWS accounts to create the hosted zone and the resource, the **Endpoint** list doesn't display your resource. See the following documentation for your resource type to determine what value to type in **Endpoint**.

**API Gateway custom regional APIs and edge-optimized APIs**  
For API Gateway custom regional APIs and edge-optimized APIs, do one of the following:  
+ **If you used the same account to create your Route 53 hosted zone and your API** – Choose **Endpoint**, and then choose an API from the list. If you have a lot of APIs, you can enter the first few characters of the API endpoint to filter the list.
**Note**  
The name of this record must match a custom domain name for your API, such as **api.example.com**.
+ **If you used different accounts to create your Route 53 hosted zone and your API** – Enter the API endpoint for the API, such as **api.example.com**.

  If you used one AWS account to create the current hosted zone and a different account to create an API, the API won't appear in the **Endpoints** list under **API Gateway APIs**.

  If you used one account to create the current hosted zone and one or more different accounts to create all of your APIs, the **Endpoints** list shows **No targets available** under **API Gateway APIs**. For more information, see [Routing traffic to an Amazon API Gateway API by using your domain name](routing-to-api-gateway.md).

**CloudFront distributions**  
For CloudFront distributions, do one of the following:  
+ **If you used the same account to create your Route 53 hosted zone and your CloudFront distribution** – Choose **Endpoint** and choose a distribution from the list. If you have a lot of distributions, you can enter the first few characters of the domain name for your distribution to filter the list.

  If your distribution doesn't appear in the list, note the following:
  + The name of this record must match an alternate domain name in your distribution.
  + If you just added an alternate domain name to your distribution, it may take 15 minutes for your changes to propagate to all CloudFront edge locations. Until changes have propagated, Route 53 can't know about the new alternate domain name.
+ **If you used different accounts to create your Route 53 hosted zone and your distribution** – Enter the CloudFront domain name for the distribution, such as **d111111abcdef8.cloudfront.net**.

  If you used one AWS account to create the current hosted zone and a different account to create a distribution, the distribution will not appear in the **Endpoints** list.

  If you used one account to create the current hosted zone and one or more different accounts to create all of your distributions, the **Endpoints** list shows **No targets available** under **CloudFront distributions**.
Do not route queries to a CloudFront distribution that has not propagated to all edge locations, or your users won't be able to access the applicable content. 
Your CloudFront distribution must include an alternate domain name that matches the name of the record. For example, if the name of the record is **acme.example.com**, your CloudFront distribution must include **acme.example.com** as one of the alternate domain names. For more information, see [Using alternate domain names (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) in the *Amazon CloudFront Developer Guide*.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Record type**, and one with a value of **AAAA — IPv6 address**. For more information, see [Routing traffic to an Amazon CloudFront distribution by using your domain name](routing-to-cloudfront-distribution.md).

**App Runner service**  
For App Runner service, do one of the following:  
+ **If you used the same account to create your Route 53 hosted zone and your App Runner service** – choose the AWS Region, then choose the domain name of the environment that you want to route traffic to from the list.
+ **If you used different accounts to create your Route 53 hosted zone and your App Runner** – Enter the custom domain name. For more information, see [Managing custom domain names for App Runner](https://docs.aws.amazon.com/apprunner/latest/dg/manage-custom-domains.html).

  If you used one AWS account to create the current hosted zone and a different account to create a App Runner, the App Runner will not appear in the **Endpoints** list.
For more information, see [Configuring Amazon Route 53 to route traffic to an App Runner service](routing-to-app-runner.md#routing-to-app-runner-configuring).

**Elastic Beanstalk environments that have regionalized subdomains**  
If the domain name for your Elastic Beanstalk environment includes the Region that you deployed the environment in, you can create an alias record that routes traffic to the environment. For example, the domain name `my-environment.us-west-2.elasticbeanstalk.com` is a regionalized domain name.  
For environments that were created before early 2016, the domain name doesn't include the Region. To route traffic to these environments, you must create a CNAME record instead of an alias record. Note that you can't create a CNAME record for the root domain name. For example, if your domain name is example.com, you can create a record that routes traffic for acme.example.com to your Elastic Beanstalk environment, but you can't create a record that routes traffic for example.com to your Elastic Beanstalk environment.
For Elastic Beanstalk environments that have regionalized subdomains, do one of the following:  
+ **If you used the same account to create your Route 53 hosted zone and your Elastic Beanstalk environment** – Choose **Endpoint**, and then choose an environment from the list. If you have a lot of environments, you can enter the first few characters of the CNAME attribute for the environment to filter the list.
+ **If you used different accounts to create your Route 53 hosted zone and your Elastic Beanstalk environment** – Enter the CNAME attribute for the Elastic Beanstalk environment.
For more information, see [Routing traffic to an AWS Elastic Beanstalk environment](routing-to-beanstalk-environment.md).

**ELB Load Balancers**  
For ELB load balancers, do one of the following:  
+ **If you used the same account to create your Route 53 hosted zone and your load balancer** – Choose **Endpoint** and choose a load balancer from the list. If you have a lot of load balancers, you can enter the first few characters of the DNS name to filter the list.
+ **If you used different accounts to create your Route 53 hosted zone and your load balancer** – Enter the value that you got in the procedure [Getting the DNS name for an Elastic Load Balancing load balancer](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure).

  If you used one AWS account to create the current hosted zone and a different account to create a load balancer, the load balancer will not appear in the **Endpoints** list.

  If you used one account to create the current hosted zone and one or more different accounts to create all of your load balancers, the **Endpoints** list shows **No targets available** under **Elastic Load Balancers**.
The console prepends **dualstack.** for Application and Classic Load Balancer from a different account. When a client, such as a web browser, requests the IP address for your domain name (example.com) or subdomain name (www.example.com), the client can request an IPv4 address (an A record), an IPv6 address (a AAAA record), or both IPv4 and IPv6 addresses (in separate requests). The **dualstack.** designation allows Route 53 to respond with the appropriate IP address for your load balancer based on which IP address format the client requested.  
For more information, see [Routing traffic to an ELB load balancer](routing-to-elb-load-balancer.md).

**AWS Global Accelerator accelerators**  
For AWS Global Accelerator accelerators, enter the DNS name for the accelerator. You can enter the DNS name of an accelerator that you created using the current AWS account or using a different AWS account. 

**Amazon S3 Buckets**  
For Amazon S3 buckets that are configured as website endpoints, do one of the following:  
+ **If you used the same account to create your Route 53 hosted zone and your Amazon S3 bucket** – Choose **Endpoint** and choose a bucket from the list. If you have a lot of buckets, you can enter the first few characters of the DNS name to filter the list.

  The value of **Endpoint** changes to the Amazon S3 website endpoint for your bucket.
+ **If you used different accounts to create your Route 53 hosted zone and your Amazon S3 bucket** – Enter the name of the Region that you created your S3 bucket in. Use the value that appears in the **Website endpoint** column in the table [Amazon S3 website endpoints](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints) in the *Amazon Web Services General Reference*.

  If you used AWS accounts other than the current account to create your Amazon S3 buckets, the bucket won't appear in the **Endpoints** list.
You must configure the bucket for website hosting. For more information, see [Configure a bucket for website hosting](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) in the *Amazon Simple Storage Service User Guide*.  
The name of the record must match the name of your Amazon S3 bucket. For example, if the name of your Amazon S3 bucket is **acme.example.com**, the name of this record must also be **acme.example.com**.  
In a group of weighted alias, latency alias, failover alias, or geolocation alias records, you can create only one record that routes queries to an Amazon S3 bucket because the name of the record must match the name of the bucket and bucket names must be globally unique.

**Amazon OpenSearch Service**  
For OpenSearch Service, do one of the following:  
+ **OpenSearch Service custom domain**: The name of the record must match the custom domain. For example, if the name of your custom domain is test.example.com, the name of this record must also be test.example.com.
+ **If you used the same account to create your Route 53 hosted zone and your OpenSearch Service domain** – choose the AWS Region, then choose the domain name.
+ **If you used different accounts to create your Route 53 hosted zone and your OpenSearch Service domain** – Enter the custom domain name. For more information, see [Create a custom endpoint](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/customendpoint.html).

  If you used one AWS account to create the current hosted zone and a different account to create a OpenSearch Service domain, the domain will not appear in the **Endpoints** list.

  If you used one account to create the current hosted zone and one or more different accounts to create all of your OpenSearch Service domains, the **Endpoints** list shows **No targets available** under **OpenSearch Service**.
For more information, see [Configuring Amazon Route 53 to route traffic to an Amazon OpenSearch Service domain endpoint](routing-to-open-search-service.md#routing-to-open-search-service-configuring).

**Amazon VPC interface endpoints**  
For Amazon VPC interface endpoints, do one of the following:  
+ **If you used the same account to create your Route 53 hosted zone and your interface endpoint** – Choose **Endpoint**, and then choose an interface endpoint from the list. If you have a lot of interface endpoints, you can enter the first few characters of the DNS hostname to filter the list.
+ **If you used different accounts to create your Route 53 hosted zone and your interface endpoint** – Enter the DNS hostname for the interface endpoint, such as **vpce-123456789abcdef01-example-us-east-1a.elasticloadbalancing.us-east-1.vpce.amazonaws.com**.

  If you used one AWS account to create the current hosted zone and a different account to create an interface endpoint, the interface endpoint won't appear in the **Endpoint** list under **VPC endpoints**.

  If you used one account to create the current hosted zone and one or more different accounts to create all of your interface endpoints, the **Endpoint** list shows **No targets available** under **VPC endpoints**.

  For more information, see [Routing traffic to an Amazon Virtual Private Cloud interface endpoint by using your domain name](routing-to-vpc-interface-endpoint.md).

**Records in this Hosted Zone**  
For records in this hosted zone, choose **Endpoint** and choose the applicable record. If you have a lot of records, you can enter the first few characters of the name to filter the list.  
If the hosted zone contains only the default NS and SOA records, the **Endpoints** list shows **No targets available**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't choose a record for which the value of **Record type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

# Values specific for simple records
<a name="resource-record-sets-values-basic"></a>

When you create simple records, you specify the following values.

**Topics**
+ [

## Routing policy
](#rrsets-values-basic-routing-policy)
+ [

## Record name
](#rrsets-values-basic-name)
+ [

## Value/Route traffic to
](#rrsets-values-basic-value)
+ [

## Record type
](#rrsets-values-basic-type)
+ [

## TTL (seconds)
](#rrsets-values-basic-ttl)

## Routing policy
<a name="rrsets-values-basic-routing-policy"></a>

Choose **Simple routing**.

## Record name
<a name="rrsets-values-basic-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Name** field. 

For more information about record names, see [Record name](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Value/Route traffic to
<a name="rrsets-values-basic-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **CNAME — Canonical name**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **NS — Name server**

  The domain name of a name server, for example, **ns1.example.com**.
**Note**  
You can specify an NS record with only simple routing policy.
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Record type
<a name="rrsets-values-basic-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the value for **Record type** based on how you want Route 53 to respond to DNS queries. 

## TTL (seconds)
<a name="rrsets-values-basic-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

# Values specific for simple alias records
<a name="resource-record-sets-values-alias"></a>

When you create alias records, you specify the following values. For more information, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Note**  
If you are using Route 53 in the AWS GovCloud (US) Region, this feature has some restrictions. For more information, see the [Amazon Route 53 page](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-r53.html) in the *AWS GovCloud (US) User Guide*.

**Topics**
+ [

## Routing policy
](#rrsets-values-alias-routing-policy)
+ [

## Record name
](#rrsets-values-alias-name)
+ [

## Value/route traffic to
](#rrsets-values-alias-alias-target)
+ [

## Record type
](#rrsets-values-alias-type)
+ [

## Evaluate target health
](#rrsets-values-alias-evaluate-target-health)

## Routing policy
<a name="rrsets-values-alias-routing-policy"></a>

Choose **Simple routing**.

## Record name
<a name="rrsets-values-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Name** field. 

For more information about record names, see [Record name](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).

## Value/route traffic to
<a name="rrsets-values-alias-alias-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For information about what AWS resources you can target, see [common values for alias records for value/route traffic to](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

## Record type
<a name="rrsets-values-alias-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the applicable value based on the AWS resource that you're routing traffic to:

**API Gateway custom regional API or edge-optimized API**  
Select **A — IPv4 address**.

**Amazon VPC interface endpoints**  
Select **A — IPv4 address**.

**CloudFront distribution**  
Select **A — IPv4 address**.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Type**, and one with a value of **AAAA — IPv6 address**.

**App Runner service**  
Select **A — IPv4 address**

**Elastic Beanstalk environment that has regionalized subdomains**  
Select **A — IPv4 address**

**ELB load balancer**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Amazon S3 bucket**  
Select **A — IPv4 address**

**OpenSearch Service**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Another record in this hosted zone**  
Select the type of the record that you're creating the alias for. All types are supported except **NS** and **SOA**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't route traffic to a record for which the value of **Type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

## Evaluate target health
<a name="rrsets-values-alias-evaluate-target-health"></a>

When the value of **Routing policy** is **Simple**, you can choose either **No** or the default **Yes** because **Evaluate target health** has no effect for **Simple** routing. If you have only one record that has a given name and type, Route 53 responds to DNS queries by using the values in that record regardless of whether the resource is healthy.

For other routing policies, **Evaluate target health** determines whether Route 53 checks the health of the resource that the alias record refers to:
+ **Services where Evaluate target health provides operational benefit**: For load balancers (ELB) and AWS Elastic Beanstalk environments with load balancers, setting **Evaluate target health** to **Yes** allows Route 53 to route traffic away from unhealthy resources.
+ **Highly available services**: For services like Amazon S3 buckets, VPC interface endpoints, Amazon API Gateway, AWS Global Accelerator, Amazon OpenSearch Service, and Amazon VPC Lattice, **Evaluate target health** provides no operational benefit because these services are designed for high availability. For failover scenarios with these services, use [Route 53 health checks](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html) instead.

For detailed information about how **Evaluate target health** works with different AWS services, see the [ EvaluateTargetHealth](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AliasTarget.html#Route53-Type-AliasTarget-EvaluateTargetHealth) documentation in the API reference.

# Values specific for failover records
<a name="resource-record-sets-values-failover"></a>

When you create failover records, you specify the following values.

**Note**  
For information about creating failover records in a private hosted zone, see [Configuring failover in a private hosted zone](dns-failover-private-hosted-zones.md).

**Topics**
+ [

## Routing policy
](#rrsets-values-failover-routing-policy)
+ [

## Record name
](#rrsets-values-failover-name)
+ [

## Record type
](#rrsets-values-failover-type)
+ [

## TTL (seconds)
](#rrsets-values-failover-ttl)
+ [

## Value/Route traffic to
](#rrsets-values-failover-value)
+ [

## Failover record type
](#rrsets-values-failover-record-type)
+ [

## Health check
](#rrsets-values-failover-associate-with-health-check)
+ [

## Record ID
](#rrsets-values-failover-set-id)

## Routing policy
<a name="rrsets-values-failover-routing-policy"></a>

Choose **Failover**. 

## Record name
<a name="rrsets-values-failover-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for both of the records in the group of failover records. 

For more information about record names, see [Record name](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Record type
<a name="rrsets-values-failover-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the same value for both the primary and secondary failover records.

## TTL (seconds)
<a name="rrsets-values-failover-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

## Value/Route traffic to
<a name="rrsets-values-failover-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **CNAME — Canonical name**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Failover record type
<a name="rrsets-values-failover-record-type"></a>

Choose the applicable value for this record. For failover to function correctly, you must create one primary and one secondary failover record.

You can't create non-failover records that have the same values for **Record name** and **Record type** as failover records.

## Health check
<a name="rrsets-values-failover-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate Target Health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain Name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain Name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Record ID
<a name="rrsets-values-failover-set-id"></a>

Enter a value that uniquely identifies the primary and secondary records. 

# Values specific for failover alias records
<a name="resource-record-sets-values-failover-alias"></a>

When you create failover alias records, you specify the following values.

For information, see the following topics:
+ For information about creating failover records in a private hosted zone, see [Configuring failover in a private hosted zone](dns-failover-private-hosted-zones.md).
+ For information about alias records, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [

## Routing policy
](#rrsets-values-failover-alias-routing-policy)
+ [

## Record name
](#rrsets-values-failover-alias-name)
+ [

## Record type
](#rrsets-values-failover-alias-type)
+ [

## Value/Route traffic to
](#rrsets-values-failover-alias-alias-target)
+ [

## Failover record type
](#rrsets-values-failover-alias-failover-record-type)
+ [

## Health check
](#rrsets-values-failover-alias-associate-with-health-check)
+ [

## Evaluate target health
](#rrsets-values-failover-alias-evaluate-target-health)
+ [

## Record ID
](#rrsets-values-failover-alias-set-id)

## Routing policy
<a name="rrsets-values-failover-alias-routing-policy"></a>

Choose **Failover**. 

## Record name
<a name="rrsets-values-failover-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for both of the records in the group of failover records. 

For more information about record names, see [Record name](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).

## Record type
<a name="rrsets-values-failover-alias-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the applicable value based on the AWS resource that you're routing traffic to. Select the same value for both the primary and secondary failover records:

**API Gateway custom regional API or edge-optimized API**  
Select **A — IPv4 address**.

**Amazon VPC interface endpoints**  
Select **A — IPv4 address**.

**CloudFront distribution**  
Select **A — IPv4 address**.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Type**, and one with a value of **AAAA — IPv6 address**.

**App Runner service**  
Select **A — IPv4 address**

**Elastic Beanstalk environment that has regionalized subdomains**  
Select **A — IPv4 address**

**ELB load balancer**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Amazon S3 bucket**  
Select **A — IPv4 address**

**OpenSearch Service**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Another record in this hosted zone**  
Select the type of the record that you're creating the alias for. All types are supported except **NS** and **SOA**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't route traffic to a record for which the value of **Type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

## Value/Route traffic to
<a name="rrsets-values-failover-alias-alias-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For information about what AWS resources you can target, see [common values for alias records for value/route traffic to](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

**Note**  
When you create primary and secondary failover records, you can optionally create one failover and one failover *alias* record that have the same values for **Name** and **Record type**. If you mix failover and failover alias records, either one can be the primary record. 

## Failover record type
<a name="rrsets-values-failover-alias-failover-record-type"></a>

Choose the applicable value for this record. For failover to function correctly, you must create one primary and one secondary failover record.

You can't create non-failover records that have the same values for **Record name** and **Record type** as failover records.

## Health check
<a name="rrsets-values-failover-alias-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate Target Health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain Name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain Name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Evaluate target health
<a name="rrsets-values-failover-alias-evaluate-target-health"></a>

Select **Yes** if you want Route 53 to determine whether to respond to DNS queries using this record by checking the health of the resource specified by **Endpoint**. 

Note the following:

**API Gateway custom regional APIs and edge-optimized APIs**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an API Gateway custom regional API or an edge-optimized API.

**CloudFront distributions**  
You can't set **Evaluate target health** to **Yes** when the endpoint is a CloudFront distribution.

**Elastic Beanstalk environments that have regionalized subdomains**  
If you specify an Elastic Beanstalk environment in **Endpoint** and the environment contains an ELB load balancer, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. (An environment automatically contains an ELB load balancer if it includes more than one Amazon EC2 instance.) If you set **Evaluate target health** to **Yes** and either no Amazon EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other available resources that are healthy, if any.   
If the environment contains a single Amazon EC2 instance, there are no special requirements.

**ELB load balancers**  
Health checking behavior depends on the type of load balancer:  
+ **Classic load balancers** – If you specify an ELB Classic Load Balancer in **Endpoint**, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. If you set **Evaluate target health** to **Yes** and either no EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other resources.
+ **Application and Network Load Balancers** – If you specify an ELB Application or Network Load Balancer and you set **Evaluate Target health** to **Yes**, Route 53 routes queries to the load balancer based on the health of the target groups that are associated with the load balancer:
  + For an Application or Network Load Balancer to be considered healthy, a target group that contains targets must contain at least one healthy target. If any target group contains only unhealthy targets, the load balancer is considered unhealthy, and Route 53 routes queries to other resources.
  + A target group that has no registered targets is considered unhealthy.
When you create a load balancer, you configure settings for Elastic Load Balancing health checks; they're not Route 53 health checks, but they perform a similar function. Do not create Route 53 health checks for the EC2 instances that you register with an ELB load balancer. 

**S3 buckets**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an S3 bucket.

**Amazon VPC interface endpoints**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an Amazon VPC interface endpoint.

**Other records in the same hosted zone**  
If the AWS resource that you specify in **Endpoint** is a record or a group of records (for example, a group of weighted records) but is not another alias record, we recommend that you associate a health check with all of the records in the endpoint. For more information, see [What happens when you omit health checks?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## Record ID
<a name="rrsets-values-failover-alias-set-id"></a>

Enter a value that uniquely identifies the primary and secondary records. 

# Values specific for geolocation records
<a name="resource-record-sets-values-geo"></a>

When you create geolocation records, you specify the following values.

**Topics**
+ [

## Routing policy
](#rrsets-values-geo-routing-policy)
+ [

## Record name
](#rrsets-values-geo-name)
+ [

## Record type
](#rrsets-values-geo-type)
+ [

## TTL (seconds)
](#rrsets-values-geo-ttl)
+ [

## Value/Route traffic to
](#rrsets-values-geo-value)
+ [

## Location
](#rrsets-values-geo-location)
+ [

## U.S. states
](#rrsets-values-geo-sublocation)
+ [

## Health check
](#rrsets-values-geo-associate-with-health-check)
+ [

## Record ID
](#rrsets-values-geo-set-id)

## Routing policy
<a name="rrsets-values-geo-routing-policy"></a>

Choose **Geolocation**. 

## Record name
<a name="rrsets-values-geo-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Name** field. 

Enter the same name for all of the records in the group of geolocation records. 

For more information about record names, see [Record name](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Record type
<a name="rrsets-values-geo-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the same value for all of the records in the group of geolocation records.

## TTL (seconds)
<a name="rrsets-values-geo-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

## Value/Route traffic to
<a name="rrsets-values-geo-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **CNAME — Canonical name**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Location
<a name="rrsets-values-geo-location"></a>

When you configure Route 53 to respond to DNS queries based on the location that the queries originated from, select the continent or country for which you want Route 53 to respond with the settings in this record. If you want Route 53 to respond to DNS queries for individual states in the United States, select **United States** from the **Location** list, and then select the state under the **Sublocation** group.

For a private hosted zone, select the continent, country, or sub-division closest to the AWS Region that your resource is in. For example, if your resource is in us-east-1, you can specify North America, United States, or Virginia.

**Important**  
We recommend that you create one geolocation record that has a value of **Default** for **Location**. This covers geographic locations that you haven't created records for and IP addresses that Route 53 can't identify a location for.

You can't create non-geolocation records that have the same values for **Record name** and **Record type** as geolocation records.

For more information, see [Geolocation routing](routing-policy-geo.md).

Here are the countries that Amazon Route 53 associates with each continent. The country codes are from ISO 3166. For more information, see the Wikipedia article [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2):

**Africa (AF)**  
AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW

**Antarctica (AN)**  
AQ, GS, TF

**Asia (AS)**  
AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE

**Europe (EU)**  
AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK  
Some providers consider TR to be in Asia and the IP-addresses will reflect that.

**North America (NA)**  
AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI

**Oceania (OC)**  
AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS

**South America (SA)**  
AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE

**Note**  
Route 53 doesn't support creating geolocation records for the following countries: Bouvet Island (BV), Christmas Island (CX), Western Sahara (EH), and Heard Island and McDonald Islands (HM). No data is available about IP addresses for these countries.

## U.S. states
<a name="rrsets-values-geo-sublocation"></a>

When you configure Route 53 to respond to DNS queries based on the state of the United States that the queries originated from, select the state from the **U.S. states** list. United States territories (for example, Puerto Rico) are listed as countries in the **Location** list.

**Important**  
Some IP addresses are associated with the United States, but not with an individual state. If you create records for all of the states in the United States, we recommend that you also create a record for the United States to route queries for these unassociated IP addresses. If you don't create a record for the United States, Route 53 responds to DNS queries from unassociated United States IP addresses with settings from the default geolocation record (if you created one) or with a "no answer" response. 

## Health check
<a name="rrsets-values-geo-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate Target Health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain Name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain Name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

For geolocation records, if an endpoint is unhealthy, Route 53 looks for a record for the larger, associated geographic Region. For example, suppose you have records for a state in the United States, for the United States, for North America, and for all locations (**Location** is **Default**). If the endpoint for the state record is unhealthy, Route 53 checks the records for the United States, for North America, and for all locations, in that order, until it finds a record that has a healthy endpoint. If all applicable records are unhealthy, including the record for all locations, Route 53 responds to the DNS query using the value for the record for the smallest geographic region. 

## Record ID
<a name="rrsets-values-geo-set-id"></a>

Enter a value that uniquely identifies this record in the group of geolocation records.

# Values specific for geolocation alias records
<a name="resource-record-sets-values-geo-alias"></a>

When you create geolocation alias records, you specify the following values.

For more information, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [

## Routing policy
](#rrsets-values-geo-alias-routing-policy)
+ [

## Record name
](#rrsets-values-geo-alias-name)
+ [

## Record type
](#rrsets-values-geo-alias-type)
+ [

## Value/Route traffic to
](#rrsets-values-geo-alias-alias-target)
+ [

## Location
](#rrsets-values-geo-alias-location)
+ [

## U.S. states
](#rrsets-values-geo-alias-sublocation)
+ [

## Health check
](#rrsets-values-geo-alias-associate-with-health-check)
+ [

## Evaluate target health
](#rrsets-values-geo-alias-evaluate-target-health)
+ [

## Record ID
](#rrsets-values-geo-alias-set-id)

## Routing policy
<a name="rrsets-values-geo-alias-routing-policy"></a>

Choose **Geolocation**. 

## Record name
<a name="rrsets-values-geo-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of geolocation records. 

For more information about record names, see [Record name](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).

## Record type
<a name="rrsets-values-geo-alias-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the applicable value based on the AWS resource that you're routing traffic to. Select the same value for all of the records in the group of geolocation records:

**API Gateway custom regional API or edge-optimized API**  
Select **A — IPv4 address**.

**Amazon VPC interface endpoints**  
Select **A — IPv4 address**.

**CloudFront distribution**  
Select **A — IPv4 address**.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Type**, and one with a value of **AAAA — IPv6 address**.

**App Runner service**  
Select **A — IPv4 address**

**Elastic Beanstalk environment that has regionalized subdomains**  
Select **A — IPv4 address**

**ELB load balancer**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Amazon S3 bucket**  
Select **A — IPv4 address**

**OpenSearch Service**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Another record in this hosted zone**  
Select the type of the record that you're creating the alias for. All types are supported except **NS** and **SOA**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't route traffic to a record for which the value of **Type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

## Value/Route traffic to
<a name="rrsets-values-geo-alias-alias-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For information about what AWS resources you can target, see [Value/route traffic to](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

## Location
<a name="rrsets-values-geo-alias-location"></a>

When you configure Route 53 to respond to DNS queries based on the location that the queries originated from, select the continent or country for which you want Route 53 to respond with the settings in this record. If you want Route 53 to respond to DNS queries for individual states in the United States, select **United States** from the **Location** list, and then select the state from the **U.S. states** list.

For a private hosted zone, select the continent, country, or sub-division closest to the AWS Region that your resource is in. For example, if your resource is in us-east-1, you can specify North America, United States, or Virginia.

**Important**  
We recommend that you create one geolocation record that has a value of **Default** for **Location**. This covers geographic locations that you haven't created records for and IP addresses that Route 53 can't identify a location for.

You can't create non-geolocation records that have the same values for **Record name** and **Record type** as geolocation records.

For more information, see [Geolocation routing](routing-policy-geo.md).

Here are the countries that Amazon Route 53 associates with each continent. The country codes are from ISO 3166. For more information, see the Wikipedia article [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2):

**Africa (AF)**  
AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW

**Antarctica (AN)**  
AQ, GS, TF

**Asia (AS)**  
AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE

**Europe (EU)**  
AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK  
Some providers consider TR to be in Asia and the IP-addresses will reflect that.

**North America (NA)**  
AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI

**Oceania (OC)**  
AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS

**South America (SA)**  
AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE

**Note**  
Route 53 doesn't support creating geolocation records for the following countries: Bouvet Island (BV), Christmas Island (CX), Western Sahara (EH), and Heard Island and McDonald Islands (HM). No data is available about IP addresses for these countries.

## U.S. states
<a name="rrsets-values-geo-alias-sublocation"></a>

When you configure Route 53 to respond to DNS queries based on the state of the United States that the queries originated from, select the state from the **U.S. states** list. United States territories (for example, Puerto Rico) are listed as countries in the **Location** list.

**Important**  
Some IP addresses are associated with the United States, but not with an individual state. If you create records for all of the states in the United States, we recommend that you also create a record for the United States to route queries for these unassociated IP addresses. If you don't create a record for the United States, Route 53 responds to DNS queries from unassociated United States IP addresses with settings from the default geolocation record (if you created one) or with a "no answer" response. 

## Health check
<a name="rrsets-values-geo-alias-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

For geolocation records, if an endpoint is unhealthy, Route 53 looks for a record for the larger, associated geographic Region. For example, suppose you have records for a state in the United States, for the United States, for North America, and for all locations (**Location** is **Default**). If the endpoint for the state record is unhealthy, Route 53 checks the records for the United States, for North America, and for all locations, in that order, until it finds a record that has a healthy endpoint. If all applicable records are unhealthy, including the record for all locations, Route 53 responds to the DNS query using the value for the record for the smallest geographic region. 

## Evaluate target health
<a name="rrsets-values-geo-alias-evaluate-target-health"></a>

Select **Yes** if you want Route 53 to determine whether to respond to DNS queries using this record by checking the health of the resource specified by **Endpoint**. 

Note the following:

**API Gateway custom regional APIs and edge-optimized APIs**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an API Gateway custom Regional API or an edge-optimized API.

**CloudFront distributions**  
You can't set **Evaluate target health** to **Yes** when the endpoint is a CloudFront distribution.

**Elastic Beanstalk environments that have regionalized subdomains**  
If you specify an Elastic Beanstalk environment in **Endpoint** and the environment contains an ELB load balancer, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. (An environment automatically contains an ELB load balancer if it includes more than one Amazon EC2 instance.) If you set **Evaluate target health** to **Yes** and either no Amazon EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other available resources that are healthy, if any.   
If the environment contains a single Amazon EC2 instance, there are no special requirements.

**ELB load balancers**  
Health checking behavior depends on the type of load balancer:  
+ **Classic Load Balancers** – If you specify an ELB Classic Load Balancer in **Endpoint**, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. If you set **Evaluate target health** to **Yes** and either no EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other resources.
+ **Application and Network Load Balancers** – If you specify an ELB Application or Network Load Balancer and you set **Evaluate target health** to **Yes**, Route 53 routes queries to the load balancer based on the health of the target groups that are associated with the load balancer:
  + For an Application or Network Load Balancer to be considered healthy, every target group that contains targets must contain at least one healthy target. If any target group contains only unhealthy targets, the load balancer is considered unhealthy, and Route 53 routes queries to other resources.
  + A target group that has no registered targets is considered unhealthy.
When you create a load balancer, you configure settings for Elastic Load Balancing health checks; they're not Route 53 health checks, but they perform a similar function. Do not create Route 53 health checks for the EC2 instances that you register with an ELB load balancer. 

**S3 buckets**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an S3 bucket.

**Amazon VPC interface endpoints**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an Amazon VPC interface endpoint.

**Other records in the same hosted zone**  
If the AWS resource that you specify in **Endpoint** is a record or a group of records (for example, a group of weighted records) but is not another alias record, we recommend that you associate a health check with all of the records in the endpoint. For more information, see [What happens when you omit health checks?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## Record ID
<a name="rrsets-values-geo-alias-set-id"></a>

Enter a value that uniquely identifies this record in the group of geolocation records.

# Values specific for geoproximity records
<a name="resource-record-sets-values-geoprox"></a>

When you create geoproximity records, you specify the following values.

**Topics**
+ [

## Routing policy
](#rrsets-values-geoprox-routing-policy)
+ [

## Record name
](#rrsets-values-geoprox-name)
+ [

## Record type
](#rrsets-values-geoprox-type)
+ [

## TTL (seconds)
](#rrsets-values-geoprox-ttl)
+ [

## Value/Route traffic to
](#rrsets-values-geoprox-value)
+ [

## Endpoint location
](#rrsets-values-geoprox-endpoint-location)
+ [

## Bias
](#rrsets-values-geoprox-bias)
+ [

## Health check
](#rrsets-values-geoprox-associate-with-health-check)
+ [

## Record ID
](#rrsets-values-geoprox-set-id)

## Routing policy
<a name="rrsets-values-geoprox-routing-policy"></a>

Choose **Geoproximity**. 

## Record name
<a name="rrsets-values-geoprox-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Name** field. 

Enter the same name for all of the records in the group of geoproximity records. 

For more information about record names, see [Record name](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Record type
<a name="rrsets-values-geoprox-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the same value for all of the records in the group of geoproximity records.

## TTL (seconds)
<a name="rrsets-values-geoprox-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

## Value/Route traffic to
<a name="rrsets-values-geoprox-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **CNAME — Canonical name**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Endpoint location
<a name="rrsets-values-geoprox-endpoint-location"></a>

You can specify the resource endpoint location by using one of the following: 

**Custom coordinates**  
Specify the longitude and lattitude for a geopgraphic area.

**AWS Region**  
Choose an available Region from the **Location** list.   
For more information about the Regions, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).

**AWS Local Zone Group**  
Choose an available Local Zone Group from the **Location** list.  
For more information about Local Zones, see [Available Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) in the *AWS Local Zones User Guide*. A local Zone Group is usually the Local Zone without the ending character. For example, if the Local Zone is `us-east-1-bue-1a` the Local Zone Group is `us-east-1-bue-1`.

You can also identify the Local Zones Group for a specific Local Zone by using the [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html) CLI command:

```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```

This command returns: `"GroupName": "us-west-2-den-1"`, specifying that the Local Zone `us-west-2-den-1a` belongs to the Local Zone Group `us-west-2-den-1`.

You can't create non-geoproximity records that have the same values for **Record name** and **Record type** as geoproximity records.

You also can't create two geoproximity resource record sets that specify the same location for the same record name and record type.

## Bias
<a name="rrsets-values-geoprox-bias"></a>

A bias either expands or shrinks a geographic area from which Route 53 routes traffic to a resource. A positive bias expands the area, and a negative bias shrinks it. For more information, see [How Amazon Route 53 uses bias to route traffic](routing-policy-geoproximity.md#routing-policy-geoproximity-bias).

## Health check
<a name="rrsets-values-geoprox-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate Target Health** for an alias record or the records in a group of failover alias, geolocation alias, geoproximity alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain Name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain Name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

For geoproximity records, if an endpoint is unhealthy, Route 53 looks for a closest endpoint that is still healthy. 

## Record ID
<a name="rrsets-values-geoprox-set-id"></a>

Enter a value that uniquely identifies this record in the group of geoproximity records.

# Values specific for geoproximity alias records
<a name="resource-record-sets-values-geoprox-alias"></a>

When you create geoproximity alias records, you specify the following values.

For more information, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [

## Routing policy
](#rrsets-values-geoprox-alias-routing-policy)
+ [

## Record name
](#rrsets-values-geoprox-alias-name)
+ [

## Record type
](#rrsets-values-geoprox-alias-type)
+ [

## Value/Route traffic to
](#rrsets-values-geoprox-alias-alias-target)
+ [

## Endpoint location
](#rrsets-values-geoprox-alias-endpoint-location)
+ [

## Bias
](#rrsets-values-geoprox-alias-bias)
+ [

## Health check
](#rrsets-values-geoprox-alias-associate-with-health-check)
+ [

## Evaluate target health
](#rrsets-values-geoprox-alias-evaluate-target-health)
+ [

## Record ID
](#rrsets-values-geoprox-alias-set-id)

## Routing policy
<a name="rrsets-values-geoprox-alias-routing-policy"></a>

Choose **Geoproximity**. 

## Record name
<a name="rrsets-values-geoprox-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of geoproximity records. 

For more information about record names, see [Record name](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).

## Record type
<a name="rrsets-values-geoprox-alias-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the applicable value based on the AWS resource that you're routing traffic to. Select the same value for all of the records in the group of geoproximity records:

**API Gateway custom regional API or edge-optimized API**  
Select **A — IPv4 address**.

**Amazon VPC interface endpoints**  
Select **A — IPv4 address**.

**CloudFront distribution**  
Select **A — IPv4 address**.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Type**, and one with a value of **AAAA — IPv6 address**.

**App Runner service**  
Select **A — IPv4 address**

**Elastic Beanstalk environment that has regionalized subdomains**  
Select **A — IPv4 address**

**ELB load balancer**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Amazon S3 bucket**  
Select **A — IPv4 address**

**OpenSearch Service**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Another record in this hosted zone**  
Select the type of the record that you're creating the alias for. All types are supported except **NS** and **SOA**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't route traffic to a record for which the value of **Type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

## Value/Route traffic to
<a name="rrsets-values-geoprox-alias-alias-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For information about what AWS resources you can target, see [Value/route traffic to](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

## Endpoint location
<a name="rrsets-values-geoprox-alias-endpoint-location"></a>

You can specify the resource endpoint location by using one of the following: 

**Custom coordinates**  
Specify the longitude and lattitude for a geopgraphic area.

**AWS Region**  
Choose an available Region from the **Location** list.   
For more information about the Regions, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).

**AWS Local Zone Group**  
Choose an available Local Zone Region from the **Location** list.  
For more information about Local Zones, see [Available Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) in the *AWS Local Zones User Guide*. A local Zone Group is usually the Local Zone without the ending character. For example, if the Local Zone is `us-east-1-bue-1a` the Local Zone Group is `us-east-1-bue-1`.

You can also identify the Local Zones Group for a specific Local Zone by using the [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html) CLI command:

```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```

This command returns: `"GroupName": "us-west-2-den-1"`, specifying that the Local Zone `us-west-2-den-1a` belongs to the Local Zone Group `us-west-2-den-1`.

You can't create non-geoproximity records that have the same values for **Record name** and **Record type** as geoproximity records.

You also can't create two geoproximity resource record sets that specify the same location for the same record name and record type.

For more information, see available-local-zones.html

## Bias
<a name="rrsets-values-geoprox-alias-bias"></a>

A bias either expands or shrinks a geographic area from which Route 53 routes traffic to a resource. A positive bias expands the area, and a negative bias shrinks it. For more information, see [How Amazon Route 53 uses bias to route traffic](routing-policy-geoproximity.md#routing-policy-geoproximity-bias).

## Health check
<a name="rrsets-values-geoprox-alias-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, geoproximity alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

For geoproximity records, if an endpoint is unhealthy, Route 53 looks for a closest endpoint that is still healthy. 

## Evaluate target health
<a name="rrsets-values-geoprox-alias-evaluate-target-health"></a>

Select **Yes** if you want Route 53 to determine whether to respond to DNS queries using this record by checking the health of the resource specified by **Endpoint**. 

Note the following:

**API Gateway custom regional APIs and edge-optimized APIs**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an API Gateway custom Regional API or an edge-optimized API.

**CloudFront distributions**  
You can't set **Evaluate target health** to **Yes** when the endpoint is a CloudFront distribution.

**Elastic Beanstalk environments that have regionalized subdomains**  
If you specify an Elastic Beanstalk environment in **Endpoint** and the environment contains an ELB load balancer, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. (An environment automatically contains an ELB load balancer if it includes more than one Amazon EC2 instance.) If you set **Evaluate target health** to **Yes** and either no Amazon EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other available resources that are healthy, if any.   
If the environment contains a single Amazon EC2 instance, there are no special requirements.

**ELB load balancers**  
Health checking behavior depends on the type of load balancer:  
+ **Classic Load Balancers** – If you specify an ELB Classic Load Balancer in **Endpoint**, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. If you set **Evaluate target health** to **Yes** and either no EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other resources.
+ **Application and Network Load Balancers** – If you specify an ELB Application or Network Load Balancer and you set **Evaluate target health** to **Yes**, Route 53 routes queries to the load balancer based on the health of the target groups that are associated with the load balancer:
  + For an Application or Network Load Balancer to be considered healthy, every target group that contains targets must contain at least one healthy target. If any target group contains only unhealthy targets, the load balancer is considered unhealthy, and Route 53 routes queries to other resources.
  + A target group that has no registered targets is considered unhealthy.
When you create a load balancer, you configure settings for Elastic Load Balancing health checks; they're not Route 53 health checks, but they perform a similar function. Do not create Route 53 health checks for the EC2 instances that you register with an ELB load balancer. 

**S3 buckets**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an S3 bucket.

**Amazon VPC interface endpoints**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an Amazon VPC interface endpoint.

**Other records in the same hosted zone**  
If the AWS resource that you specify in **Endpoint** is a record or a group of records (for example, a group of weighted records) but is not another alias record, we recommend that you associate a health check with all of the records in the endpoint. For more information, see [What happens when you omit health checks?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## Record ID
<a name="rrsets-values-geoprox-alias-set-id"></a>

Enter a value that uniquely identifies this record in the group of geoproximity records.

# Values specific for latency records
<a name="resource-record-sets-values-latency"></a>

When you create latency records, you specify the following values.

**Topics**
+ [

## Routing policy
](#rrsets-values-latency-routing-policy)
+ [

## Record name
](#rrsets-values-latency-name)
+ [

## Record type
](#rrsets-values-latency-type)
+ [

## TTL (seconds)
](#rrsets-values-latency-ttl)
+ [

## Value/Route traffic to
](#rrsets-values-latency-value)
+ [

## Region
](#rrsets-values-latency-region)
+ [

## Health check
](#rrsets-values-latency-associate-with-health-check)
+ [

## Record ID
](#rrsets-values-latency-set-id)

## Routing policy
<a name="rrsets-values-latency-routing-policy"></a>

Choose **Latency**. 

## Record name
<a name="rrsets-values-latency-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of latency records. 

For more information about record names, see [Record name](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Record type
<a name="rrsets-values-latency-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the value for **Type** based on how you want Route 53 to respond to DNS queries. 

Select the same value for all of the records in the group of latency records.

## TTL (seconds)
<a name="rrsets-values-latency-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

## Value/Route traffic to
<a name="rrsets-values-latency-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **CNAME — Canonical name**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Region
<a name="rrsets-values-latency-region"></a>

The Amazon EC2 Region where the resource that you specified in this record resides. Route 53 recommends an Amazon EC2 Region based on other values that you've specified. This also applies to private hosted zones. We recommend that you not change this value.

Note the following:
+ You can only create one latency record for each Amazon EC2 Region.
+ You aren't required to create latency records for all Amazon EC2 Regions. Route 53 chooses the Region with the best latency from among the Regions that you create latency records for.
+ You can't create non-latency records that have the same values for **Record name** and **Record type** as latency records.
+ If you create a record tagged with the Region **cn-north-1**, Route 53 always responds to queries from within China using this record, regardless of the latency.

For more information about using latency records, see [Latency-based routing](routing-policy-latency.md). 

## Health check
<a name="rrsets-values-latency-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Record ID
<a name="rrsets-values-latency-set-id"></a>

Enter a value that uniquely identifies this record in the group of latency records.

# Values specific for latency alias records
<a name="resource-record-sets-values-latency-alias"></a>

When you create latency alias records, you specify the following values.

For more information, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [

## Routing policy
](#rrsets-values-latency-alias-routing-policy)
+ [

## Record name
](#rrsets-values-latency-alias-name)
+ [

## Record type
](#rrsets-values-latency-alias-type)
+ [

## Value/Route traffic to
](#rrsets-values-latency-alias-alias-target)
+ [

## Region
](#rrsets-values-latency-alias-region)
+ [

## Health check
](#rrsets-values-latency-alias-associate-with-health-check)
+ [

## Evaluate target health
](#rrsets-values-latency-alias-evaluate-target-health)
+ [

## Record ID
](#rrsets-values-latency-alias-set-id)

## Routing policy
<a name="rrsets-values-latency-alias-routing-policy"></a>

Choose **Latency**. 

## Record name
<a name="rrsets-values-latency-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of latency records. 

For more information about record names, see [Record name](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name)

## Record type
<a name="rrsets-values-latency-alias-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the applicable value based on the AWS resource that you're routing traffic to:

**API Gateway custom regional API or edge-optimized API**  
Select **A — IPv4 address**.

**Amazon VPC interface endpoints**  
Select **A — IPv4 address**.

**CloudFront distribution**  
Select **A — IPv4 address**.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Type**, and one with a value of **AAAA — IPv6 address**.

**App Runner service**  
Select **A — IPv4 address**

**Elastic Beanstalk environment that has regionalized subdomains**  
Select **A — IPv4 address**

**ELB load balancer**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Amazon S3 bucket**  
Select **A — IPv4 address**

**OpenSearch Service**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Another record in this hosted zone**  
Select the type of the record that you're creating the alias for. All types are supported except **NS** and **SOA**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't route traffic to a record for which the value of **Type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

Select the same value for all of the records in the group of latency records.

## Value/Route traffic to
<a name="rrsets-values-latency-alias-alias-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For information about what AWS resources you can target, see [common values for alias records for value/route traffic to](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

## Region
<a name="rrsets-values-latency-alias-region"></a>

The Amazon EC2 region where the resource that you specified in this record resides. Route 53 recommends an Amazon EC2 Region based on other values that you've specified. This also applies to private hosted zones. We recommend that you not change this value.

Note the following:
+ You can only create one latency record for each Amazon EC2 Region.
+ You aren't required to create latency records for all Amazon EC2 Regions. Route 53 chooses the Region with the best latency from among the Regions that you create latency records for.
+ You can't create non-latency records that have the same values for **Record name** and **Record type** as latency records.
+ If you create a record tagged with the Region **cn-north-1**, Route 53 always responds to queries from within China using this record, regardless of the latency.

For more information about using latency records, see [Latency-based routing](routing-policy-latency.md). 

## Health check
<a name="rrsets-values-latency-alias-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain Name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Evaluate target health
<a name="rrsets-values-latency-alias-evaluate-target-health"></a>

Select **Yes** if you want Route 53 to determine whether to respond to DNS queries using this record by checking the health of the resource specified by **Endpoint**. 

Note the following:

**API Gateway custom regional APIs and edge-optimized APIs**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an API Gateway custom regional API or an edge-optimized API.

**CloudFront distributions**  
You can't set **Evaluate Target Health** to **Yes** when the endpoint is a CloudFront distribution.

**Elastic Beanstalk environments that have regionalized subdomains**  
If you specify an Elastic Beanstalk environment in **Endpoint** and the environment contains an ELB load balancer, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. (An environment automatically contains an ELB load balancer if it includes more than one Amazon EC2 instance.) If you set **Evaluate target health** to **Yes** and either no Amazon EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other available resources that are healthy, if any.   
If the environment contains a single Amazon EC2 instance, there are no special requirements.

**ELB load balancers**  
Health checking behavior depends on the type of load balancer:  
+ **Classic Load Balancers** – If you specify an ELB Classic Load Balancer in **Endpoint**, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. If you set **Evaluate target health** to **Yes** and either no EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other resources.
+ **Application and Network Load Balancers** – If you specify an ELB Application or Network Load Balancer and you set **Evaluate target health** to **Yes**, Route 53 routes queries to the load balancer based on the health of the target groups that are associated with the load balancer:
  + For an Application or Network Load Balancer to be considered healthy, every target group that contains targets must contain at least one healthy target. If any target group contains only unhealthy targets, the load balancer is considered unhealthy, and Route 53 routes queries to other resources.
  + A target group that has no registered targets is considered unhealthy.
When you create a load balancer, you configure settings for Elastic Load Balancing health checks; they're not Route 53 health checks, but they perform a similar function. Do not create Route 53 health checks for the EC2 instances that you register with an ELB load balancer. 

**S3 buckets**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an S3 bucket.

**Amazon VPC interface endpoints**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an Amazon VPC interface endpoint.

**Other records in the same hosted zone**  
If the AWS resource that you specify in **Endpoint** is a record or a group of records (for example, a group of weighted records) but is not another alias record, we recommend that you associate a health check with all of the records in the endpoint. For more information, see [What happens when you omit health checks?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## Record ID
<a name="rrsets-values-latency-alias-set-id"></a>

Enter a value that uniquely identifies this record in the group of latency records.

# Values specific for IP-based records
<a name="resource-record-sets-values-ipbased"></a>

When you create IP-based records, you specify the following values.

**Note**  
Although creating IP-based records in a private hosted zone is allowed, it's not supported.

**Topics**
+ [

## Routing policy
](#rrsets-values-ipbased-routing-policy)
+ [

## Record name
](#rrsets-values-ibased-name)
+ [

## Record type
](#rrsets-values-ibased-type)
+ [

## TTL (seconds)
](#rrsets-values-ibased-ttl)
+ [

## Value/Route traffic to
](#rrsets-values-ibased-value)
+ [

## Location
](#rrsets-values-ibased-location)
+ [

## Health check
](#rrsets-values-ibased-associate-with-health-check)
+ [

## Record ID
](#rrsets-values-ipbased-set-id)

## Routing policy
<a name="rrsets-values-ipbased-routing-policy"></a>

Choose **IP-based**. 

## Record name
<a name="rrsets-values-ibased-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of IP-based records. 

**CNAME records**  
If you're creating a record that has a value of **CNAME** for **Record type**, the name of the record can't be the same as the name of the hosted zone.

**Special characters**  
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).

**Wildcard characters**  
You can use an asterisk (\$1) character in the name. DNS treats the \$1 character either as a wildcard or as the \$1 character (ASCII 42), depending on where it appears in the name. For more information, see [Using an asterisk (\$1) in the names of hosted zones and records](DomainNameFormat.md#domain-name-format-asterisk).

## Record type
<a name="rrsets-values-ibased-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the value for **Type** based on how you want Route 53 to respond to DNS queries. 

Select the same value for all of the records in the group of IP-based records.

## TTL (seconds)
<a name="rrsets-values-ibased-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

## Value/Route traffic to
<a name="rrsets-values-ibased-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **CNAME — Canonical name**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value) [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Location
<a name="rrsets-values-ibased-location"></a>

The name of the CIDR location where the resource that you specified in this record is specified by the CIDR block values within the CIDR location. 

For more information about using IP-based records, see [IP-based routing](routing-policy-ipbased.md). 

## Health check
<a name="rrsets-values-ibased-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, IP-based alias, latency alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Record ID
<a name="rrsets-values-ipbased-set-id"></a>

Enter a value that uniquely identifies this record in the group of IP-based records.

# Values specific for IP-based alias records
<a name="resource-record-sets-values-ipbased-alias"></a>

When you create IP-based alias records, you specify the following values.

**Note**  
Although creating IP-based alias records in a private hosted zone is allowed, it's not supported.

For more information, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [

## Routing policy
](#rrsets-values-ipbased-alias-routing-policy)
+ [

## Record name
](#rrsets-values-ipbased-alias-name)
+ [

## Record type
](#rrsets-values-ipbased-alias-type)
+ [

## Value/Route traffic to
](#rrsets-values-ipbased-alias-alias-target)
+ [

## Location
](#rrsets-values-ipbased-alias-location)
+ [

## Health check
](#rrsets-values-ipbased-alias-associate-with-health-check)
+ [

## Evaluate target health
](#rrsets-values-ipbased-alias-evaluate-target-health)
+ [

## Record ID
](#rrsets-values-ipbased-alias-set-id)

## Routing policy
<a name="rrsets-values-ipbased-alias-routing-policy"></a>

Choose **IP-based**. 

**Note**  
Although creating IP-based alias records in a private hosted zone is allowed, it's not supported.

## Record name
<a name="rrsets-values-ipbased-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of IP-based records. 

**CNAME records**  
If you're creating a record that has a value of **CNAME** for **Record type**, the name of the record can't be the same as the name of the hosted zone.

**Aliases to CloudFront distributions and Amazon S3 buckets**  
The value that you specify depends in part on the AWS resource that you're routing traffic to:  
+ **CloudFront distribution** – Your distribution must include an alternate domain name that matches the name of the record. For example, if the name of the record is **acme.example.com**, your CloudFront distribution must include **acme.example.com** as one of the alternate domain names. For more information, see [Using alternate domain names (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) in the *Amazon CloudFront Developer Guide*. 
+ **Amazon S3 bucket** – The name of the record must match the name of your Amazon S3 bucket. For example, if the name of your bucket is **acme.example.com**, the name of this record must also be **acme.example.com**.

  In addition, you must configure the bucket for website hosting. For more information, see [Configure a bucket for website hosting](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) in the *Amazon Simple Storage Service User Guide*. 

**Special characters**  
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).

**Wildcard characters**  
You can use an asterisk (\$1) character in the name. DNS treats the \$1 character either as a wildcard or as the \$1 character (ASCII 42), depending on where it appears in the name. For more information, see [Using an asterisk (\$1) in the names of hosted zones and records](DomainNameFormat.md#domain-name-format-asterisk).

## Record type
<a name="rrsets-values-ipbased-alias-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the applicable value based on the AWS resource that you're routing traffic to. Select the same value for all of the records in the group of IP-based records:

**API Gateway custom regional API or edge-optimized API**  
Select **A — IPv4 address**.

**Amazon VPC interface endpoints**  
Select **A — IPv4 address**.

**CloudFront distribution**  
Select **A — IPv4 address**.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Type**, and one with a value of **AAAA — IPv6 address**.

**App Runner service**  
Select **A — IPv4 address**

**Elastic Beanstalk environment that has regionalized subdomains**  
Select **A — IPv4 address**

**ELB load balancer**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Amazon S3 bucket**  
Select **A — IPv4 address**

**OpenSearch Service**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Another record in this hosted zone**  
Select the type of the record that you're creating the alias for. All types are supported except **NS** and **SOA**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't route traffic to a record for which the value of **Type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

## Value/Route traffic to
<a name="rrsets-values-ipbased-alias-alias-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For information about what AWS resources you can target, see [common values for alias records for value/route traffic to](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

## Location
<a name="rrsets-values-ipbased-alias-location"></a>

When you configure Route 53 to respond to DNS queries based on the location that the queries originated from, select the CIDR location for which you want Route 53 to respond with the settings in this record.

**Important**  
We recommend that you create one IP-based record that has a value of **Default** for **Location**. This covers locations that you haven't created records for and IP addresses that Route 53 can't identify a location for.

You can't create non-IP-based records that have the same values for **Record name** and **Record type** as IP-based records.

For more information, see [IP-based routing](routing-policy-ipbased.md).

## Health check
<a name="rrsets-values-ipbased-alias-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, IP-based routing alias, latency alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

For IP-based alias records, if an endpoint is unhealthy, Route 53 looks for a record within the larger, associated location. For example, suppose you have records for a state in the United States, for the United States, for North America, and for all locations (**Location** is **Default**). If the endpoint for the state record is unhealthy, Route 53 checks the records for the United States, for North America, and for all locations, in that order, until it finds a record that has a healthy endpoint. If all applicable records are unhealthy, including the record for all locations, Route 53 responds to the DNS query using the value for the record for the smallest geographic region. 

## Evaluate target health
<a name="rrsets-values-ipbased-alias-evaluate-target-health"></a>

Select **Yes** if you want Route 53 to determine whether to respond to DNS queries using this record by checking the health of the resource specified by **Endpoint**. 

Note the following:

**API Gateway custom regional APIs and edge-optimized APIs**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an API Gateway custom regional API or an edge-optimized API.

**CloudFront distributions**  
You can't set **Evaluate target health** to **Yes** when the endpoint is a CloudFront distribution.

**Elastic Beanstalk environments that have regionalized subdomains**  
If you specify an Elastic Beanstalk environment in **Endpoint** and the environment contains an ELB load balancer, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. (An environment automatically contains an ELB load balancer if it includes more than one Amazon EC2 instance.) If you set **Evaluate target health** to **Yes** and either no Amazon EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other available resources that are healthy, if any.   
If the environment contains a single Amazon EC2 instance, there are no special requirements.

**ELB load balancers**  
Health checking behavior depends on the type of load balancer:  
+ **Classic Load Balancers** – If you specify an ELB Classic Load Balancer in **Endpoint**, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. If you set **Evaluate target health** to **Yes** and either no EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other resources.
+ **Application and Network Load Balancers** – If you specify an ELB Application or Network Load Balancer and you set **Evaluate target health** to **Yes**, Route 53 routes queries to the load balancer based on the health of the target groups that are associated with the load balancer:
  + For an Application or Network Load Balancer to be considered healthy, every target group that contains targets must contain at least one healthy target. If any target group contains only unhealthy targets, the load balancer is considered unhealthy, and Route 53 routes queries to other resources.
  + A target group that has no registered targets is considered unhealthy.
When you create a load balancer, you configure settings for Elastic Load Balancing health checks; they're not Route 53 health checks, but they perform a similar function. Do not create Route 53 health checks for the EC2 instances that you register with an ELB load balancer. 

**S3 buckets**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an S3 bucket.

**Amazon VPC interface endpoints**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an Amazon VPC interface endpoint.

**Other records in the same hosted zone**  
If the AWS resource that you specify in **Endpoint** is a record or a group of records (for example, a group of weighted records) but is not another alias record, we recommend that you associate a health check with all of the records in the endpoint. For more information, see [What happens when you omit health checks?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## Record ID
<a name="rrsets-values-ipbased-alias-set-id"></a>

Enter a value that uniquely identifies this record in the group of IP-based records.

# Values specific for multivalue answer records
<a name="resource-record-sets-values-multivalue"></a>

When you create multivalue answer records, you specify the following values.

**Note**  
Creating multivalue answer alias records is not supported.

**Topics**
+ [

## Routing policy
](#rrsets-values-multivalue-routing-policy)
+ [

## Record name
](#rrsets-values-multivalue-name)
+ [

## Record type
](#rrsets-values-multivalue-type)
+ [

## TTL (seconds)
](#rrsets-values-multivalue-ttl)
+ [

## Value/Route traffic to
](#rrsets-values-multivalue-value)
+ [

## Health check
](#rrsets-values-multivalue-associate-with-health-check)
+ [

## Record ID
](#rrsets-values-multivalue-set-identifier)

## Routing policy
<a name="rrsets-values-multivalue-routing-policy"></a>

Choose **Multivalue answer**.

## Record name
<a name="rrsets-values-multivalue-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of multivalue records. 

For more information about record names, see [Record name](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Record type
<a name="rrsets-values-multivalue-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select any value except **NS** or **CNAME**.

Select the same value for all of the records in the group of multivalue answer records.

## TTL (seconds)
<a name="rrsets-values-multivalue-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

**Note**  
If you create two or more multivalue answer records that have the same name and type, you are using the console, and you specify different values for **TTL**, Route 53 changes the value of **TTL** for all of the records to the last value that you specified.

## Value/Route traffic to
<a name="rrsets-values-multivalue-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. If you enter more than one value, enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Health check
<a name="rrsets-values-multivalue-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Record ID
<a name="rrsets-values-multivalue-set-identifier"></a>

Enter a value that uniquely identifies this record in the group of multivalue answer records. 

# Values specific for weighted records
<a name="resource-record-sets-values-weighted"></a>

When you create weighted records, you specify the following values.

**Topics**
+ [

## Routing policy
](#rrsets-values-weighted-routing-policy)
+ [

## Record name
](#rrsets-values-weighted-name)
+ [

## Record type
](#rrsets-values-weighted-type)
+ [

## TTL (seconds)
](#rrsets-values-weighted-ttl)
+ [

## Value/Route traffic to
](#rrsets-values-weighted-value)
+ [

## Weight
](#rrsets-values-weighted-weight)
+ [

## Health check
](#rrsets-values-weighted-associate-with-health-check)
+ [

## Record ID
](#rrsets-values-weighted-set-identifier)

## Routing policy
<a name="rrsets-values-weighted-routing-policy"></a>

Select **Weighted**.

## Record name
<a name="rrsets-values-weighted-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Record name** field. 

Enter the same name for all of the records in the group of weighted records. 

For more information about record names, see [Record name](resource-record-sets-values-shared.md#rrsets-values-common-name).

## Record type
<a name="rrsets-values-weighted-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the same value for all of the records in the group of weighted records.

## TTL (seconds)
<a name="rrsets-values-weighted-ttl"></a>

The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see [How Amazon Route 53 routes traffic for your domain](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).

However, if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information. If you're changing settings for a domain or subdomain that's already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct.

If you're associating this record with a health check, we recommend that you specify a TTL of 60 seconds or less so clients respond quickly to changes in health status.

You must specify the same value for **TTL** for all of the records in this group of weighted records.

**Note**  
If you create two or more weighted records that have the same name and type, and you specify different values for **TTL**, Route 53 changes the value of **TTL** for all of the records to the last value that you specified.

If a group of weighted records includes one or more weighted alias records that are routing traffic to an ELB load balancer, we recommend that you specify a TTL of 60 seconds for all of the non-alias weighted records that have the same name and type. Values other than 60 seconds (the TTL for load balancers) will change the effect of the values that you specify for **Weight**.

## Value/Route traffic to
<a name="rrsets-values-weighted-value"></a>

Choose **IP address or another value depending on the record type**. Enter a value that is appropriate for the value of **Record type**. For all types except **CNAME**, you can enter more than one value. Enter each value on a separate line.

You can route traffic to, or specify the following values:
+ **A — IPv4 address**
+ **AAAA — IPv6 address**
+ **CAA — Certificate Authority Authorization**
+ **CNAME — Canonical name**
+ **MX — Mail exchange**
+ **NAPTR — Name Authority Pointer**
+ **PTR — Pointer**
+ **SPF — Sender Policy Framework**
+ **SRV — Service locator**
+ **TXT — Text**

For more information about the above values, see [common values for Value/Route traffic to](resource-record-sets-values-shared.md#rrsets-values-common-value).

## Weight
<a name="rrsets-values-weighted-weight"></a>

A value that determines the proportion of DNS queries that Route 53 responds to using the current record. Route 53 calculates the sum of the weights for the records that have the same combination of DNS name and type. Route 53 then responds to queries based on the ratio of a resource's weight to the total. 

You can't create non-weighted records that have the same values for **Record name** and **Record type** as weighted records.

Enter an integer between 0 and 255. To disable routing to a resource, set **Weight** to 0. If you set **Weight** to 0 for all of the records in the group, traffic is routed to all resources with equal probability. This ensures that you don't accidentally disable routing for a group of weighted records.

The effect of setting **Weight** to 0 is different when you associate health checks with weighted records. For more information, see [How Amazon Route 53 chooses records when health checking is configuredHow Route 53 chooses records when health checking is configured](health-checks-how-route-53-chooses-records.md).

## Health check
<a name="rrsets-values-weighted-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Record ID
<a name="rrsets-values-weighted-set-identifier"></a>

Enter a value that uniquely identifies this record in the group of weighted records.

# Values specific for weighted alias records
<a name="resource-record-sets-values-weighted-alias"></a>

When you create weighted alias records, you specify the following values. For more information, see [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md).

**Topics**
+ [

## Routing policy
](#rrsets-values-weighted-alias-routing-policy)
+ [

## Record name
](#rrsets-values-weighted-alias-name)
+ [

## Record type
](#rrsets-values-weighted-alias-type)
+ [

## Value/Route traffic to
](#rrsets-values-weighted-alias-alias-target)
+ [

## Weight
](#rrsets-values-weighted-alias-weight)
+ [

## Health check
](#rrsets-values-weighted-alias-associate-with-health-check)
+ [

## Evaluate target health
](#rrsets-values-weighted-alias-evaluate-target-health)
+ [

## Record ID
](#rrsets-values-weighted-alias-set-identifier)

## Routing policy
<a name="rrsets-values-weighted-alias-routing-policy"></a>

Choose **Weighted**.

## Record name
<a name="rrsets-values-weighted-alias-name"></a>

Enter the name of the domain or subdomain that you want to route traffic for. The default value is the name of the hosted zone. 

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the **Name** field. 

Enter the same name for all of the records in the group of weighted records. 

For more information about record names, see [Record name](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name)

## Record type
<a name="rrsets-values-weighted-alias-type"></a>

The DNS record type. For more information, see [Supported DNS record types](ResourceRecordTypes.md).

Select the applicable value based on the AWS resource that you're routing traffic to:

**API Gateway custom regional API or edge-optimized API**  
Select **A — IPv4 address**.

**Amazon VPC interface endpoints**  
Select **A — IPv4 address**.

**CloudFront distribution**  
Select **A — IPv4 address**.  
If IPv6 is enabled for the distribution, create two records, one with a value of **A — IPv4 address** for **Type**, and one with a value of **AAAA — IPv6 address**.

**App Runner service**  
Select **A — IPv4 address**

**Elastic Beanstalk environment that has regionalized subdomains**  
Select **A — IPv4 address**

**ELB load balancer**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Amazon S3 bucket**  
Select **A — IPv4 address**

**OpenSearch Service**  
Select **A — IPv4 address** or **AAAA — IPv6 address**

**Another record in this hosted zone**  
Select the type of the record that you're creating the alias for. All types are supported except **NS** and **SOA**.  
If you're creating an alias record that has the same name as the hosted zone (known as the *zone apex*), you can't route traffic to a record for which the value of **Type** is **CNAME**. This is because the alias record must have the same type as the record you're routing traffic to, and creating a CNAME record for the zone apex isn't supported even for an alias record. 

Select the same value for all of the records in the group of weighted records.

## Value/Route traffic to
<a name="rrsets-values-weighted-alias-alias-target"></a>

The value that you choose from the list or that you type in the field depends on the AWS resource that you're routing traffic to.

For information about what AWS resources you can target, see [common values for alias records for value/route traffic to](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).

For more information about how to configure Route 53 to route traffic to specific AWS resources, see [Routing internet traffic to your AWS resources](routing-to-aws-resources.md).

## Weight
<a name="rrsets-values-weighted-alias-weight"></a>

A value that determines the proportion of DNS queries that Route 53 responds to using the current record. Route 53 calculates the sum of the weights for the records that have the same combination of DNS name and type. Route 53 then responds to queries based on the ratio of a resource's weight to the total. 

You can't create non-weighted records that have the same values for **Record name** and **Record type** as weighted records.

Enter an integer between 0 and 255. To disable routing to a resource, set **Weight** to 0. If you set **Weight** to 0 for all of the records in the group, traffic is routed to all resources with equal probability. This ensures that you don't accidentally disable routing for a group of weighted records.

The effect of setting **Weight** to 0 is different when you associate health checks with weighted records. For more information, see [How Amazon Route 53 chooses records when health checking is configuredHow Route 53 chooses records when health checking is configured](health-checks-how-route-53-chooses-records.md).

## Health check
<a name="rrsets-values-weighted-alias-associate-with-health-check"></a>

Select a health check if you want Route 53 to check the health of a specified endpoint and to respond to DNS queries using this record only when the endpoint is healthy. 

Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the **Value** field. When you select a health check for a record, Route 53 checks the health of the endpoint that you specified in the health check. For information about how Route 53 determines whether an endpoint is healthy, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).

Associating a health check with a record is useful only when Route 53 is choosing between two or more records to respond to a DNS query, and you want Route 53 to base the choice in part on the status of a health check. Use health checks only in the following configurations:
+ You're checking the health of all of the records in a group of records that have the same name, type, and routing policy (such as failover or weighted records), and you specify health check IDs for all the records. If the health check for a record specifies an endpoint that is not healthy, Route 53 stops responding to queries using the value for that record.
+ You select **Yes** for **Evaluate target health** for an alias record or the records in a group of failover alias, geolocation alias, latency alias, IP-based alias, or weighted alias record. If the alias records reference non-alias records in the same hosted zone, you must also specify health checks for the referenced records. If you associate a health check with an alias record and also select **Yes** for **Evaluate Target Health**, both must evaluate to true. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).

If your health checks specify the endpoint only by domain name, we recommend that you create a separate health check for each endpoint. For example, create a health check for each HTTP server that is serving content for www.example.com. For the value of **Domain name**, specify the domain name of the server (such as us-east-2-www.example.com), not the name of the records (example.com).

**Important**  
In this configuration, if you create a health check for which the value of **Domain name** matches the name of the records and then associate the health check with those records, health check results will be unpredictable.

## Evaluate target health
<a name="rrsets-values-weighted-alias-evaluate-target-health"></a>

Select **Yes** if you want Route 53 to determine whether to respond to DNS queries using this record by checking the health of the resource specified by **Endpoint**. 

Note the following:

**API Gateway custom regional APIs and edge-optimized APIs**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an API Gateway custom Regional API or an edge-optimized API.

**CloudFront distributions**  
You can't set **Evaluate target health** to **Yes** when the endpoint is a CloudFront distribution.

**Elastic Beanstalk environments that have regionalized subdomains**  
If you specify an Elastic Beanstalk environment in **Endpoint** and the environment contains an ELB load balancer, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. (An environment automatically contains an ELB load balancer if it includes more than one Amazon EC2 instance.) If you set **Evaluate target health** to **Yes** and either no Amazon EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other available resources that are healthy, if any.   
If the environment contains a single Amazon EC2 instance, there are no special requirements.

**ELB load balancers**  
Health checking behavior depends on the type of load balancer:  
+ **Classic Load Balancers** – If you specify an ELB Classic Load Balancer in **Endpoint**, Elastic Load Balancing routes queries only to the healthy Amazon EC2 instances that are registered with the load balancer. If you set **Evaluate Target Health** to **Yes** and either no EC2 instances are healthy or the load balancer itself is unhealthy, Route 53 routes queries to other resources.
+ **Application and Network Load Balancers** – If you specify an ELB Application or Network Load Balancer and you set **Evaluate Target Health** to **Yes**, Route 53 routes queries to the load balancer based on the health of the target groups that are associated with the load balancer:
  + For an Application or Network Load Balancer to be considered healthy, every target group that contains targets must contain at least one healthy target. If any target group contains only unhealthy targets, the load balancer is considered unhealthy, and Route 53 routes queries to other resources.
  + A target group that has no registered targets is considered unhealthy.
When you create a load balancer, you configure settings for Elastic Load Balancing health checks; they're not Route 53 health checks, but they perform a similar function. Do not create Route 53 health checks for the EC2 instances that you register with an ELB load balancer. 

**S3 buckets**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an S3 bucket.

**Amazon VPC interface endpoints**  
There are no special requirements for setting **Evaluate target health** to **Yes** when the endpoint is an Amazon VPC interface endpoint.

**Other records in the same hosted zone**  
If the AWS resource that you specify in **Endpoint** is a record or a group of records (for example, a group of weighted records) but is not another alias record, we recommend that you associate a health check with all of the records in the endpoint. For more information, see [What happens when you omit health checks?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).

## Record ID
<a name="rrsets-values-weighted-alias-set-identifier"></a>

Enter a value that uniquely identifies this record in the group of weighted records.

# Creating records by importing a zone file
<a name="resource-record-sets-creating-import"></a>

If you're migrating from another DNS service provider, and if your current DNS service provider lets you export your current DNS settings to a zone file, you can quickly create all of the records for an Amazon Route 53 hosted zone by importing a zone file.

**Note**  
A zone file uses a standard format known as BIND to represent records in a text format. For information about the format of a zone file, see the Wikipedia entry [Zone file](https://en.wikipedia.org/wiki/Zone_file). Additional information is available in [RFC 1034, Domain Names—Concepts and Facilities](https://datatracker.ietf.org/doc/html/rfc1034) section 3.6.1, and [RFC 1035, Domain Names—Implementation and Specification](https://datatracker.ietf.org/doc/html/rfc1035) section 5. 

If you want to create records by importing a zone file, note the following:
+ The zone file must be in RFC-compliant format.
+ The domain name of the records in the zone file must match the name of the hosted zone.
+ Route 53 supports the `$ORIGIN` and `$TTL` keywords. If the zone file includes `$GENERATE` or `$INCLUDE` keywords, the import fails and Route 53 returns an error.
+ When you import the zone file, Route 53 ignores the SOA record in the zone file. Route 53 also ignores any NS records that have the same name as the hosted zone.
+ You can import a maximum of 1000 records.
+ If the hosted zone already contains records that appear in the zone file, the import process fails, and no records are created.
+ For TXT records that contain backslash characters, the zone file import process interprets certain backslash sequences as control characters. To include literal backslash characters in TXT record values:
  + Use double backslashes (`\\\\`) in the zone file to represent a single literal backslash in the final TXT record.
  + For example, if your TXT record should contain `\\jYTDWqH...` (with a literal backslash and j), specify `\\\\jYTDWqH...` in the zone file.

  This is particularly important for ACME challenge records and other TXT records that contain literal backslash characters.
+ For long TXT records (such as DKIM records), the zone file import process supports splitting the content into multiple strings. To create TXT records with multiple strings:
  + Use separate lines in your zone file with the same record name and type.  
**Example**  

    ```
    example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC"
    example.com. 300 IN TXT "7fCC6C13dM9tXuJmUBH7D4Vw8y1ByJ8z9QX2fvLm3pN4sR5tU6vW7xY8zA9bC0dE1f"
    example.com. 300 IN TXT "G2hI3jK4lM5nO6pQ7rS8tU9vW0xY1zA2bC3dE4fG5hI6jK7lM8nO9pQ0rS1tU2vW3x"
    ```

  The import process automatically combines these into a single TXT record with multiple strings. Each individual string can contain up to 65,535 characters. Do not concatenate long strings into a single quoted value.
+ We recommend that you review the contents of the zone file to confirm that record names include or exclude a trailing dot as appropriate:
  + When the name of a record in the zone file includes a trailing dot (`example.com.`), the import process interprets the name as a fully qualified domain name and creates a Route 53 record with that name.
  + When the name of a record in the zone file does not include a trailing dot (`www`), the import process concatenates that name with the domain name in the zone file (`example.com`) and creates a Route 53 record with the concatenated name (`www.example.com`).

  If the export process doesn't add a trailing dot to the fully qualified domain names of a record, the Route 53 import process adds the domain name to the name of the record. For example, suppose you're importing records into the hosted zone `example.com` and the name of an MX record in the zone file is `mail.example.com`, with no trailing dot. The Route 53 import process creates an MX record named `mail.example.com.example.com`.
**Important**  
For CNAME, MX, PTR, and SRV records, this behavior also applies to the domain name that is included in the RDATA value. For example, suppose you have a zone file for `example.com`. If a CNAME record in the zone file (`support`, without a trailing dot) has an RDATA value of `www.example.com` (also without a trailing dot), the import process creates a Route 53 record with the name `support.example.com` that routes traffic to `www.example.com.example.com`. Before you import your zone file, review RDATA values and update as applicable. For TXT records containing backslash characters, use double backslashes (`\\\\`) in the zone file to represent literal backslashes.

Route 53 doesn't support exporting records to a zone file.

**Note**  
If you're creating a record that has the same name as the hosted zone, don't enter a value (for example, an @ symbol) in the Name field.<a name="RRSchanges_import_console_procedure"></a>

**To create records by importing a zone file**

1. Get a zone file from the DNS service provider that is currently servicing the domain. The process and terminology vary from one service provider to another. Refer to your provider's interface and documentation for information about exporting or saving your records in a zone file or a BIND file.

   If the process isn't obvious, try asking your current DNS provider's customer support for your *records list* or *zone file* information.

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, create a new hosted zone:

   1. Choose **Create hosted zone**.

   1. Enter the name of your domain and, optionally, a comment. 

   1. Choose **Create**.

1. Choose **Import zone file**.

1. In the **Import zone file** pane, paste the contents of your zone file into the **Zone file** text box.

1. Choose **Import**.
**Note**  
Depending on the number of records in your zone file, you might have to wait a few minutes for the records to be created.

1. If you're using another DNS service for the domain (which is common if you registered the domain with another registrar), migrate DNS service to Route 53. When that step is complete, your registrar will start to identify Route 53 as your DNS service in response to DNS queries for your domain, and the queries will start being sent to Route 53 DNS servers. (Typically, there's a day or two of delay before DNS queries start being routed to Route 53 because information about your previous DNS service is cached on DNS resolvers for that long.) 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).

# Editing records
<a name="resource-record-sets-editing"></a>

The following procedure explains how to edit records using the Amazon Route 53 console. For information about how to edit records using the Route 53 API, see [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) in the *Amazon Route 53 API Reference*.

**Note**  
Your changes to records take time to propagate to the Route 53 DNS servers. Currently, the only way to verify that changes have propagated is to use the [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API action. Changes generally propagate to all Route 53 name servers within 60 seconds.<a name="resource-record-sets-editing-procedure"></a>

**To edit records using the Route 53 console**

1. If you're not editing alias records, skip to step 2. 

   If you're editing alias records that route traffic to an Elastic Load Balancing Classic Load Balancer, Application Load Balancer, or Network Load Balancer, and if you created your Route 53 hosted zone and your load balancer using different accounts, perform the procedure [Getting the DNS name for an Elastic Load Balancing load balancer](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure) to get the DNS name for the load balancer. 

   If you're editing alias records for any other AWS resource, skip to step 2.

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 row for the hosted zone that contains the records that you want to edit.

1. Select the row for the record that you want to edit, and then enter your changes in the **Edit record** pane.

1. Enter the applicable values. For more information, see [Values that you specify when you create or edit Amazon Route 53 records](resource-record-sets-values.md). 

1. Choose **Save changes**.

1. If you're editing multiple records, repeat steps 5 through 7.

# Deleting records
<a name="resource-record-sets-deleting"></a>

The following procedure explains how to delete records using the Route 53 console. For information about how to delete records using the Route 53 API, see [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) in the *Amazon Route 53 API Reference*.

**Note**  
Your changes to records take time to propagate to the Route 53 DNS servers. Currently, the only way to verify that changes have propagated is to use the [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API action. Changes generally propagate to all Route 53 name servers within 60 seconds.<a name="resource-record-sets-deleting-procedure"></a>

**To delete records**

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. On the Hosted Zones page, choose the row for the hosted zone that contains records that you want to delete. 

1. In the list of records, select the record that you want to delete.

   To select multiple, consecutive records, choose the first row, hold the **Shift** key, and choose the last row. To select multiple, nonconsecutive records, choose the first row, hold the **Ctrl** key, and choose additional rows. 

   You can't delete the records that have a value of **NS** or **SOA** for **Type**.

1. Choose **Delete**.

1. Choose **Delete** to close the dialog box.

# Listing records
<a name="resource-record-sets-listing"></a>

The following procedure explains how to use the Amazon Route 53 console to list the records in a hosted zone. For information about how to list records using the Route 53 API, see [ListResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListResourceRecordSets.html) in the *Amazon Route 53 API Reference*. 

**To list records**

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.

1. To change the search mode, choose the gear icon on the upper right of the **Records** table. Choose one of:
   + **Automatic**

     In this mode, the service uses a filter based on a number of records. Full for less than 2000 and fast for more than 2000 records.
   + **Full**

     In this mode, all the search filters are available, but the search performance might be slower.
   + **Fast**

     In this mode, some advanced features aren't available, but the search performance will be faster.

To display only selected records, enter the applicable search criteria above the list of records. In the automatic mode the search behavior depends on whether the hosted zone contains up to 2,000 records or more than 2,000 records:

**Up to 2,000 records and full mode**  
+ To display the records that have specific values, enter a value in the search bar and press **Enter**. For example, to display the records that have an IP address beginning with **192.0**, enter that value in the **Search** field and press **Enter**.
+ To display only the records that have the same DNS record type, select **Record type **in the dropdown list, and enter the record type. 
+ To display only alias records, select **Alias** in the dropdown list, and enter **Yes**.
+ To display only weighted records, select **Routing policy** in the dropdown list, and enter **WEIGHTED**.

**More than 2,000 records and fast mode**  
+ You can search only on record names, not on record values. You also can't filter based on the record type, or on alias or weighted records.

  To do this, put your cursor into the **Filter** textbox, select **Properties** and then **Record name**.
+ For records that have three labels (three parts separated by dots), when you enter a value in the search field and press **Enter**, the Route 53 console automatically performs a wildcard search on the third label from the right in the record name. For example, suppose the hosted zone example.com contains 100 records named record1.example.com through record100.example.com. (Record1 is the third label from the right.) Here's what happens when you search on the following values:
  + **record1** – The Route 53 console searches for **record1\$1.example.com**, which returns **record1.example.com**, **record10.example.com** through **record19.example.com**, and **record100.example.com**.
  + **record1.example.com** – As in the preceding example, the console searches for **record1\$1.example.com** and returns the same records.
  + **1** – The console searches for **1\$1.example.com** and returns no records.
  + **example** – The console searches for **example\$1.example.com** and returns no records.
  + **example.com** – In this example, the console doesn't perform a wildcard search. It returns all the records in the hosted zone.
  + **Automatic search mode** – When using this search mode, you must first provide a property, such as record name, to be able to search.
**Note**  
If the third label from the right contains one or more hyphens (such as `third-label.example.com`), and if you search for the part of the third label immediately before the hyphen (`third` in this example), Route 53 won't return any records. Instead, either include the hyphen (search for `third-`) or omit the character immediately before the hyphen (search for `third`).
+ For records that have four or more labels, you must specify the exact name of the record. No wildcard searches are supported. For example, if the hosted zone includes a record named label4.record1.example.com, you can find that record only if you specify **label4.record1.example.com** in the search field.

# Configuring DNSSEC signing in Amazon Route 53
<a name="dns-configuring-dnssec"></a>

Domain Name System Security Extensions (DNSSEC) signing lets DNS resolvers validate that a DNS response came from Amazon Route 53 and has not been tampered with. When you use DNSSEC signing, every response for a hosted zone is signed using public key cryptography. For an overview of DNSSEC, see the DNSSEC section of [AWS re:Invent 2021 - Amazon Route 53: A year in review](https://www.youtube.com/watch?v=77V23phAaAE).

In this chapter, we explain how to enable DNSSEC signing for Route 53, how to work with key-signing keys (KSKs), and how to troubleshoot issues. You can work with DNSSEC signing in the AWS Management Console or programmatically with the API. For more information about using the CLI or SDKs to work with Route 53, see [Set up Amazon Route 53](setting-up-route-53.md).

Before you enable DNSSEC signing, note the following:
+ To help prevent a zone outage and avoid problems with your domain becoming unavailable, you must quickly address and resolve DNSSEC errors. We strongly recommend that you set up a CloudWatch alarm that alerts you whenever a `DNSSECInternalFailure` or `DNSSECKeySigningKeysNeedingAction` error is detected. For more information, see [Monitoring hosted zones using Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md).
+ There are two kinds of keys in DNSSEC: a key-signing key (KSK) and a zone-signing key (ZSK). In Route 53 DNSSEC signing, each KSK is based on an [asymmetric customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#asymmetric-keys-concept) in AWS KMS that you own. You are responsible for KSK management, which includes rotating it if needed. ZSK management is performed by Route 53.
+ When you enable DNSSEC signing for a hosted zone, Route 53 limits the TTL to one week. If you set a TTL of more than one week for records in the hosted zone, you don't get an error. However, Route 53 enforces a TTL of one week for the records. Records that have a TTL of less than one week and records in other hosted zones that do not have DNSSEC signing enabled are not affected. 
+ When you use DNSSEC signing, multi-vendor configurations are not supported. If you have configured white-label name servers (also known as vanity name servers or private name servers), make sure those name servers are provided by a single DNS provider.
+ Some DNS providers do not support Delegation Signer (DS) records in their authoritative DNS. If your parent zone is hosted by a DNS provider who does not support DS queries (not setting AA flag in the DS query response), then when you enable DNSSEC in its child zone, the child zone will become unresolvable. Make sure your DNS provider supports DS records.
+ It can be helpful to set up IAM permissions to allow another user, besides the zone owner, to add or remove records in the zone. For example, a zone owner can add a KSK and enable signing, and might also be responsible for key rotation. However, someone else might be responsible for working with other records for the hosted zone. For an example IAM policy, see [Example permissions for a domain record owner](access-control-managing-permissions.md#example-permissions-record-owner).
+ To check to see if the TLD has DNSSEC support, see [Domains that you can register with Amazon Route 53](registrar-tld-list.md).

**Topics**
+ [

# Enabling DNSSEC signing and establishing a chain of trust
](dns-configuring-dnssec-enable-signing.md)
+ [

# Disabling DNSSEC signing
](dns-configuring-dnssec-disable.md)
+ [

# Working with customer managed keys for DNSSEC
](dns-configuring-dnssec-cmk-requirements.md)
+ [

# Working with key-signing keys (KSKs)
](dns-configuring-dnssec-ksk.md)
+ [

# KMS key and ZSK management in Route 53
](dns-configuring-dnssec-zsk-management.md)
+ [

# DNSSEC proofs of nonexistence in Route 53
](dns-configuring-dnssec-proof-of-nonexistence.md)
+ [

# Troubleshooting DNSSEC signing
](dns-configuring-dnssec-troubleshoot.md)

# Enabling DNSSEC signing and establishing a chain of trust
<a name="dns-configuring-dnssec-enable-signing"></a>

****  
The incremental steps apply to the hosted zone owner and the parent zone maintainer. This can be the same person, but if not, the zone owner should notify and work with the parent zone maintainer.

We recommend following the steps in this article to have your zone signed and included in the chain of trust. The following steps will minimize the risk of onboarding onto DNSSEC.

**Note**  
Make sure you read the prerequisites before you start in [Configuring DNSSEC signing in Amazon Route 53](dns-configuring-dnssec.md).

There are three steps to take to enable DNSSEC signing, as described in the following sections. 

**Topics**
+ [

## Step 1: Prepare for enabling DNSSEC signing
](#dns-configuring-dnssec-enable-signing-step-1)
+ [

## Step 2: Enable DNSSEC signing and create a KSK
](#dns-configuring-dnssec-enable)
+ [

## Step 3: Establish chain of trust
](#dns-configuring-dnssec-chain-of-trust)

## Step 1: Prepare for enabling DNSSEC signing
<a name="dns-configuring-dnssec-enable-signing-step-1"></a>

The preparation steps help you minimize the risk of onboarding to DNSSEC by monitoring zone availability and lowering wait times between enabling signing and the insertion of the Delegation Signer (DS) record.

**To prepare for enabling DNSSEC signing**

1. Monitor zone availability.

   You can monitor the zone for the availability of your domain names. This can help you address any issues that might warrant rolling a step back after you enable DNSSEC signing. You can monitor for your domain names with most traffic by using query logging. For more information about setting up query logging, see [Monitoring Amazon Route 53](monitoring-overview.md).

   The monitoring can be done through a shell script, or through a third party service. It shouldn't, however, be the only signal to determine if a rollback is required. You might also get feedback from your customers due to a domain not being available.

1. Lower the zone's maximum TTL.

   The zone’s maximum TTL is the longest TTL record in the zone. In the following example zone, the zone’s maximum TTL is 1 day (86400 seconds).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html)

   Lowering the zone's maximum TTL will help reduce the wait time between enabling signing and the insertion of the Delegation Signer (DS) record. We recommend lowering the zone's maximum TTL to 1 hour (3600 seconds). This allows you to roll back after only an hour if any resolver has problems with caching signed records.

   **Rollback:** undo the TTL changes.

1. Lower the SOA TTL and SOA minimum field.

   The SOA minimum field is the last field in the SOA record data. In the following example SOA record, the minimum field has the value of 5 minutes (300 seconds).    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html)

   The SOA TTL and SOA minimum field determines how long resolvers remember negative answers. After you enable signing, Route 53 name servers start returning NSEC records for negative answers. The NSEC contains information that resolvers might use to synthesize a negative answer. If you have to roll back because the NSEC information caused a resolver to assume a negative answer for a name, then you only have to wait for the maximum of the SOA TTL and SOA minimum field for the resolver to stop the assumption.

   **Rollback:** undo the SOA changes.

1. Make sure the TTL and SOA minimum field changes are effective.

   Use [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) to make sure your changes so far have been propagated to all Route 53 DNS servers.

## Step 2: Enable DNSSEC signing and create a KSK
<a name="dns-configuring-dnssec-enable"></a>

You can enable DNSSEC signing and create a key-signing key (KSK) by using AWS CLI or on the Route 53 console.
+ [CLI](#dnssec_CLI)
+ [Console](#dnssec_console)

When you provide or create a KMS key, there are several requirements. For more information, see [Working with customer managed keys for DNSSEC](dns-configuring-dnssec-cmk-requirements.md).

------
#### [ CLI ]

You can use a key that you already have, or create one by running an AWS CLI command like the following using your own values for `hostedzone_id`, `cmk_arn`, `ksk_name`, and `unique_string` (to make the request unique):

```
aws --region us-east-1 route53 create-key-signing-key \
			--hosted-zone-id $hostedzone_id \
			--key-management-service-arn $cmk_arn --name $ksk_name \
			--status ACTIVE \
			--caller-reference $unique_string
```

For more information about customer managed keys, see [Working with customer managed keys for DNSSEC](dns-configuring-dnssec-cmk-requirements.md). See also [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html).

To enable DNSSEC signing, run an AWS CLI command like the following, using your own value for the `hostedzone_id`:

```
aws --region us-east-1 route53 enable-hosted-zone-dnssec \
			--hosted-zone-id $hostedzone_id
```

For more information, see [enable-hosted-zone-dnssec](https://docs.aws.amazon.com/cli/latest/reference/route53/enable-hosted-zone-dnssec.html) and [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html).

------
#### [ Console ]<a name="dns-configuring-dnssec-enable-procedure"></a>

**To enable DNSSEC signing and create a KSK**

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 then choose a hosted zone that you want to enable DNSSEC signing for.

1. On the **DNSSEC signing** tab, choose **Enable DNSSEC signing**.
**Note**  
If the option in this section is **Disable DNSSEC signing**, you have already completed the first step in enabling DNSSEC signing. Be sure that you establish, or that there already exists, a chain of trust for the hosted zone for DNSSEC, and then you're done. For more information, see [Step 3: Establish chain of trust](#dns-configuring-dnssec-chain-of-trust).

1. In the **Key-signing key (KSK) creation** section, choose **Create new KSK**, and under **Provide KSK name**, enter a name for the KSK that Route 53 will create for you. The name can include numbers, letters, and underscores (\$1). It must be unique.

1. Under **Customer managed CMK**, choose the customer managed key for Route 53 to use when it creates the KSK for you. You can use an existing customer managed key that applies to DNSSEC signing, or create a new customer managed key.

   When you provide or create a customer managed key, there are several requirements. For more information, see [Working with customer managed keys for DNSSEC](dns-configuring-dnssec-cmk-requirements.md).

1. Enter the alias for an existing customer managed key. If you want to use a new customer managed key, enter an alias for the customer managed key, and Route 53 will create one for you.
**Note**  
If you choose to have Route 53 create a customer managed key, be aware that separate charges apply for each customer managed key. For more information, see [AWS Key Management Service pricing](https://aws.amazon.com/kms/pricing/).

1. Choose **Enable DNSSEC signing**.

------

**After you enable zone signing, complete the following steps** (whether you used the console or the CLI):

1. Ensure zone signing is effective.

   If you used AWS CLI, you can use the operation Id from the output of the `EnableHostedZoneDNSSEC()` call to run [get-change](https://docs.aws.amazon.com/cli/latest/reference/route53/get-change.html) or [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) to make sure that all Route 53 DNS Servers are signing responses (status = `INSYNC`).

1. Wait for at least the previous zone’s maximum TTL.

   Wait for resolvers to flush all unsigned records from their cache. To achieve this you should wait for at least the previous zone’s maximum TTL. In the `example.com` zone above, the wait time would be 1 day.

1. Monitor for reports of customer issues.

   After you have enabled zone signing, your customers might start seeing issues related to network devices and resolvers. The recommended monitoring period is 2 weeks.

   The following are examples of issues that you might see:
   + Some network devices can limit DNS response size to under 512 bytes, which is too small for some signed responses. These network devices should be reconfigured to allow larger DNS response sizes.
   + Some network devices do a deep inspection on DNS responses and strips certain records it doesn’t understand, like the ones used for DNSSEC. These devices should be reconfigured.
   + Some customers’ resolvers claim that they can accept a larger UDP response than their network supports. You can test your network capability and configure your resolvers appropriately. For more information see, [DNS Reply Size Test Server](https://www.dns-oarc.net/oarc/services/replysizetest/).

**Rollback:** call [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) then rollback the steps in [Step 1: Prepare for enabling DNSSEC signing](#dns-configuring-dnssec-enable-signing-step-1).

## Step 3: Establish chain of trust
<a name="dns-configuring-dnssec-chain-of-trust"></a>

After you enable DNSSEC signing for a hosted zone in Route 53, establish a chain of trust for the hosted zone to complete your DNSSEC signing setup. You do this by creating a Delegation Signer (DS) record in the *parent* hosted zone, for your hosted zone, using the information that Route 53 provides. Depending on where your domain is registered, you add the record to the parent hosted zone in Route 53 or at another domain registrar.<a name="dns-configuring-dnssec-chain-of-trust-procedure"></a>

**To establish a chain of trust for DNSSEC signing**

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 then choose a hosted zone that you want to establish a DNSSEC chain of trust for. *You must enable DNSSEC signing first.*

1. On the **DNSSEC signing** tab, under **DNSSEC signing**, choose **View information to create DS record**.
**Note**  
If you don't see **View information to create DS record** in this section, then you must enable DNSSEC signing before you establish the chain of trust. Choose **Enable DNSSEC signing** and complete the steps as described in [Step 2: Enable DNSSEC signing and create a KSK](#dns-configuring-dnssec-enable), and then return to these steps to establish the chain of trust.

1. Under **Establish a chain of trust**, choose either **Route 53 registrar** or **Another domain registrar**, depending on where your domain is registered.

1. Use the provided values from step 3 to create a DS record for the parent hosted zone in Route 53. If your domain is not hosted at Route 53, use the provided values to create a DS record at your domain registrar website. 

   Establish a chain of trust for the parent zone:
   + If your domain is managed through Route 53, follow these steps:

     Make sure that you configure the correct signing algorithm (ECDSAP256SHA256 and type 13) and digest algorithm (SHA-256 and type 2). 

     If Route 53 is your registrar, do the following in the Route 53 console:

     1. Note the **Key type**, **Signing algorithm**, and **Public key** values. In the navigation pane, choose **Registered domains**.

     1. Select a domain, and then, within the **DNSSEC keys** tab, choose **Add key**.

     1. In the **Manage DNSSEC keys** dialog box, choose the appropriate **Key type** and **Algorithm** for the **Route 53 registrar** from the dropdown menus.

     1. Copy the **Public key** for the Route 53 registrar. In the **Manage DNSSEC keys** dialog box, paste the value into the **Public key** box.

     1. Choose **Add**.

         Route 53 will add the DS record to the parent zone from the public key. For example, if your domain is `example.com`, the DS record is added to the .com DNS zone.
   + If your domain is managed on another registry, follow the instructions in the **Another domain registrar** section.

     To make sure the following steps go smoothly, introduce a low DS TTL to the parent zone. We recommend setting the DS TTL to 5 minutes (300 seconds) for faster recovery if you need to roll your changes back.
     + Establish a chain of trust for the child zone:

       If your parent zone is administered by another registry, contact your registrar to introduce the DS record for your zone. Typically you will not be able to adjust the TTL of the DS record.
     + If your parent zone is hosted on Route 53, contact the parent zone owner to introduce the DS record for your zone. 

       Provide the `$ds_record_value` to the parent zone owner. You can get it by clicking on the **View Information to create DS record** in the console and copying the **DS record** field, or by calling [GetDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetDNSSEC.html) API and retrieving the value of the ‘DSRecord’ field:

       ```
       aws --region us-east-1 route53 get-dnssec 
                   --hosted-zone-id $hostedzone_id
       ```

       The parent zone owner can insert the record through the Route 53 console or CLI.
       +  To insert the DS record by using AWS CLI, the parent zone owner creates and names a JSON file similar to the following example. The parent zone owner might name the file something like `inserting_ds.json`. 

         ```
         {
             "HostedZoneId": "$parent_zone_id",
             "ChangeBatch": {
                 "Comment": "Inserting DS for zone $zone_name",
                 "Changes": [
                     {
                         "Action": "UPSERT",
                         "ResourceRecordSet": {
                             "Name": "$zone_name",
                             "Type": "DS",
                             "TTL": 300,
                             "ResourceRecords": [
                                 {
                                     "Value": "$ds_record_value"
                                 }
                             ]
                         }
                     }
                 ]
             }
         }
         ```

         Then run the following command:

         ```
         aws --region us-east-1 route53 change-resource-record-sets 
                     --cli-input-json file://inserting_ds.json
         ```
       + To insert the DS record by using the console, 

         Open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

         In the navigation pane, choose **Hosted zones**, the name of your hosted zone and then **Create record** button. Make sure you choose Simple routing for the **Routing policy**.

         In the **Record name** field enter the same name as the `$zone_name`, select DS from the **Record type** drop-down, and enter the value of `$ds_record_value` into the **Value** field, and choose **Create records**.

   **Rollback:** remove the DS from the parent zone, wait for the DS TTL, and then roll back the steps for establishing trust. If the parent zone is hosted on Route 53, the parent zone owner can change the `Action` from `UPSERT` to `DELETE` in the JSON file, and re-run the example CLI above.

1. Wait for the updates to propagate, based on the TTL for your domain records.

   If the parent zone is on Route 53 DNS service, the parent zone owner can confirm full propagation through the [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API.

   Otherwise, you can periodically probe the parent zone for the DS record, and then wait another 10 minutes afterwards to increase the probability of the DS record insertion being fully propagated. Do note that some registrars have scheduled DS insertion, for example, once a day.

When you introduce the Delegation Signer (DS) record in the parent zone, the validated resolvers that have picked up the DS will start validating responses from the zone.

To make sure the steps for establishing trust go smoothly, complete the following:

1. Find the maximum NS TTL.

   There are 2 sets of NS records associated with your zones:
   + The delegation NS record — this is the NS record for your zone held by the parent zone. You can find this by running the following Unix commands (if your zone is example.com, the parent zone is com):

     `dig -t NS com`

     Pick one of the NS records and then run the following:

     `dig @one of the NS records of your parent zone -t NS example.com`

     For example:

     `dig @b.gtld-servers.net. -t NS example.com`
   + The in-zone NS record — this is the NS record in your zone. You can find this by running the following Unix command:

     `dig @one of the NS records of your zone -t NS example.com`

     For example:

     `dig @ns-0000.awsdns-00.co.uk. -t NS example.com`

     Note the maximum TTL for both zones.

1. Wait for the maximum NS TTL.

   Prior to the DS insertion, resolvers are getting a signed response, but aren't validating the signature. When the DS record is inserted, resolvers will not see it until the NS record for the zone expires. When resolvers re-fetch the NS record, the DS record will then be also returned.

   If your customer is running a resolver on a host with an out of sync clock, make sure the clock is within 1 hour of the correct time.

   After completing this step, all DNSSEC-aware resolvers will validate your zone.

1. Observe name resolution.

   You should observe that there are no issues with resolvers validating your zone. Make sure you also account for the time needed for your customers to report problems to you.

   We recommend monitoring for up to 2 weeks.

1. (Optional) Lengthen the DS and NS TTLs.

   If you are satisfied with the setup, you can save the TTL and SOA changes you made. Note that Route 53 limits the TTL to 1 week for signed zones. For more information, see [Configuring DNSSEC signing in Amazon Route 53](dns-configuring-dnssec.md).

   If you can change the DS TTL, we recommend that you set it to 1 hour.

# Disabling DNSSEC signing
<a name="dns-configuring-dnssec-disable"></a>

The steps for disabling DNSSEC signing in Route 53 vary, depending on the chain of trust that your hosted zone is part of. 

For example, your hosted zone might have a parent zone that has a Delegation Signer (DS) record, as part of a chain of trust. Your hosted zone might also be itself a parent zone for child zones that have enabled DNSSEC signing, which is another part of the chain of trust. Investigate and determine the full chain of trust for your hosted zone before you take the steps to disable DNSSEC signing.

The chain of trust for your hosted zone that enables DNSSEC signing must be carefully undone as you disable signing. To remove your hosted zone from the chain of trust, you remove all DS records that are in place for the chain of trust that includes this hosted zone. This means that you must do the following, in order:

1. Remove any DS records that this hosted zone has for child zones that are part of a chain of trust.

1. Remove the DS record from the parent zone. Skip this step if you have an island of trust (there are no DS records in the parent zone and no DS records for child zones in this zone). 

1. If you are not able to remove DS records, in order to remove the zone from the chain of trust, remove NS records from the parent zone. For more information, see [Adding or changing name servers and glue records for a domain](domain-name-servers-glue-records.md).

The following incremental steps allow you to monitor the effectiveness of the individual steps to avoid DNS availability issues in your zone.

**To disable DNSSEC signing**

1. Monitor zone availability.

   You can monitor the zone for the availability of your domain names. This can help you address any issues that might warrant rolling a step back after you enable DNSSEC signing. You can monitor for your domain names with most traffic by using query logging. For more information about setting up query logging, see [Monitoring Amazon Route 53](monitoring-overview.md).

   The monitoring can be done through a shell script, or through a paid service. It shouldn't, however, be the only signal to determine if a rollback is required. You might also get feedback from your customers due to a domain not being available.

1. Find the current DS TTL.

   You can find the DS TTL by running the following Unix command:

   `dig -t DS example.com example.com`

1. Find the maximum NS TTL.

   There are 2 sets of NS records associated with your zones:
   + The delegation NS record — this is the NS record for your zone held by the parent zone. You can find this by running the following Unix commands:

     First find the NS of your parent zone (if your zone is example.com, the parent zone is com):

     `dig -t NS com`

     Pick one of the NS records and then run the following:

     `dig @one of the NS records of your parent zone -t NS example.com`

     For example:

     `dig @b.gtld-servers.net. -t NS example.com`
   + The in-zone NS record — this is the NS record in your zone. You can find this by running the following Unix command:

     `dig @one of the NS records of your zone -t NS example.com`

     For example:

     `dig @ns-0000.awsdns-00.co.uk. -t NS example.com`

     Note the maximum TTL for both zones.

1. Remove the DS record from the parent zone. 

   Contact the parent zone owner to remove the DS record.

   **Rollback:** re-insert the DS record, confirm DS insertion is effective, and wait for the maximum NS (not DS) TTL before all resolvers will start validating again.

1. Confirm the DS removal is effective.

   If the parent zone is on Route 53 DNS service, the parent zone owner can confirm full propagation through the [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API.

   Otherwise, you can periodically probe the parent zone for the DS record, and then wait another 10 minutes afterwards to increase the probability of the DS record removal being fully propagated. Do note that some registrars have scheduled DS removal, for example once a day.

1. Wait for the DS TTL.

   Wait until all resolvers have expired the DS record from their caches.

1. Disable DNSSEC signing and deactivate the key-signing key (KSK).
   + [CLI](#CLI_dnssec_disable)
   + [Console](#console_dnssec_disable)

------
#### [ CLI ]

   Call [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) and [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) APIs.

   For example:

   ```
   aws --region us-east-1 route53 disable-hosted-zone-dnssec \
               --hosted-zone-id $hostedzone_id
   
   aws --region us-east-1 route53 deactivate-key-signing-key \
               --hosted-zone-id $hostedzone_id --name $ksk_name
   ```

------
#### [ Console ]

   **To disable DNSSEC signing**

   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 then choose a hosted zone that you want to disable DNSSEC signing for.

   1. On the **DNSSEC signing** tab, choose **Disable DNSSEC signing**.

   1. On the **Disable DNSSEC signing** page, choose one of the following options, depending on your scenario for the zone that you're disabling DNSSEC signing for.
      + **Parent zone only** — This zone has a parent zone with a DS record. In this scenario, you must remove the parent zone's DS record.
      + **Child zones only** — This zone has a DS record for a chain of trust with one or more child zones. In this scenario, you must remove the zone's DS records.
      + **Parent and child zones** — This zone has both a DS record for a chain of trust with one or more child zones *and* a parent zone with a DS record. In this scenario, do the following, in order:

        1. Remove the zone's DS records.

        1. Remove the parent zone's DS record.

        If you have an island of trust, you can skip this step.

   1. Determine what the TTL is for each DS record that you remove in Step 4.,Make sure that the longest TTL period has expired.

   1. Select the check box to confirm that you have followed the steps in order.

   1. Type *disable* in the field, as shown, and then choose **Disable**.

   **To deactivate the key-signing key (KSK)**

   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 then choose a hosted zone that you want to deactivate the key-signing key (KSK) for.

   1. In the **Key-signing keys (KSKs)** section, choose the KSK you want to deactivate, and under **Actions**, choose **Edit KSK**, set **KSK status** to **Inactive**, and then choose **Save KSK**.

------

   **Rollback:** call [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html) and [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) APIs.

   For example:

   ```
   aws --region us-east-1 route53 activate-key-signing-key \
               --hosted-zone-id $hostedzone_id --name $ksk_name
   
   aws --region us-east-1 route53 enable-hosted-zone-dnssec \
               --hosted-zone-id $hostedzone_id
   ```

1. Confirm disabling zone signing is effective.

   Use the Id from the `EnableHostedZoneDNSSEC()` call to run [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) to make sure that all Route 53 DNS Servers have stopped signing responses (status = `INSYNC`).

1. Observe name resolution.

   You should observe that there are no issues resulting in resolvers validating your zone. Allow 1-2 weeks to also account for the time needed for your customers to report problems to you.

1. (Optional) Clean up.

   If you will not re-enable signing, you can clean up the KSKs through [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html) and delete the corresponding customer managed key to save costs.

# Working with customer managed keys for DNSSEC
<a name="dns-configuring-dnssec-cmk-requirements"></a>

When you enable DNSSEC signing in Amazon Route 53, Route 53 creates a key-signing key (KSK) for you. To create a KSK, Route 53 must use a customer managed key in AWS Key Management Service that supports DNSSEC. This section describes the details and requirements for the customer managed key that are helpful to know as you work with DNSSEC.

Keep the following in mind when you work with customer managed keys for DNSSEC:
+ The customer managed key that you use with DNSSEC signing must be in the US East (N. Virginia) Region. 
+ The customer managed key must be an [asymmetric customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-concepts.html#asymmetric-cmks) with an [ECC\$1NIST\$1P256 key spec](https://docs.aws.amazon.com//kms/latest/developerguide/asymmetric-key-specs.html#key-spec-ecc). These customer managed keys are used only for signing and verification. For help creating an asymmetric customer managed key, see [Creating asymmetric customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-asymmetric-cmk) in the AWS Key Management Service Developer Guide. For help finding the cryptographic configuration of an existing customer managed key, see [Viewing the cryptographic configuration of customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-crypto-config.html) in the AWS Key Management Service Developer Guide.
+ If you create a customer managed key yourself to use with DNSSEC in Route 53, you must include specific key policy statements that give Route 53 the required permissions. Route 53 must be able to access your customer managed key so that it can create a KSK for you. For more information, see [Route 53 customer managed key permissions required for DNSSEC signing](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC).
+ Route 53 can create a customer managed key for you in AWS KMS to use with DNSSEC signing without additional AWS KMS permissions. However, you must have specific permissions if you want to edit the key after it's created. The specific permissions that you must have are the following: `kms:UpdateKeyDescription`, `kms:UpdateAlias`, and `kms:PutKeyPolicy`.
+ Be aware that separate charges apply for each customer managed key that you have, whether you create the customer managed key or Route 53 creates it for you. For more information, see [AWS Key Management Service pricing](https://aws.amazon.com/kms/pricing/).

# Working with key-signing keys (KSKs)
<a name="dns-configuring-dnssec-ksk"></a>

When you enable DNSSEC signing, Route 53 creates a key-signing key (KSK) for you. You can have up to two KSKs per hosted zone in Route 53. After you enable DNSSEC signing, you can add, remove, or edit your KSKs.

Note the following when you work with your KSKs:
+ Before you can delete a KSK, you must edit the KSK to set its status to **Inactive**. 
+ When DNSSEC signing is enabled for a hosted zone, Route 53 limits the TTL to one week. If you set a TTL for records in the hosted zone to more than one week, you don't get an error, but Route 53 enforces a TTL of one week.
+ To help prevent a zone outage and avoid problems with your domain becoming unavailable, you must quickly address and resolve DNSSEC errors. We strongly recommend that you set up a CloudWatch alarm that alerts you whenever a `DNSSECInternalFailure` or `DNSSECKeySigningKeysNeedingAction` error is detected. For more information, see [Monitoring hosted zones using Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md).
+ The KSK operations described in this section allow you to rotate your zone’s KSKs. For more information and a step-by-step example, see *DNSSEC Key Rotation* in the blog post [ Configuring DNSSEC signing and validation with Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/).

To work with KSKs in the AWS Management Console, follow the guidance in the following sections.

## Add a key-signing key (KSK)
<a name="dns-configuring-dnssec-ksk-add-ksk"></a>

When you enable DNSSEC signing, Route 53 creates a key-signing (KSK) for you. You can also add KSKs separately. You can have up to two KSKs per hosted zone in Route 53. 

When you create a KSK, you must provide or request Route 53 to create a customer managed key to use with the KSK. When you provide or create a customer managed key, there are several requirements. For more information, see [Working with customer managed keys for DNSSEC](dns-configuring-dnssec-cmk-requirements.md).

Follow these steps to add a KSK in the AWS Management Console.<a name="dns-configuring-dnssec-ksk-add-ksk-procedure"></a>

**To add a KSK**

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 then choose a hosted zone.

1. On the **DNSSEC signing** tab, under **Key-signing keys (KSKs)**, choose **Switch to advanced view**, and then, under **Actions**, choose **Add KSK**.

1. Under **KSK**, enter a name for the KSK that Route 53 will create for you. The name can include numbers, letters, and underscores (\$1). It must be unique.

1. Enter the alias for a customer managed key that applies to DNSSEC signing, or enter an alias for a new customer managed key that Route 53 will create for you.
**Note**  
If you choose to have Route 53 create a customer managed key, be aware that separate charges apply for each customer managed key. For more information, see [AWS Key Management Service pricing](https://aws.amazon.com/kms/pricing/).

1. Choose **Create KSK**.

## Edit a key-signing key (KSK)
<a name="dns-configuring-dnssec-ksk-edit-ksk"></a>

You can edit the status of a KSK to be **Active** or **Inactive**. When a KSK is active, Route 53 uses that KSK for DNSSEC signing. Before you can delete a KSK, you must edit the KSK to set its status to **Inactive**.

Follow these steps to edit a KSK in the AWS Management Console.<a name="dns-configuring-dnssec-ksk-edit-ksk-procedure"></a>

**To edit a KSK**

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 then choose a hosted zone.

1. On the **DNSSEC signing** tab, under **Key-signing keys (KSKs)**, choose **Switch to advanced view**, and then, under **Actions**, choose **Edit KSK**.

1. Make the desired updates to the KSK, and then choose **Save**.

## Delete a key-signing key (KSK)
<a name="dns-configuring-dnssec-ksk-delete-ksk"></a>

Before you can delete a KSK, you must edit the KSK to set its status to **Inactive**. 

One reason that you might delete a KSK is as part of routine key rotation. It's a best practice to rotate cryptographic keys periodically. Your organization might have standard guidance for how often to rotate keys. 

Follow these steps to delete a KSK in the AWS Management Console.<a name="dns-configuring-dnssec-ksk-delete-ksk-procedure"></a>

**To delete a KSK**

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 then choose a hosted zone.

1. On the **DNSSEC signing** tab, under **Key-signing keys (KSKs)**, choose **Switch to advanced view**, and then under **Actions**, choose **Delete KSK**.

1. Follow the guidance to confirm deleting the KSK.

# KMS key and ZSK management in Route 53
<a name="dns-configuring-dnssec-zsk-management"></a>

This section describes the current practice Route 53 uses for your DNSSEC signing enabled zones.

**Note**  
Route 53 uses the following rule which might change. Any future changes will not reduce your zone's or Route 53's security posture.

**How Route 53 uses the AWS KMS associated with your KSK**  
In DNSSEC, the KSK is used to generate the resource record signature (RRSIG) for the DNSKEY resource record set. All `ACTIVE` KSKs are used in the RRSIG generation. Route 53 generates an RRSIG by calling the `Sign` AWS KMS API on the associated KMS key. For more information, see [Sign](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html) in the *AWS KMS API guide*. These RRSIGs do not count towards the zone’s resource record set limit.  
RRSIG has an expiration. To prevent the RRSIGs from expiring, the RRSIGs are refreshed regularly by regenerating them every one to seven days.  
The RRSIGs are also refreshed every time you call any of these APIs:  
+ [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html)
+ [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html)
+ [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html)
+ [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)
+ [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)
+ [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)
Every time Route 53 performs a refresh, we generate 15 RRSIGs to cover the next few days in case the associated KMS key becomes inaccessible. For KMS key cost estimation, you can assume a once a day regular refresh. A KMS key might become inaccessible by inadvertent changes to the KMS key policy. Inaccessible KMS key will set the associated KSK’s status to `ACTION_NEEDED`. We strongly recommend that you monitor this condition by setting up a CloudWatch alarm whenever a `DNSSECKeySigningKeysNeedingAction` error is detected because validating resolvers will start failing lookups after the last RRSIG expires. For more information, see [Monitoring hosted zones using Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md).

**How Route 53 manages your zone’s ZSK**  
Each new hosted zone with DNSSEC signing enabled will have one `ACTIVE` zone signing key (ZSK). The ZSK is generated separately for each hosted zone and is owned by Route 53. The current key algorithm is ECDSAP256SHA256.  
We will start performing regular ZSK rotation on the zone within 7–30 days of the start of signing. Currently, Route 53 uses the Pre-Publish Key Rollover method. For more information, see [Pre-Publish Zone Signing Key Rollover](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.1). This method will introduce another ZSK to the zone. The rotation will be repeated every 7–30 days.  
Route 53 will suspend ZSK rotation if any of the zone’s KSK is in `ACTION_NEEDED` status because Route 53 will not be able to regenerate the RRSIGs for DNSKEY resource record sets to account for the changes in the zone’s ZSK. ZSK rotation will automatically resume after the condition is cleared.

# DNSSEC proofs of nonexistence in Route 53
<a name="dns-configuring-dnssec-proof-of-nonexistence"></a>

**Note**  
Route 53 uses the following rule which might change. Any future changes will not reduce your zone's or Route 53's security posture.

There are three kinds of proof of nonexistence in DNSSEC:
+ Proof of nonexistence of a record matching the query name.
+ Proof of nonexistence of a type matching the query type.
+ Proof of existence of a wildcard record used to generate the record in response.

Route 53 implements the proof of nonexistence of a record matching the query name using the BL method. For more information, see [BL](https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00). It's a method that produces a compact representation of the proof and prevents zone walking.

In cases where there is a record matching the query name but not the query type (such as querying for web.example.com/AAAA but there is only web.example.com/A present), we return a minimal NSEC (next secure) record containing all supported resource record types.

When Route 53 synthesizes an answer from a wildcard record, the response will not be accompanied with a next secure record, or NSEC record for the wildcard. Such NSEC record is used in some implementations, typically those performing offline signing, to prevent the resource record signatures (RRSIG) in the response from being re-used to spoof a different response. Route 53 uses online signing for non-DNSKEY records to generate RRSIGs specific to the response which cannot be re-used for a different response.

# Troubleshooting DNSSEC signing
<a name="dns-configuring-dnssec-troubleshoot"></a>

The information in this section can help you address issues with DNSSEC signing, including enabling, disabling, and with your key-signing keys (KSKs).

Enabling DNSSEC  
Make sure you have read the prerequisites in [Configuring DNSSEC signing in Amazon Route 53](dns-configuring-dnssec.md) before you start enabling DNSSEC signing.

Disabling DNSSEC  
In order to safely disable DNSSEC, Route 53 will check whether the target zone is in the chain of trust. It checks if the parent of the target zone has any NS records of the target zone and DS records of the target zone. If the target zone is not publicly resolvable, for example, getting a SERVFAIL response when querying for NS and DS, Route 53 cannot determine whether it is safe to disable DNSSEC. You can contact your parent zone to fix those issues, and retry disabling DNSSEC later.

KSK status is **Action needed**  
A KSK can change its status to **Action needed** (or `ACTION_NEEDED` in a [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html) status), when Route 53 DNSSEC loses access to a corresponding AWS KMS key (due to a change in permissions or AWS KMS key deletion).  
If the status of a KSK is **Action needed**, it means that eventually it'll cause a zone outage for clients using DNSSEC validating resolvers and you must act fast to prevent a production zone becoming un-resolvable.  
To correct the problem, make sure that the customer managed key that your KSK is based on is enabled and has the correct permissions. For more information about the required permissions, see [Route 53 customer managed key permissions required for DNSSEC signing](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC).  
After you have fixed the KSK, activate it again by using the console or the AWS CLI, as described in [Step 2: Enable DNSSEC signing and create a KSK](dns-configuring-dnssec-enable-signing.md#dns-configuring-dnssec-enable).  
To prevent this issue in the future, consider adding an Amazon CloudWatch metric to track the state of the KSK as suggested in [Configuring DNSSEC signing in Amazon Route 53](dns-configuring-dnssec.md).

KSK status is **Internal failure**  
When a KSK has a status of **Internal failure** (or `INTERNAL_FAILURE` in a [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html) status), you can't work with any other DNSSEC entities until the problem is resolved. You must take action before you can work with DNSSEC signing, including working with this KSK or your other KSK.  
To correct the problem, try again to activate or deactivate the KSK.  
 To correct the problem when working with the APIs, try enabling signing ([EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)) or disabling signing ([ DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)).  
It's important that you correct **Internal failure** problems promptly. You can't make any other changes to the hosted zone until you correct the problem, except the operations to fix the **Internal failure**.

# Using AWS Cloud Map to create records and health checks
<a name="autonaming"></a>

If you want to route internet traffic or traffic within an Amazon VPC to application components or microservices, you can use AWS Cloud Map to automatically create records and, optionally, to create health checks. For more information, see the [AWS Cloud Map Developer Guide](https://docs.aws.amazon.com/cloud-map/latest/dg/).

# DNS constraints and behaviors
<a name="DNSBehavior"></a>

DNS messaging is subject to factors that affect how you create and use hosted zones and records. This section explains these factors.

## Maximum response size
<a name="MaxSize"></a>

To comply with DNS standards, responses sent over UDP are no more than 512 bytes in size. Responses exceeding 512 bytes are truncated and the resolver must re-issue the request over TCP. If the resolver supports EDNS0 (as defined in [RFC 2671](https://tools.ietf.org/html/rfc2671)), and advertises the EDNS0 option to Amazon Route 53, Route 53 permits responses up to 4096 bytes over UDP, without truncation.

## Authoritative section processing
<a name="AuthSectionProcessing"></a>

For successful queries, Route 53 appends name server (NS) records for the relevant hosted zone to the Authority section of the DNS response. For names that are not found (NXDOMAIN responses), Route 53 appends the start of authority (SOA) record (as defined in [RFC 1035](https://tools.ietf.org/html/rfc1035)) for the relevant hosted zone to the Authority section of the DNS response.

## Additional section processing
<a name="SectionProcessing"></a>

Route 53 appends records to the Additional section. If the records are known and appropriate, the service appends A or AAAA records for any target of an MX, CNAME, NS, or SRV record cited in the Answer section. For more information about these DNS record types, see [Supported DNS record types](ResourceRecordTypes.md).

# Related topics
<a name="dns-configuring-related-topics"></a>

For information about transferring domain registration (not just DNS hosting) to Route 53, see the following topics:
+ [Pre-transfer checklist for domain transfers](domain-transfer-checklist.md) – Complete this checklist before transferring domain registration to avoid common transfer failures.
+ [Transferring registration for a domain to Amazon Route 53](domain-transfer-to-route-53.md) – Step-by-step process for transferring domain registration from another registrar to Route 53.
+ [Transferring domains](domain-transfer.md) – Overview of all domain transfer options, including transfers between AWS accounts.