Resolvers – Domain Name Services – ANS-C01 Study Guide

Resolvers

DNS resolvers are at the heart of DNS functionality. Resolvers, also known as recursive resolvers, receive queries that contain the hostname and reply with the IP address of that hostname, as shown in Figure 2.7. The Route 53 Resolver acts as a bridge between your on-premise DNS infrastructure and the AWS VPC. Route 53 Resolvers in hybrid clouds enable DNS query responses in a hybrid cloud. DNS endpoints and conditional forwarding rules are used to allow the resolution for DNS between the VPC and your internal data center.

FIGURE 2.7 DNS Resolver

The AWS resolver enables bidirectional name resolution between on-premise and VPC resources. On-premise DNS records can now be queried from the AWS VPC, and the on-premise devices can query and resolve DNS records in a VPC.

A Route 53 Resolvers consists of an Amazon-provided DNS server and is provided by default as part of every AWS VPC. This DNS server fields DNS queries for AWS public resources, Route 53 private hosted zones, and names that are specific to the VPC DNS names. Resolver rules can be configured to conditionally forward DNS requests originating inside a VPC directed to an on-premise DNS resolver. By establishing a direct connection between your data center and a VPC using a VPN or Direct Connect, a VPC resolver endpoint acts as the forwarding target server of the on-premise DNS server to reply to on-premise requests to VPC resources.

Route 53 Resolver DNS Firewall

Route 53 has integrated firewall capabilities that filter outbound DNS traffic from a VPC based on rules you define. Rules are created and placed in groups that can be reused throughout your deployment. The Route 53 firewall rule groups are associated with a VPC for filtering. Firewall activity is displayed in logs and metrics that can be monitored and used to adjust your rules to filter the DNS replies. The DNS firewall allows you to monitor and control which domains your servers can query by denying access to the domains that you specify and allowing all others to be allowed to be forwarded. The opposite is also supported where you can specify which domains are trusted and allowed and block all others. Requests for specific EC2 instances can be blocked in either public or private subnets, and VPC endpoint resolution requests to resources in your VPC can also be allowed or blocked.

Health Checks

An extension for the Route 53 functionality is to health check the resources in a record before responding to queries. This prevents Route 53 DNS from delivering an IP address of a service that is down and not responding to health checks.

These health checks can be performed on any type of endpoint including web, FTP, and email servers or load balancers, as shown in Figure 2.8. Notifications of failed health checks can be configured in CloudWatch to perform any number of actions including restarting the service, running a Lambda application, or sending out alert emails.

When configuring health checking in Route 53, you must specify the endpoint service and what actions to take if the health check should fail. You will need to provide the IP address of the endpoint and the protocol to use for health checking such as HTTP, HTTPS, or TCP (three-way handshake). The failure threshold is the interval to perform the check and how many failures in a row are OK before declaring that the service is down.

Once health checking has been configured in a record, as shown in Figures 2.9 and 2.10, Route 53 will perform the checks based on its configuration. If there is a positive response, no further actions are taken. However, if there is no response from the endpoint, then Route 53 will track the number of failed responses. When the failure threshold is reached, the endpoint is declared to be in the failed state, and the defined actions are taken. However, if there is a positive response before the failure threshold, then the failure counter gets reset to zero, and no failure actions are taken.

FIGURE 2.8 Route 53 health checks