This blog post describes how to enable private DNS resolution in AWS VPC, which is used internally within a VPC or from an on-premises network. We also cover different DNS integration options between AWS VPC and on-premises networks.
How to enable AWS Route 53 Private DNS? AWS enables Private DNS in a VPC by default. An EC2 instance is automatically assigned with a non-editable hostname derived from its private IP address in <region>.compute.internal zone. An administrator can create Route 53 private hosted zones and manually manage records in them. Private zones are not reachable from the Internet and can be assigned any domain name.
Create Private Hosted Zone Step-by-step
Step 1. Open Route 53 console (https://console.aws.amazon.com/route53/) and press the “Create hosted zone” button.
Step 2. Type in any desired domain name, select “Private hosted zone,” and choose a VPC (or VPCs) to associate this zone with. Note that AWS charges a monthly fee (not prorated for partial months) for each hosted zone. There is also a usage fee for every DNS query. AWS doesn’t charge monthly fees if the zone is deleted within 12 hours. See the detailed pricing information here.
Step 3. Once the zone is created, you can add the DNS records of different types, such as A or CNAME records. Open the zone’s configuration page by clicking on it. Figure 3 shows that the private hosted zone has 2 default records – NS and SOA. Click on the Create Record button.
The screenshot above shows different types of records that you can create. Note that you cannot create NS records in a private hosted zone. This restricts the ability to delegate subdomains.
Step 4. Configure routing policies. AWS Route53 hosted zone can store multiple records of the same name and type. When clients try to resolve a DNS name Route 53 can reply with different values based on selected policy. Private hosted zones support only the following routing policies: simple, weighted, failover, and multivalue answer.
Routing Policies
Simple routing policy
In the previous step, we selected a simple routing policy for an A record – intranet.fastreroute.com with the value of 10.0.0.15. You can add additional IP addresses into the value textbox, as per its description label shown in the screenshot. If a query is made for intranet.fastreroute.com, the resolver will always return the same value (or values). You cannot create another A record for intranet.fastreroute.com when a simple routing policy is selected.
Multivalue routing policy
The next type of routing policy that you can use in private hosted zones is Multivalue Answer Policy. This routing policy looks up records of the same name and type and then randomly returns one.
To use this policy, create several records with the same name, for example, intranet.fastreroute.local of type A pointing to 10.0.0.15 and another one pointing to 10.0.0.16. To differentiate between these records, each must have a unique Record ID.
This feature allows performing simple DNS-based load balancing. To ensure that unreachable entries are not returned to clients, associate a health check with the record. Note that health checks rely on testing resources from outside of VPC via public IP addresses. For the resources that are not reachable externally, you can use CloudWatch alarms-based health checks instead.
Weighted routing policy
In the screenshot below, the weighted routing policy configuration window is shown. This option load balances traffic between multiple records with the same name and type in the same way as the Multivalue answer policy. However, traffic is distributed between multiple targets not evenly but based on the relative weight. A record with a higher weight value will be returned more often than of a lower weight.
Failover routing policy
Failover routing policy example is shown in Figure 7 and enables “active/passive” routing. The policy configuration has a field called “Failover record type,” which configures one record as primary and secondary. While the primary target is healthy, its value is returned to the client. If a failure occurs with the primary target, the secondary record’s value is returned.
Step 5. Validate that the name resolution works. Testing can be performed from an EC2 instance using a VPC DNS resolver (VPC CIDR + 2). If the resolution doesn’t work, ensure that the VPC has enableDnsHostnames, and enableDnsSupport options enabled. Detailed information on how to check if these attributes are enabled is available here.
In split-view (or split-brain) DNS deployments, when the private domain name matches the public Internet domain, an internal request (for example, from EC2 instance in VPC) is matched against private hosted zones first. If no matching private hosted zone is found, the request is resolved as a public Internet query.
How to resolve entries in private hosted zones from on-premises networks?
AWS VPC Route 53 resolvers are listening on the reserved IP address of VPC CIDR + 2 and reachable internally within the VPC. However, on-premises networks connected via VPN or DirectConnect will not be able to access these resolvers directly.
Similarly, DNS requests will not flow in the reverse direction. EC2 instances within VPC often need to resolve names via on-premises DNS servers. While EC2 instances can reach on-premises servers, it is usually better to use resolvers within VPC to minimize dependence on on-premises infrastructure. Route 53 resolvers can reply to the requests for private hosted zones. However, by default, they will try to resolve all other queries via the Internet.
To address these issues, there are 2 available options:
- Using an instance within VPC as DNS servers (managed by user)
- Using Route 53 resolver endpoints (managed by AWS)
The following example will help to understand how these 2 options work.
Route 53 and On-premises DNS Integration Limitations
In this example, we have an internal DNS domain of fastreroute.local that is used within the corporate network. We also created a private hosted zone to use in our AWS VPC– fastreroute-aws.local.
As shown in Figure 8, the on-premises network client sends its requests to the local DNS server, which provides resolution for local zone fastreroute.local and sends all other queries to the Internet. On-premises network cannot reach Route 53 resolver, which in this example has IP address of 10.50.0.2 (VPC base prefix + 2), so we can’t forward DNS requests to the resolver by using conditional forwarding. Similarly, EC2 instances in AWS send their queries to Route 53 resolver, which can reply to queries for records in Route53 private hosted zone (fastreroute-aws.local) and forwards all non-local queries to the Internet.
User-managed DNS on EC2 instances
As briefly mentioned earlier, to enable DNS resolution to work between AWS and on-premises network, we can install an EC2 instance that will run DNS server software (it can be Windows DNS service or Linux/Unix BIND). It then can forward requests from on-premises DNS servers to Route53 resolver. You can configure EC2 instances to use it instead of using Route 53 resolver, which gives the flexibility of forwarding queries to fastreroute.local to the on-premises DNS server. Figure 9 shows how the setup works.
One of the benefits of such an approach is that it allows an organization to deploy a DNS server. For example, it can be a Microsoft AD-integrated DNS server that can support Active Directory. To provide high availability, you can deploy additional EC2 instances in a different availability zone.
AWS-managed Route 53 Endpoints
The second approach is to deploy Route 53 resolver endpoints. As shown in Figure 10, there are 2 types of resolver endpoints.
Inbound endpoints accept requests from the on-premises networks over VPN or Direct Connect. Outbound endpoints provide the way to forward DNS requests to on-premises DNS servers. Forwarding rules specify requests to which domain names are forwarded via outbound endpoint to a DNS server.
Additional Resources and References
Working with private hosted zones:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html
Resolving DNS queries between VPCs and your network:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html