# Working with records
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
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
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
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
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
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
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
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
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
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
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
To get started, create a CIDR collection and add CIDR blocks and locations to it.
**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
**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
**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
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
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
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
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
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
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
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
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
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**
```
192.0.2.1
```
## AAAA record type
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**
```
2001:0db8:85a3:0:0:8a2e:0370:7334
```
## CAA record type
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
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
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
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
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
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
**Example for the Route 53 console**
```
0 issue "ca.example.net"
0 iodef "mailto:admin@example.com"
```
**Example for the Route 53 API**
```
0 issue "ca.example.net"
0 iodef "mailto:admin@example.com"
```
## CNAME record type
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**
```
hostname.example.com
```
## DS record type
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**
```
123 4 5 1234567890abcdef1234567890absdef
```
## HTTPS record type
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**
```
0 example.com
```
**Example for the Route 53 API for service mode**
```
16 example.com alpn="h2,h3" port=808
```
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
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**
```
10 mail.example.com
```
## NAPTR record type
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**
```
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!" .
```
## NS record type
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**
```
ns-1.example.com
```
## PTR record type
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**
```
hostname.example.com
```
## SOA record type
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**
```
ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60
```
## SPF record type
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**
```
"v=spf1 ip4:192.168.0.1/16 -all"
```
## SRV record type
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**
```
10 5 80 hostname.example.com
```
## SSHFP record type
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**
```
1 1 09F6A01D2175742B257C6B98B7C72C44C4040683
```
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
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**
```
0 example.com
```
**Example for the Route 53 API for service mode**
```
16 example.com alpn="h2,h3" port=808
```
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
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**
```
0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971
```
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 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 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:
```
"String 1" "String 2" "String 3"
```
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
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
Case is preserved, so `"Ab"` and `"aB"` are different values.
### Examples
**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:
```
"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"
```
# Creating records by using the Amazon Route 53 console
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).
**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.
**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
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
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
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
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
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)
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
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
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
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
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
Choose **Simple routing**.
## Record name
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
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
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)
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
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
Choose **Simple routing**.
## Record name
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
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
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
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
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
Choose **Failover**.
## Record name
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
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)
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
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
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
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
Enter a value that uniquely identifies the primary and secondary records.
# Values specific for failover alias records
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
Choose **Failover**.
## Record name
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
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
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
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
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
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
Enter a value that uniquely identifies the primary and secondary records.
# Values specific for geolocation records
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
Choose **Geolocation**.
## Record name
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
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)
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
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
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
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
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
Enter a value that uniquely identifies this record in the group of geolocation records.
# Values specific for geolocation alias records
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
Choose **Geolocation**.
## Record name
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
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
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
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
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
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
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
Enter a value that uniquely identifies this record in the group of geolocation records.
# Values specific for geoproximity records
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
Choose **Geoproximity**.
## Record name
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
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)
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
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
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 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
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
Enter a value that uniquely identifies this record in the group of geoproximity records.
# Values specific for geoproximity alias records
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
Choose **Geoproximity**.
## Record name
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
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
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
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 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
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
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
Enter a value that uniquely identifies this record in the group of geoproximity records.
# Values specific for latency records
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
Choose **Latency**.
## Record name
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
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)
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
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
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
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
Enter a value that uniquely identifies this record in the group of latency records.
# Values specific for latency alias records
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
Choose **Latency**.
## Record name
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
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
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
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
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
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
Enter a value that uniquely identifies this record in the group of latency records.
# Values specific for IP-based records
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
Choose **IP-based**.
## Record name
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
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)
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
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
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
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
Enter a value that uniquely identifies this record in the group of IP-based records.
# Values specific for IP-based alias records
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
Choose **IP-based**.
**Note**
Although creating IP-based alias records in a private hosted zone is allowed, it's not supported.
## Record name
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
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
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
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
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
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
Enter a value that uniquely identifies this record in the group of IP-based records.
# Values specific for multivalue answer records
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
Choose **Multivalue answer**.
## Record name
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
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)
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
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
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
Enter a value that uniquely identifies this record in the group of multivalue answer records.
# Values specific for weighted records
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
Select **Weighted**.
## Record name
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
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)
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
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 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
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
Enter a value that uniquely identifies this record in the group of weighted records.
# Values specific for weighted alias records
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
Choose **Weighted**.
## Record name
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
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
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 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
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
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
Enter a value that uniquely identifies this record in the group of weighted records.
# Creating records by importing a zone file
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.
**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
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.
**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
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.
**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
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.