Category: AWS

AWS Route 53: How To Enable Private DNS?

admin

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.

Figure 1. Create an AWS Private Hosted Zone
Figure 1. Create an AWS Private Hosted Zone

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.

Figure 2. Create an AWS Private Hosted Zone Detail Page
Figure 2. Create an AWS Private Hosted Zone Detail Page

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.

Figure 3. Route 53 private hosted zone overview
Figure 3. Route 53 private hosted zone overview
Figure 4. Create a record in AWS hosted zone
Figure 4. Create a record in AWS hosted zone

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.

Figure 5. Multivalue Answer Routing Policy
Figure 5. Multivalue Answer Routing Policy

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.

Figure 6. Weighted Routing Policy
Figure 6. Weighted Routing Policy

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.

Figure 7. Failover Routing Policy
Figure 7. Failover Routing Policy

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.

Figure 8. AWS DNS Resolution Sample Diagram
Figure 8. AWS DNS Resolution Sample Diagram

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.

Figure 9. AWS DNS Resolution using EC2 instances
Figure 9. AWS DNS Resolution using EC2 instances

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.

Figure 9. AWS DNS Resolution using Route 53 Inbound and Outbound Resolver Endpoints
Figure 9. AWS DNS Resolution using Route 53 Inbound and Outbound Resolver Endpoints

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

AWS Networking Introduction – Part 1

admin

In this article, we introduce basic AWS Networking Concepts, such as Subnets, Route Tables, Elastic IPs, and Internet Gateways.

VPCs and CIDR Blocks

Virtual Private Cloud (VPC) is an isolated network within AWS that physically spans across all Availability Zones (AZ is a physical data center) in a region. A single AWS account can have several VPCs in the same or different regions.

VPC is assigned an IPv4 prefix (CIDR block) with the length between /16 and /28. Additional secondary IPv4 prefixes can be allocated if required.

There is no default communication between VPCs, even if they belong to the same account.

Figure 1. AWS Virtual Private Cloud (VPC)
Figure 1. AWS Virtual Private Cloud (VPC)

What is an AWS Subnet and a Route Table?

A subnet is a part of VPC’s IP CIDR block and has virtual machines or instance’s network interfaces attached to it. Subnet always belongs to a single availability zone.

Figure 2. AWS Subnets
Figure 2. AWS Subnets

All subnets can communicate with each other directly within the VPC. Routing is done by implicit AWS VPC router, which is allocated the first IP address in each subnet’s range, for example, 10.50.1.1 for the first subnet in AZ A. Second IP address in each subnet is reserved for AWS DNS server, and third address is reserved for future use.

When you create a VPC, the main route table is created and all subnets are associated with it unless you override this configuration manually.

In the diagram below, you can see that the route table has a single route for VPC’s CIDR block 10.50.0.0/16, which is marked as local. Every route table will have this route automatically installed. The rule is that no route table within VPC can contain this route (or it is components, for example, 10.50.1.0/24) as propagated or statically configured. Therefore, don’t allocate IP prefixes from a VPC CIDR block outside of the VPC.

Local routes use implicit AWS VPC router, which is a virtual router that has an interface in every subnet and cannot be bypassed for subnet-to-subnet communication.

Figure 3. AWS Route Table
Figure 3. AWS Route Table

How routing works in AWS?

With the configuration performed so far, there is no connectivity outside of the VPC. There is a single route in the main routing table 10.50.0.0/16 that allows connectivity between subnets.

Traditional routing in IP is based on the ability to direct traffic to the next-hop router using the encapsulation appropriate for the link. In Ethernet, the MAC address of the next-hop router is carried in a frame and is resolved using a broadcast-based protocol ARP. AWS routing doesn’t work in the same way.

AWS doesn’t support broadcast (and multicast). Forwarding to the first hop (or default gateway) is not based on MAC address-based forwarding. To explain this concept, let’s launch 2 instances of Windows-based OS (any version will do). On the client VM (10.50.4.20) we will configure the default gateway of 10.50.4.10 (server virtual instance).

Figure 4. AWS Routing From a Workstation (non-working)
Figure 4. Routing From a Workstation (non-working)

By default, the network adapter of an instance will not accept packets not destined to one of its addresses. To disable this behavior, Source/dest check set to false in network interface property of the server. Connectivity to external destinations outside of the VPC range is then tested by using tracert command. The expected behavior in traditional routing is for the first hop to reply, however, this didn’t happen.

In-instance routing if there are multiple interfaces only identifies the correct egress network adapter. Once the packet is transmitted and is on the subnet, the AWS route table is responsible for the forwarding. In our example, the default gateway can be configured to be any address on the 10.50.4.0/24 subnet.

What can be a next-hop for a route in the AWS route table?

In contrast to traditional routing – the IP address cannot be specified as the next hop. Available options are displayed in the screenshot below.

Figure 5. Route Table Next-Hop Options
Figure 5. Route Table Next-Hop Options

To fix the issue presented in the previous example we will select the network interface (or ENI) attached to the server instance using its resource ID. Now traceroute returns the correct first hop of 10.50.4.10.

The final configuration of route table is shown in the figure below.

Figure 6. Adjusted Main Route Table

After introducing this default route, every virtual instance in every subnet within the VPC will be sending all it’s traffic to the server, as per the main routing table configuration. What if this behavior is not desired?

What is the use case for using additional AWS route tables?

A subnet can be associated with a single route table. If a specific subnet requires different forwarding compared to other subnets, a dedicated route table can be created and associated with this subnet. For the next example, we will remove the default route from the main route table, so no Internet access will be available from all subnets in the VPC. The web server in subnet 10.50.2.0/24, requires access to and from the Internet.

As this example is about routing, we assume that Internet Gateway and Elastic IPs and are pre-configured. These concepts will be covered later. For now, a new route table is created and the required subnet is explicitly associated with it. Then the default route with the next-hop of Internet Gateway (IGW) is configured. As a result, only 1 subnet will be able to communicate with the Internet.

Figure 7. AWS VPC Additional Route Table
Figure 7. AWS VPC Additional Route Table

Internet Gateway and Elastic IPs

Internet Gateway (IGW) provides access to the Internet from VPC. It is attached to VPC and can be accessed from all subnets in VPC. It is a highly available component and AWS ensures that it is up even if one of the AZs fails. As shown in the previous section, to provide access to the Internet from a subnet, a default route is required which uses IGW as a default gateway.

The other requirement is publicly routed IP address. AWS performs NAT (Network Address Translation) and all hosts within the VPCs are using the private IP addresses. Publicly routed IP addresses are 1-to-1 mapped to an instance’s private IP address, as shown in the figure below. IGW is responsible for address translation.

Figure 8. Elastic IPs and NAT

What is Elastic IP and how it is different to Public IP?

AWS Public IP can be assigned to your instance during provisioning. It maps to the primary IP address of the primary interface (eth0) of the instance. It is dynamic and is assigned from the AWS pool and will be returned back to the pool when an instance is powered off.

Elastic IP on the other hand is assigned to your account and will be reserved, even if the instance is powered off.

Is it possible to assign multiple publicly routable IP addresses to a single interface?

Yes, it is done by assigning several secondary private IP addresses to the network interface. Then each of the elastic IPs is associated with a secondary IP address.