An Update to Hybrid DNS for the Enterprise on AWS — Introducing Route 53 Resolver for Hybrid Cloud!
Early last year, I published an article outlining the different options available for creating an enterprise-tailored hybrid DNS solution on AWS. This solution required EC2 instances, configuring DNS software, and a good amount of “undifferentiated heavy lifting.”
As AWS has matured their enterprise offerings over the past several years, they’ve identified hybrid DNS as a gap and I was so happy to hear they’ve solved this problem by announcing the ‘Route 53 Resolver for Hybrid Cloud’ service today!
The new Route 53 resolver offering is broken down into two different offerings — an “inbound endpoint” and an “outbound endpoint”. When used together, an enterprise has all of the pieces required to turn an existing DNS configuration into a hybrid configuration, bridging both the datacenter and AWS.
The rest of this post will review the functionality introduced in the new Route 53 Resolver for Hybrid Cloud offering, how to use it, and how to transition away from an EC2 based DNS forwarder solution to using only AWS’ new managed Route 53 services!
AWS’ announcement of the service is available here.
AWS documentation for the service is available here.
Inbound Endpoints
In the past, you could not access your VPC’s Route 53 endpoint IP address over a DirectConnect or VPN connection. This meant that, in order for clients outside of the VPC to resolve addresses for DNS records hosted in Route 53 private zones, you needed an intermediary service to handle forwarding requests to Route 53. This is no longer a requirement!
With inbound endpoints, you can now provision multiple endpoints within your VPC which you can then point your on-premise DNS forwarders to for resolution of Route 53 records.
Configuration of inbound endpoints is fairly straightforward. Within the console, you’ll find the new Route 53 resolver configuration options within the Route 53 service console. For each inbound endpoint, you pick a subnet, security group(s) to place on the endpoint, and then decide whether to assign a static IP or let AWS choose one for you. It’s recommended to create multiple inbound endpoints, each in a separate availability zone, to ensure high availability of your endpoints. The IPs created for inbound endpoints are important to remember, because you’ll need to use these on the conditional forwarders in your on-premise network to send DNS queries into Route 53.
As an example, let’s say I have the private DNS zone cloud.acmecorp.com hosted in Route 53. I go through the process of configuring an inbound endpoint in my VPC, and I chose to create endpoints in 2 subnets, across 2 availability zones. The inbound endpoint interfaces each get an IP address assigned: 10.10.1.5 and 10.10.2.5. I can now take these 2 IP addresses, go into my on-premise DNS solution, and create a conditional forwarder which says For any DNS requests with the prefix cloud.acmecorp.com, send the resolution request to either 10.10.1.5 or 10.10.2.5. These requests will then be routed over your DirectConnect or VPN, in to your AWS VPC, and now you’re resolving DNS requests for a private zone in Route 53 with no extra services required!
Modifying your DNS configuration to take advantage of inbound endpoints
If you previously set up services in your VPC, such as Windows DNS, Unbound, or BIND, to handle forwarding requests destined for Route 53 private zones, you can now remove these. In your on-premise DNS, wherever you have forwarders pointing at these intermediate DNS services, you should update the forwarding IP addresses to point directly to your inbound endpoint IPs.
Outbound Endpoints
Outbound endpoints help route DNS requests which originate within your VPC to any external DNS service, without requiring any extra servers to be set up and managed.
In the world before the Route 53 outbound endpoints, if we wanted to allow EC2 instances in a VPC to resolve addresses for services in an on-premise network, you needed to configure your endpoints to use custom DNS resolvers (such as Windows DNS or BIND) and let those intermediary services figure out how to route the request. By doing this, you added a lot of extra configuration and overhead for managing DNS, plus you lost out on the simplicity and scalability which Route 53 offers out of the box.
With outbound endpoints, you can configure custom DNS forwarders for your VPC directly within Route 53, allowing you to leave all of your services hosted in AWS pointed directly to Route 53 for DNS resolution. Yes, you read that correctly: assuming your EC2 instances are not already using a custom DNS configuration, they are already using the Route 53 resolver!
Configuration of outbound endpoints is equally as easy as setting up inbound endpoints. Within the console, you’ll find the new Route 53 resolver configuration options within the Route 53 service console. For each outbound endpoint, you pick a subnet, security group(s) to place on the endpoint, and then decide whether to assign a static IP or let AWS choose one for you. It’s recommended to create multiple outbound endpoints, each in a separate availability zone, to ensure high availability of your endpoints. These IPs are not as important as the inbound endpoint IPs, as they’re only ever used for routing DNS requests on your behalf in to Route 53 — you don’t actually need to list them anywhere for this to start working. As long as you’ve not created any custom DNS configuration, EC2 instances in the VPC where the rule was created will automatically use that rule. The only potential place you may need to use these IPs, is if you’re whitelisting them on your on-premise firewall to allow DNS traffic from AWS.
The second part of setting up an outbound endpoint is the configuration of rules. Rules are required for every domain you wish to forward DNS requests for.
To better explain rules, let’s look at an example. Say my corporate network has 2 zones:
- 1 for active directory (ad.acmecorp.internal)
- 1 for internal corporate applications (corp.acmecorp.internal)
Somewhere in my on-premise network, there are DNS servers which are authoritative for these zones:
- ad.acmecorp.internal: 172.16.0.5, 172.16.1.5
- corp.acmecorp.internal: 172.16.50.5, 172.16.51.5
For each of the 2 corporate DNS zones, I will need to create a rule in Route 53 and associate that rule with my outbound endpoint. My Route 53 resolver rules will be the following:
- For DNS requests on the ad.acmecorp.internal prefix, forward DNS requests to 172.16.0.5 or 172.16.1.5.
- For DNS requests on the corp.acmecorp.internal prefix, forward DNS requests to 172.16.50.5 or 172.16.51.5.
With the rules in place, requests will then be routed from Route 53, to your outbound endpoint, and then over your VPC or DirectConnect into your corporate network for resolution. All without any extra servers!
To make the offering even easier to manage, the service also allows for sharing rules between AWS accounts. As an enterprise AWS administrator, you can create rules in a central account and then share them with each of your other corporate AWS accounts, so that VPCs in those accounts can take advantage of this new hybrid-DNS technology.
Modifying your DNS configuration to take advantage of outbound endpoints
If you previously set up services in your VPC, such as Windows DNS, Unbound, or BIND, to handle forwarding requests destined for corporate DNS private zones, you can now remove these. You can now create the forwarders directly within Route 53 to your corporate DNS zones and can repoint all of your AWS VPCs to using only Route 53 for DNS resolution.
A quick note on pricing
For every request that hits a Route 53 resolver endpoint, you will accrue a charge. Pricing is the same as the request pricing for the Route 53 public DNS service. Because of this, for your outbound endpoints, it’s important to make sure you’re using the built in DNS resolver in your VPC (e.g. the VPC CIDR +2 address) and not explicitly setting your EC2 instances to point to the outbound endpoint IP addresses. Remember — if you’re using the default VPC DNS configuration, your EC2 instances will already be pointed at the VPC DNS resolver (+2 address) and you will automatically be using any rules created as part of the outbound endpoint configuration.
You will still pay for DNS queries which hit endpoints, even if they go through the VPC resolver. This is why you’ll want to ensure that only requests for DNS zones in your on-premise network are hitting the outbound endpoints. AWS does offer cached DNS requests for free, however, so once a query hits a resolver endpoint the first time, future requests will be returned from the Route 53 resolver cache.
Conclusion
I am hopeful that this brief introduction to AWS’ new Route 53 Resolver for Hybrid Cloud functionality is helpful. This is a hugeeeee advancement in DNS technology on the AWS platform, and will be a gamechanger for enterprises who are jumping in to AWS and looking to minimize the amount of extra services they must manage when creating a hybrid network between existing data centers and public cloud environments. Look for some sessions at re:Invent on this new Route 53 functionality!
Thanks for reading!
