# Best practices for VPC Resolver
<a name="best-practices-resolver"></a>

This section provides best practices for optimizing Amazon Route 53 VPC Resolver, covering the following topics:

1. **Avoiding Loop Configurations with Resolver Endpoints:**
   + Prevent routing loops by ensuring that the same VPC is not associated with both a Resolver rule and its inbound endpoint.
   + Utilize AWS RAM to share VPCs across accounts while maintaining proper routing configurations.

   For more information, see [Avoid loop configurations with Resolver endpoints](best-practices-resolver-endpoints.md)

1. **Scaling Resolver endpoints:**
   + Implement security group rules that permit traffic based on connection state to reduce connection tracking overhead
   + Follow recommended security group rules for inbound and outbound Resolver endpoints to maximize query throughput.
   + Monitor unique IP address and port combinations generating DNS traffic to avoid capacity limitations. 

   For more information, see [Resolver endpoint scaling](best-practices-resolver-endpoint-scaling.md)

1. **High availability for Resolver endpoints:**
   + Create inbound endpoints with IP addresses in at least two Availability Zones for redundancy.
   + Provision additional network interfaces to ensure availability during maintenance or traffic surges

   For more information, see [High availability for Resolver endpoints](best-practices-resolver-endpoint-high-availability.md)

1. **Preventing DNS zone walking attacks:**
   + Be aware of potential DNS zone walking attacks, where attackers attempt to retrieve all content from DNSSEC-signed DNS zones.
   + If your endpoints experience throttling due to suspected zone walking, contact AWS Support for assistance. 

   For more information, see [DNS zone walking](best-practices-resolver-zone-walking.md)

 By following these best practices, you can optimize the performance, scalability, and security of your VPC Resolver deployments, ensuring reliable and efficient DNS resolution for your applications and resources.

# Avoid loop configurations with Resolver endpoints
<a name="best-practices-resolver-endpoints"></a>

Don't associate the same VPC to a Resolver rule and its inbound endpoint (whether it’s a direct target of the endpoint, or via an on-premises DNS server). When the outbound endpoint in a Resolver rule points to an inbound endpoint that shares a VPC with the rule, it can cause a loop where the query is continually passed between the inbound and outbound endpoints.

The forwarding rule can still be associated with other VPCs that are shared with other accounts by using AWS Resource Access Manager (AWS RAM). Private hosted zones associated with the hub, or a central VPC, will still resolve from queries to inbound endpoints because a forwarding resolver rule does not change this resolution.

# Resolver endpoint scaling
<a name="best-practices-resolver-endpoint-scaling"></a>

Resolver endpoint security groups use connection tracking to gather information about traffic to and from the endpoints. Each endpoint interface has a maximum number of connections that can be tracked, and a high volume of DNS queries can exceed the connections and cause throttling and query loss. Connection tracking is AWS's default behavior for monitoring the state of traffic flowing through security groups (SGs). Using connection tracking in SGs will reduce the throughput of traffic, however, you can implement untracked connections to reduce overhead and improve performance. For more information see [Untracked connections](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections).

If the connection tracking is enforced either by using restrictive security group rules or queries are routed through Network Load Balancer (see [Automatically tracked connections](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#automatic-tracking)), the overall maximum queries per second per IP address for an endpoint can be as low as 1500.

**Ingress and egress Security Group rule recommendations for the inbound Resolver endpoint**


****  

| 
| 
| **Ingress rules** | 
| --- |
| Protocol type | Port number | Source IP | 
| TCP  | 53 | 0.0.0.0/0 | 
| UDP | 53 | 0.0.0.0/0 | 
| **Egress rules** | 
| --- |
| Protocol type | Port number | Destination IP | 
| TCP | All | 0.0.0.0/0 | 
| UDP | All | 0.0.0.0/0 | 

**Ingress and egress security group rule recommendations for the outbound Resolver endpoint**


****  

| 
| 
| **Ingress rules** | 
| --- |
| Protocol type | Port number | Source IP | 
| TCP  | All | 0.0.0.0/0 | 
| UDP | All | 0.0.0.0/0 | 
| **Egress rules** | 
| --- |
| Protocol type | Port number | Destination IP | 
| TCP | 53 | 0.0.0.0/0 | 
| UDP | 53 | 0.0.0.0/0 | 

**Note**  
**Security group port requirements:**  
**Inbound endpoints** require ingress rules allowing TCP and UDP on port 53 to receive DNS queries from your network. Egress rules can allow all ports since the endpoint may need to respond to queries from various source ports.
**Outbound endpoints** require egress rules allowing TCP and UDP access to the ports you're using for DNS queries on your network. Port 53 is shown in the example above because it's the most common DNS port, but your network might use different ports. Ingress rules can allow all ports to accommodate responses from your DNS servers.

**Inbound Resolver endpoints**

For clients using an inbound resolver endpoint, the capacity of the elastic network interface will be impacted if you have over 40,000 unique IP address and port combinations generating the DNS traffic.

# High availability for Resolver endpoints
<a name="best-practices-resolver-endpoint-high-availability"></a>

When you create your VPC Resolver inbound endpoints, Route 53 requires that you create at least two IP addresses that the DNS resolvers on your network will forward queries to. You should also specify IP addresses in at least two Availability Zones for redundancy. 

If you require more than one elastic network interface endpoint to be available at all times, we recommend that you create at least one more network interface than you need, to make sure you have additional capacity available for handling possible traffic surges. The additional network interface also ensures availability during service operations like maintenance or upgrades.

For more information, see this detailed blog article: [How to achieve DNS high availability with Resolver endpoints](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-achieve-dns-high-availability-with-route-53-resolver-endpoints/) and [Values that you specify when you create or edit inbound endpoints](resolver-forwarding-inbound-queries-values.md).

# DNS zone walking
<a name="best-practices-resolver-zone-walking"></a>

A DNS zone walking attack attempts to get all content from DNSSEC-signed DNS zones. If VPC Resolver team detects a traffic pattern that matches the ones generated when DNS zones are walked on your endpoint, the service team will throttle the traffic on your endpoint. As a consequence you might observe a high percentage of your DNS queries timing out.

If you observe reduced capacity on your endpoints and believe that the endpoint have been throttled erroneously, go to https://console.aws.amazon.com/support/home\$1/ to create a support case.