Networking & Content Delivery
Introducing IP-based routing for Amazon Route 53
Amazon Route 53 is a highly available and scalable cloud Domain Name System (DNS) web service. Route 53 provides you with the ability to manage traffic to your public domains globally through a variety of routing types, including latency-based routing, geolocation, geoproximity, and weighted routing – all of which can be combined with DNS failover in order to support a variety of latency optimized, fault-tolerant architectures.
Today, Route 53 adds IP-based routing to the list of routing types for public hosted zones, enabling you to route traffic to resources of your domain based on the client subnet. With IP-based routing, 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 allowing you to upload your data to Route 53 in the form of client IP to location mappings.
This post explains what IP-based routing is and how to deploy it to route traffic with Route 53 based on client subnets. Before diving into how this new Route 53 feature works, let’s explore how Route 53 will determine the query-originating client subnet in a DNS request.
When a Route 53 DNS server receives a query from a DNS resolver, the source IP address of the resolver is always present. In addition Route 53 supports the Extension Mechanisms for DNS (EDNS; RFC 6891), which allows DNS resolvers that implement EDNS Client Subnet (RFC 7871) to also include the IP range of the original client that made the query. When present, this allows Route 53 to more accurately determine the client’s location.
When it is available, Route 53 will use the ECS value to determine responses for the client. Otherwise, it will use the resolver’s IP.
To learn more about how Route 53 uses EDNS, see this documentation page.
How IP-based routing works
IP-based routing allows you to create a set of Classless Inter-Domain Routing (CIDR) blocks that represent the client IP network ranges and map those CIDR blocks to locations. These sets of CIDR blocks that are mapped to sets of locations are referred to as a CIDR collection. Within each CIDR collection you will be able to create a set of locations, and for each location you can define a set of CIDR blocks that represent the client subnets you wish to pair with a given location.
When creating resource record in a public hosted zone, you can select IP-based routing as the routing type and provide the collection ID and location name. If the ECS value in the DNS query matches one of the subnets associated with the given location, Route 53 responds to the DNS query with the corresponding answer value in the resource record. A location name “*” defines a default location, and Route 53 will return the value of this record if the ECS value or subsequently the resolver IP do not match any other records within the record set.
Six new APIs have been added as part of this feature – CreateCidrCollection, DeleteCidrCollection, ChangeCidrCollection, ListCidrCollections, ListCidrLocations and ListCidrBlocks. Additionally, the existing ChangeResourceRecordSets API has been updated to support CIDR collections. To learn more about these APIs, please visit the Route 53 API reference page.
Configuration steps
To implement IP-based routing for resource records, you first create a CIDR collection with locations and CIDR blocks. To create a CIDR collection, navigate to the Route 53 console, and in the left navigation pane, click on ‘IP-based routing’ and then ‘CIDR collections’. From this page, you can create a CIDR collection with CIDR locations and corresponding CIDR blocks. Now you are able to associate this CIDR collection and corresponding locations when creating resource records.
Example 1: Standalone IP-based routing
Step 1: Create a CIDR collection
To create a CIDR collection from the AWS CLI, use the create-cidr-collection command providing a name for the collection.
Step 2: Add a location with corresponding CIDR blocks to the CIDR collection
In Step 1, an empty CIDR collection with name ‘collection-1’ was created. In the output, there is a unique ID generated for the collection. We will now use this ID to update the collection and add an IPv4 and IPv6 CIDR block with location name ‘location-1’.
Now, we have a CIDR collection consisting of one location named ‘location-1’ that is comprised of the CIDR blocks 2001:0db8:1234::/48 and 203.0.113.0/24.
Step 3: Create resource records using IP-based routing
This step creates two AAAA records for the “example.com” hosted zone. The first AAAA record has a value of 2001:0db8::0123:4567:89ab:cdef and an IP-based routing type with reference to the CIDR collection created in Step 1, and the location name ‘location-1’ created in Step 2. The second AAAA record has a value of 2001:0db8::abcd:ef01:2345:6789 and also refers to the same CIDR collection, and a default location name as “*”. Route 53 will return the first record’s value for DNS queries to example.com coming from clients in the subnets 2001:0db8:1234::/48 and 203.0.113.0/24, and returns the second record’s value for all other requests.
Figure 1. Route 53 console with two records displaying IP-based routing
Figure 2. Route 53 console view when creating a resource record with IP-based routing
Figure 3. Route 53 console view when creating a CIDR collection
Figure 4. Route 53 console displaying one location within a CIDR collection
Example 2: Latency-based routing with an IP-based routing override
In example 1, we created two AAAA records with IP-based routing that targeted different IPv6 addresses. In this example, we will create a record that responds with 2001:db8::0123:4567:89ab:cdef for requests originating from CIDR blocks in ‘location-1’. For all other requests we will have resource records using latency-based routing which will respond with 2001:db8::abcd:ef01:2345:6789 for us-east-1 and 2001:db8::9876:5432:10fe:dcba for us-west-2.
In this example we reuse the same collection ID and location created in steps 1 and 2 in the previous example.
Step 1: Create latency-based routing for latency.example.com
First, we create two AAAA records for latency.example.com targeting different IPv6 addresses, with latency-based routing:
Step 2: Create records for example.com that use IP-based routing
The next command creates two AAAA records for example.com, with IP-based routing. With this, Route 53 returns the first record targeting an IPv6 address for clients within the CIDR blocks defined in location-1, and returns the second record targeting latency.example.com for all other requests, which returns one of the two AAAA records created in Step 1 based on the latency between the client and the regions of the two IPv6 targets.
Figure 5. Route 53 console displaying resource records with IP-based and latency-based routing
How to test records
The test record tool in the Route 53 console is an easy way to determine how Route 53 will respond to DNS queries for a specified record from different client subnets. The tool does not send DNS queries but instead simulates them to test the response. This tool can be used with public hosted zones and for any record type.
Figure 6. Display of the Route 53 test record tool
Figure 7. The response shown by the Route 53 test record tool
Use Cases
IP-based routing gives you granular control by uploading your data to Route 53 in the form of client subnet to location mappings. This can be useful if you want to route end users from certain ISPs to specific endpoints in order to optimize network transit costs or performance. Additionally, if you want to add overrides to existing Route 53 routing types such as geolocation routing based on your knowledge of your clients’ physical locations, IP-based routing provides a solution for this. On the other hand, if you are looking to direct traffic based on whether it originates from a resolver within your control or not, you should utilize split horizon DNS.
Considerations and Limitations
- By default, you can create up to 5 CIDR collections per account and each CIDR collection can contain up to 1,000 CIDR blocks. The full list of quotas for Route 53 can be found in the Route 53 documentation.
- 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 “*” 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:db8::/32 as the CIDR in your CIDR collection and a query comes in originating from 2001:0db8:1234::/48, this would match. If, on the other hand, you specify 2001:db8:1234::/48 in your CIDR collection and a query comes in originating from 2001:db8::/32, this would not match and Route 53 will answer with the record for the “*” location.
- If a query originates from an IPv4 or IPv6 address, and no CIDR blocks are specified in the CIDR collection matching that IP version, Route 53 will answer with the default “*” location
- If you do no specify a default “*” location and a query originates from a CIDR block that does not match any specified CIDR blocks in the CIDR collection, Route 53 will answer with ‘NODATA’.
- IP-based routing is not supported for private hosted zones.
Conclusion
In this blog post, we introduced Amazon Route 53’s new IP-based routing type and how Route 53 uses the originating client’s IP address to make routing decisions based on user-configurable CIDR blocks.
We discussed two use cases where IP-based routing can provide value and how it can complement the existing routing types supported by Route 53. With this, Route 53 provides you with a new way to fine tune DNS routing and make more deterministic routing decisions for your workloads.
Get started today with Route 53 IP-based routing type by checking out the documentation and visiting the Route 53 console.
Scott Morrison
Scott is a Senior Specialist Solutions Architect for Networking at AWS, where he helps customers design resilient and cost-effective networks. Scott loves to code in his spare working hours to solve unique problems. When not working, Scott is often found either in the desert outside of Las Vegas off-roading or occasionally playing in poker tournaments.
Suresh Samuel
Suresh is a Senior Technical Account Manager at AWS. He helps customers in the Financial Services Industry with their operations in AWS. When not working, he can be found photographing birds in Texas or hanging out with his kids.