# What is Route 53 VPC Resolver?
<a name="resolver"></a>

Route 53 VPC Resolver responds recursively to DNS queries from AWS resources for public records, Amazon VPC-specific DNS names, and Amazon Route 53 private hosted zones, and is available by default in all VPCs. 

**Note**  
Route 53 VPC Resolver was previously called Route 53 Resolver, but was renamed when Route 53 Global Resolver was introduced.

An Amazon VPC connects to a VPC Resolver at a VPC\$12 IP address. This VPC\$12 address connects to a VPC Resolver within an Availability Zone. 

A VPC Resolver automatically answers DNS queries for:
+ Local VPC domain names for EC2 instances (for example, ec2-192-0-2-44.compute-1.amazonaws.com).

  
+ Records in private hosted zones (for example, acme.example.com).
+ For public domain names, VPC Resolver performs recursive lookups against public name servers on the internet.

 

If you have workloads that leverage both VPCs and on-premises resources, you also need to resolve DNS records hosted on-premises. Similarly, these on-premises resources may need to resolve names hosted on AWS. Through Resolver endpoints and conditional forwarding rules, you can resolve DNS queries between your on-premises resources and VPCs to create a hybrid cloud setup over VPN or Direct Connect (DX). Specifically:
+ Inbound Resolver endpoints allow DNS queries to your VPC from your on-premises network or another VPC.
+ Outbound Resolver endpoints allow DNS queries from your VPC to your on-premises network or another VPC. 
+ Resolver rules enable you to create one forwarding rule for each domain name and specify the name of the domain for which you want to forward DNS queries from your VPC to an on-premises DNS resolver and from your on-premises to your VPC. Rules are applied directly to your VPC and can be shared across multiple accounts. 

The following diagram shows hybrid DNS resolution with Resolver endpoints. Note that the diagram is simplified to show only one Availability Zone.

![\[Conceptual graphic that shows the path of a DNS query from your VPC to your on-premises data storage through an Route 53 VPC Resolver outbound endpoint and the path from a DNS resolver on your network inbound endpoint back to the VPC.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/Resolver-routing.png)


The diagram illustrates the following steps:

**Outbound (solid arrows 1–5):**

1. An Amazon EC2 instance needs to resolve a DNS query to the domain internal.example.com. The authoritative DNS server is in the on-premises data center. This DNS query is sent to the VPC\$12 in the VPC that connects to VPC Resolver.

1. A VPC Resolver forwarding rule is configured to forward queries to internal.example.com in the on-premises data center.

1. The query is forwarded to an outbound endpoint.

1. The outbound endpoint forwards the query to the on-premises DNS resolver through a private connection between AWS and the data center. The connection can be either Direct Connect or AWS Site-to-Site VPN, depicted as a virtual private gateway.

1. The on-premises DNS resolver resolves the DNS query for internal.example.com and returns the answer to the Amazon EC2 instance via the same path in reverse.

**Inbound (dashed arrows a–d):**

1. A client in the on-premises data center needs to resolve a DNS query to an AWS resource for the domain dev.example.com. It sends the query to the on-premises DNS resolver. 

1. The on-premises DNS resolver has a forwarding rule that points queries to dev.example.com to an inbound endpoint. 

1. The query arrives at the inbound endpoint through a private connection, such as Direct Connect or AWS Site-to-Site VPN, depicted as a virtual gateway.

1. The inbound endpoint sends the query to VPC Resolver, and VPC Resolver resolves the DNS query for dev.example.com and returns the answer to the client via the same path in reverse.

**Topics**
+ [Resolving DNS queries between VPCs and your network](resolver-overview-DSN-queries-to-vpc.md)
+ [Route 53 VPC Resolver availability and scaling](resolver-availability-scaling.md)
+ [Getting started with Route 53 VPC Resolver](resolver-getting-started.md)
+ [Forwarding inbound DNS queries to your VPCs](resolver-forwarding-inbound-queries.md)
+ [Forwarding outbound DNS queries to your network](resolver-forwarding-outbound-queries.md)
+ [Resolver delegation rules tutorial](outbound-delegation-tutorial.md)
+ [Enabling DNSSEC validation in Amazon Route 53](resolver-dnssec-validation.md)

# Resolving DNS queries between VPCs and your network
<a name="resolver-overview-DSN-queries-to-vpc"></a>

The VPC Resolver contains endpoints that you configure to answer DNS queries to and from your on-premises environment.

**Note**  
 Forwarding private DNS queries to any VPC CIDR \$1 2 address from on-premises or other VPC DNS servers is not supported, and can cause unstable results. Instead, we recommend that you use a Resolver inbound endpoint.

You also can integrate DNS resolution between VPC Resolver and DNS resolvers on your network by configuring forwarding rules. *Your network* can include any network that is reachable from your VPC, such as the following:
+ The VPC itself
+ Another peered VPC
+ An on-premises network that is connected to AWS with Direct Connect, a VPN, or a network address translation (NAT) gateway

Before you start to forward queries, you create Resolver inbound and/or outbound endpoints in the connected VPC. These endpoints provide a path for inbound or outbound queries:

**Inbound endpoint: DNS resolvers on your network can forward DNS queries to Route 53 VPC Resolver via this endpoint**  
There are two types of inbound endpoints, a **default inbound endpoint** that forwards to IP addresses, and a **delegation inbound endpoint** that delegates the authority for a subdomain hosted in Route 53 private hosted Zone to the Route 53 VPC Resolver. Inbound endpoints allow your DNS resolvers to easily resolve domain names for AWS resources such as EC2 instances or records in a Route 53 private hosted zone. For more information, see [How DNS resolvers on your network forward DNS queries to Resolver endpoints](resolver-overview-forward-network-to-vpc.md).

**Outbound endpoint: VPC Resolver conditionally forwards queries to resolvers on your network via this endpoint**  
To forward selected queries, you create Resolver rules that specify the domain names for the DNS queries that you want to forward (such as example.com), and the IP addresses of the DNS resolvers on your network that you want to forward the queries to. If a query matches multiple rules (example.com, acme.example.com), VPC Resolver chooses the rule with the most specific match (acme.example.com) and forwards the query to the IP addresses that you specified in that rule. There are three types of rules, **forward**, **system**, and **delegation**. For more information, see [How Resolver endpoints forward DNS queries from your VPCs to your network](resolver-overview-forward-vpc-to-network.md). 

Like Amazon VPC, VPC Resolver is regional. In each region where you have VPCs, you can choose whether to forward queries from your VPCs to your network (outbound queries), from your network to your VPCs (inbound queries), or both.

You can't create Resolver endpoints in a VPC that you don't own. Only the VPC owner can create VPC-level resources such as inbound endpoints.

**Note**  
When you create a Resolver endpoint, you can't specify a VPC that has the instance tenancy attribute set to `dedicated`. For more information, see [Using VPC Resolver in VPCs that are configured for dedicated instance tenancy](resolver-choose-vpc.md#resolver-considerations-dedicated-instance-tenancy).

To use inbound or outbound forwarding, you create a Resolver endpoint in your VPC. As part of the definition of an endpoint, you specify the IP addresses, or DNS delegation, that you want to forward inbound DNS queries to or the IP addresses that you want outbound queries to originate from. For each IP address and delegation that you specify, VPC Resolver automatically creates a VPC elastic network interface.

The following diagram shows the path of a DNS query from a DNS resolver on your network to Route 53 Resolver endpoints.

![\[Conceptual graphic that shows the path of a DNS query from a DNS resolver on your network to Route 53 Resolver endpoints.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/Resolver-inbound-endpoint.png)


The following diagram shows the path of a DNS query from an EC2 instance in one of your VPCs to a DNS resolver on your network. The jyo.example.com domain uses a forwarding rule, whereas the ric.example.com subdomain has delegated the forwarding authority to VPC Resolver.

![\[Conceptual graphic that shows the path of a DNS query from your network to Route 53 VPC Resolver.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/Resolver-outbound-endpoint.png)


For an overview of VPC network interfaces, see [Elastic network interfaces](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html) in the *Amazon VPC User Guide*.

**Topics**
+ [How DNS resolvers on your network forward DNS queries to Resolver endpoints](resolver-overview-forward-network-to-vpc.md)
+ [How Resolver endpoints forward DNS queries from your VPCs to your network](resolver-overview-forward-vpc-to-network.md)
+ [Considerations when creating inbound and outbound endpoints](resolver-choose-vpc.md)

# How DNS resolvers on your network forward DNS queries to Resolver endpoints
<a name="resolver-overview-forward-network-to-vpc"></a>

To forward DNS queries from your network to Route 53 VPC Resolver, you create inbound endpoints in an AWS Region. There are two categories of inbound endpoints, **default** and **delegation**.

**Steps for creating default inbound endpoints**

1. You create a default Resolver inbound endpoint in a VPC and specify the IP addresses that the resolvers on your network forward DNS queries to, along with a VPC security group that includes inbound rules allowing TCP and UDP access on port 53. For instructions see [Configuring inbound forwarding](resolver-forwarding-inbound-queries-configuring.md).

   For each IP address that you specify for the inbound endpoint, VPC Resolver creates a VPC elastic network interface in the VPC where you created the inbound endpoint. 

1. You configure resolvers on your network to forward DNS queries for the applicable domain names to the IP addresses that you specified in the inbound endpoint. For more information, see [Considerations when creating inbound and outbound endpoints](resolver-choose-vpc.md).

**Here's how VPC Resolver resolves DNS queries that originate on your network via a default inbound endpoint:**

1. A web browser or another application on your network submits a DNS query for a domain name that you forwarded to VPC Resolver.

1. A resolver on your network forwards the query to the IP addresses in your inbound endpoint.

1. The inbound endpoint forwards the query to VPC Resolver.

1. VPC Resolver gets the applicable value for the domain name in the DNS query, either internally or by performing a recursive lookup against public name servers.

1. VPC Resolver returns the value to the inbound endpoint.

1. The inbound endpoint returns the value to the resolver on your network.

1. The resolver on your network returns the value to the application.

1. Using the value that was returned by VPC Resolver, the application submits a request, for example, a request for an object in an Amazon S3 bucket.

**Steps for creating delegation inbound endpoints**

1. You create a delegation Resolver inbound endpoint in a VPC. For instructions see [Configuring inbound forwarding](resolver-forwarding-inbound-queries-configuring.md).

   For each IP address that you specify for the inbound endpoint, VPC Resolver creates a VPC elastic network interface in the VPC where you created the inbound endpoint. 

1. You configure resolvers on your network to delegate DNS queries for the applicable domain names to VPC Resolver. For the glue records you must enter the IP addresses for the inbound endpoints. For more information, see [Considerations when creating inbound and outbound endpoints](resolver-choose-vpc.md).

**Here's how VPC Resolver resolves DNS queries that originate on your network via a delegation inbound endpoint:**

1. As a prerequisite, you must delegate the subdomain that is hosted in the private hosted zone from on-premises. Because you are delegating the subdomain via the inbound delegation endpoint, you use the inbound endpoint IP addresses as the glue records for the subdomain that's being delegated.
**Note**  
You might also need to include the glue records to make sure the DNS query is resolvable. If you delegate a subdomain to name servers that are in the same zone as the parent domain, glue records are needed.

1. A web browser or another application on your network submits a DNS query for a domain name that you delegated to the VPC Resolver.

1. A resolver on your network forwards the query to the IP addresses in your inbound endpoint.

1. The inbound endpoint delegates the query to VPC Resolver.

1. VPC Resolver returns the address to the AWS resource from the private hosted zone to the inbound endpoint.

1. The inbound endpoint returns the value to the resolver on your network.

1. The resolver on your network returns the value to the application.

1. Using the value that was returned by VPC Resolver, the application submits a request, for example, a request for an object in an Amazon S3 bucket.

Creating an inbound endpoint doesn't change the behavior of VPC Resolver, it just provides a path from a location outside the AWS network to VPC Resolver.

# How Resolver endpoints forward DNS queries from your VPCs to your network
<a name="resolver-overview-forward-vpc-to-network"></a>

When you want to forward DNS queries from the EC2 instances in one or more VPCs in an AWS Region to your network, you perform the following steps.

1. You create a Resolver outbound endpoint in a VPC, and you specify several values:
   + The VPC that you want DNS queries to pass through on the way to the resolvers on your network. 
   + A [VPC security group](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) that includes outbound rules allowing TCP and UDP access on port 53 (or the port you're using for DNS queries on your network)

   For each IP address that you specify for the outbound endpoint, VPC Resolver creates an Amazon VPC elastic network interface in the VPC that you specify. For more information, see [Considerations when creating inbound and outbound endpoints](resolver-choose-vpc.md).

1. You create one or more rules, which specify the domain names of the DNS queries that you want to delegate to VPC Resolver to forward, or want VPC Resolver to forward to resolvers on your network. For forwarding rules, you also specify the IP addresses of the resolvers. For more information, see [Using rules to control which queries are forwarded to your network](resolver-overview-forward-vpc-to-network-using-rules.md).

1. You associate each rule with the VPCs for which you want to forward DNS queries to your network.

# Using rules to control which queries are forwarded to your network
<a name="resolver-overview-forward-vpc-to-network-using-rules"></a>

Rules control which DNS queries Resolver endpoint forwards to DNS resolvers on your network and which queries VPC Resolver answers itself. 

You can categorize rules in a couple of ways. One way is by who creates the rules:
+ **Autodefined rules** – VPC Resolver automatically creates autodefined rules and associates the rules with your VPCs. Most of these rules apply to the AWS-specific domain names that VPC Resolver answers queries for. For more information, see [Domain names that VPC Resolver creates autodefined system rules for](resolver-overview-forward-vpc-to-network-autodefined-rules.md).
+ **Custom rules** – You create custom rules and associate the rules with VPCs. Currently, you can create two types of custom rules, **conditional forwarding rules**, also known as forwarding rules, and **delegation rules**. **Forwarding** rules cause VPC Resolver to forward DNS queries from your VPCs to the IP addresses for DNS resolvers on your network.

  If you create a forwarding rule for the same domain as an autodefined rule, VPC Resolver forwards queries for that domain name to DNS resolvers on your network based on the settings in the forwarding rule.

  **Delegation rules** forward DNS queries with the delegation records in the delegation rule that match the NS records in response to the resolvers on your network.

Another way to categorize rules is by what they do:
+ **Conditional forwarding rules** – You create conditional forwarding rules (also known as forwarding rules) when you want to forward DNS queries for specified domain names to DNS resolvers on your network.
+ **System rules** – System rules cause VPC Resolver to selectively override the behavior that is defined in a forwarding rule. When you create a system rule, VPC Resolver resolves DNS queries for specified subdomains that would otherwise be resolved by DNS resolvers on your network.

  By default, forwarding rules apply to a domain name and all its subdomains. If you want to forward queries for a domain to a resolver on your network but you don't want to forward queries for some subdomains, you create a system rule for the subdomains. For example, if you create a forwarding rule for example.com but you don't want to forward queries for acme.example.com, you create a system rule and specify acme.example.com for the domain name.
+ **Recursive rule** – VPC Resolver automatically creates a recursive rule named **Internet Resolver**. This rule causes Route 53 VPC Resolver to act as a recursive resolver for any domain names that you didn't create custom rules for and that VPC Resolver didn't create autodefined rules for. For information about how to override this behavior, see "Forwarding All Queries to Your Network" later in this topic.

You can create custom rules that apply to specific domain names (yours or most AWS domain names), to public AWS domains names, or to all domain names. 

**Forwarding queries for specific domain names to your network**  
To forward queries for a specific domain name, such as example.com, to your network, you create a rule and specify that domain name. For **forwarding** rules you also specify the IP addresses of the DNS resolvers on your network that you want to forward the queries to, or, for **delegation** rules, create the delegation record for which you would like to delegate the authority to on-prem resolvers. You then associate each rule with the VPCs for which you want to forward DNS queries to your network. For example, you can create separate rules for example.com, example.org, and example.net. Then you can associate the rules with the VPCs in an AWS Region in any combination.

**Forwarding queries for amazonaws.com to your network**  
The domain name amazonaws.com is the public domain name for AWS resources such as EC2 instances and S3 buckets. If you want to forward queries for amazonaws.com to your network, create a rule, specify amazonaws.com for the domain name, and specify **Forward** or **Delegation** for the rule type depending on which method you want to use.  
VPC Resolver doesn't automatically forward DNS queries for some amazonaws.com subdomains even if you create a forwarding rule for amazonaws.com. For more information, see [Domain names that VPC Resolver creates autodefined system rules for](resolver-overview-forward-vpc-to-network-autodefined-rules.md). For information about how to override this behavior, see "Forwarding All Queries to Your Network," immediately following.

**Forwarding all queries to your network**  
  
If you want to forward all queries to your network, you create a rule, specify "." (dot) for the domain name, and associate the rule with the VPCs for which you want to forward all DNS queries to your network. VPC Resolver still doesn't forward all DNS queries to your network because using a DNS resolver outside of AWS would break some functionality. For example, some internal AWS domain names have internal IP address ranges that aren't accessible from outside of AWS. For a list of the domain names for which queries aren't forwarded to your network when you create a rule for ".", see [Domain names that VPC Resolver creates autodefined system rules for](resolver-overview-forward-vpc-to-network-autodefined-rules.md).  
However, autodefined system rules for reverse DNS can be disabled, allowing the "." rule to forward all reverse DNS queries to your network. For more information on how to turn off the autodefined rules, see [Forwarding rules for reverse DNS queries in VPC Resolver](resolver-rules-managing.md#resolver-automatic-forwarding-rules-reverse-dns).  
If you want to try forwarding DNS queries for all domain names to your network, including the domain names that are excluded from forwarding by default, you can create a "." rule and do one of the following:  
+ Set the `enableDnsHostnames` flag for the VPC to `false`
+ Create rules for the domain names that are listed in [Domain names that VPC Resolver creates autodefined system rules for](resolver-overview-forward-vpc-to-network-autodefined-rules.md)
If you forward all domain names to your network, including the domain names that VPC Resolver excludes when you create a "." rule, some features might stop working.

# How VPC Resolver determines whether the domain name in a query matches any rules
<a name="resolver-overview-forward-vpc-to-network-domain-name-matches"></a>

Route 53 VPC Resolver compares the domain name in the DNS query with the domain name in the rules that are associated with the VPC that the query originated from. VPC Resolver considers the domain names to match in the following cases:
+ The domain names match exactly
+ The domain name in the query is a subdomain of the domain name in the rule

For example, if the domain name in the rule is acme.example.com, VPC Resolver considers the following domain names in a DNS query to be a match:
+ acme.example.com
+ zenith.acme.example.com

The following domain names are not a match:
+ example.com
+ nadir.example.com

If the domain name in a query matches the domain name in more than one rule (such as example.com and www.example.com), VPC Resolver routes outbound DNS queries using the rule that contains the most specific domain name (www.example.com).

# How VPC Resolver determines where to forward DNS queries
<a name="resolver-overview-forward-vpc-to-network-where-to-forward-queries"></a>

When an application that runs on an EC2 instance in a VPC submits a DNS query, Route 53 VPC Resolver performs the following steps:

1. Resolver checks for domain names in rules.

   If the domain name in a query matches the domain name in a default forward rule, VPC Resolver forwards the query to the IP address that you specified when you created the outbound endpoint. The outbound endpoint then forwards the query to the IP addresses of resolvers on your network, which you specified when you created the rule.

   If the delegation record in response matches the delegation rule, then the Resolver delegate the authority to on-prem resolvers through the outbound endpoint associated with the delegation rule.

   For more information, see [How VPC Resolver determines whether the domain name in a query matches any rules](resolver-overview-forward-vpc-to-network-domain-name-matches.md). 

1. Resolver endpoint forwards DNS queries based on the settings in the "." rule.

   If the domain name in a query doesn't match the domain name in any other rules, VPC Resolver forwards the query based on the settings in the autodefined "." (dot) rule. The dot rule applies to all domain names except some AWS internal domain names and record names in private hosted zones. This rule causes VPC Resolver to forward DNS queries to public name servers if the domain names in queries don't match any names in your custom forwarding rules. If you want to forward all queries to the DNS resolvers on your network, you can create a custom forwarding rule, specify "." for the domain name, specify **Forwarding** for **Type**, and specify the IP addresses of those resolvers. 

1. VPC Resolver returns the response to the application that submitted the query.

# Using rules in multiple Regions
<a name="resolver-overview-forward-vpc-to-network-using-rules-multiple-regions"></a>

Route 53 VPC Resolver is a regional service, so objects that you create in one AWS Region are available only in that Region. To use the same rule in more than one Region, you must create the rule in each Region.

The AWS account that created a rule can share the rule with other AWS accounts. For more information, see [Sharing Resolver rules with other AWS accounts and using shared rules](resolver-rules-managing.md#resolver-rules-managing-sharing).

# Domain names that VPC Resolver creates autodefined system rules for
<a name="resolver-overview-forward-vpc-to-network-autodefined-rules"></a>

Resolver automatically creates autodefined system rules that define how queries for selected domains are resolved by default:
+ For private hosted zones and for Amazon EC2–specific domain names (such as compute.amazonaws.com and compute.internal), autodefined rules ensure that your private hosted zones and EC2 instances continue to resolve if you create conditional forwarding rules for less specific domain names such as "." (dot) or "com".
+ For publicly reserved domain names (such as localhost and 10.in-addr.arpa), DNS best practices recommend that queries are answered locally instead of being forwarded to public name servers. See [RFC 6303, Locally Served DNS Zones](https://tools.ietf.org/html/rfc6303).

**Note**  
If you create a conditional forwarding rule for "." (dot) or "com", we recommend that you also create a system rule for amazonaws.com. (System rules cause VPC Resolver to locally resolve DNS queries for specific domains and subdomains.) Creating this system rule improves performance, reduces the number of queries that are forwarded to your network, and reduces VPC Resolver charges.

If you want to override an autodefined rule, you can create a conditional forwarding rule for the same domain name. 

You can also disable some of the autodefined rules. For more information, see [Forwarding rules for reverse DNS queries in VPC Resolver](resolver-rules-managing.md#resolver-automatic-forwarding-rules-reverse-dns). 

VPC Resolver creates the following autodefined rules.

**Rules for private hosted zones**  
For each private hosted zone that you associate with a VPC, VPC Resolver creates a rule and associates it with the VPC. If you associate the private hosted zone with multiple VPCs, VPC Resolver associates the rule with the same VPCs.  
The rule has a type of **Forward**.

**Rules for various AWS internal domain names**  
All rules for the internal domain names in this section have a type of **Forward**. VPC Resolver forwards DNS queries for these domain names to the authoritative name servers for the VPC.  
VPC Resolver creates most of these rules when you set the `enableDnsHostnames` flag for a VPC to `true`. VPC Resolver creates the rules even if you aren't using Resolver endpoints.
VPC Resolver creates the following autodefined rules and associates them with a VPC when you set the `enableDnsHostnames` flag for the VPC to `true`:   
+ *Region-name*.compute.internal, for example, eu-west-1.compute.internal. The us-east-1 Region doesn't use this domain name.
+ *Region-name*.compute.*amazon-domain-name*, for example, eu-west-1.compute.amazonaws.com or cn-north-1.compute.amazonaws.com.rproxy.goskope.com.cn. The us-east-1 Region doesn't use this domain name.
+ ec2.internal. Only the us-east-1 Region uses this domain name.
+ compute-1.internal. Only the us-east-1 Region uses this domain name.
+ compute-1.amazonaws.com. Only the us-east-1 Region uses this domain name.
The following autodefined rules are for the reverse DNS lookup for the rules that VPC Resolver creates when you set the `enableDnsHostnames` flag for the VPC to `true`.  
+ 10.in-addr.arpa
+ 16.172.in-addr.arpa through 31.172.in-addr.arpa 
+ 168.192.in-addr.arpa
+ 254.169.254.169.in-addr.arpa
+ Rules for each of the CIDR ranges for the VPC. For example, if a VPC that has a CIDR range of 10.0.0.0/23, VPC Resolver creates the following rules: 
  + 0.0.10.in-addr.arpa
  + 1.0.10.in-addr.arpa
The following autodefined rules, for localhost-related domains, also are created and associated with a VPC when you set the `enableDnsHostnames` flag for the VPC to `true`:  
+ localhost
+ localdomain
+ 127.in-addr.arpa
+ 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
+ 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
VPC Resolver creates the following autodefined rules and associates them with your VPC when you connect the VPC with another VPC through transit gateway or VPC peering, and with DNS support enabled:  
+ The reverse DNS lookup for the peer VPC's IP address ranges, for example, 0.192.in-addr.arpa

  If you add an IPv4 CIDR block to a VPC, VPC Resolver adds an autodefined rule for the new IP address range.
+ If the other VPC is in another Region, the following domain names:
  + *Region-name*.compute.internal. The us-east-1 Region doesn't use this domain name.
  + *Region-name*.compute.*amazon-domain-name*. The us-east-1 Region doesn't use this domain name.
  + ec2.internal. Only the us-east-1 Region uses this domain name.
  + compute-1.amazonaws.com. Only the us-east-1 Region uses this domain name.

**A rule for all other domains**  
VPC Resolver creates a "." (dot) rule that applies to all domain names that aren't specified earlier in this topic. The "." rule has a type of **Recursive**, which means that the rule causes VPC Resolver to act as a recursive resolver.

# Considerations when creating inbound and outbound endpoints
<a name="resolver-choose-vpc"></a>

Before you create inbound and outbound Resolver endpoints in an AWS Region, consider the following issues.

**Topics**
+ [Number of inbound and outbound endpoints in each Region](#resolver-considerations-number-of-endpoints)
+ [Using the same VPC for inbound and outbound endpoints](#resolver-considerations-same-vpc-inbound-outbound)
+ [Inbound endpoints and private hosted zones](#resolver-considerations-inbound-endpoint-private-zone)
+ [VPC peering](#resolver-considerations-vpc-peering)
+ [IP addresses in shared subnets](#resolver-considerations-shared-subnets)
+ [Connection between your network and the VPCs that you create endpoints in](#resolver-considerations-connection-between-network-and-vpcs)
+ [When you share rules, you also share outbound endpoints](#resolver-considerations-share-rules-share-outbound-endpoints)
+ [Choosing protocols for the endpoints](#resolver-endpoint-protocol-considerations)
+ [Using VPC Resolver in VPCs that are configured for dedicated instance tenancy](#resolver-considerations-dedicated-instance-tenancy)

## Number of inbound and outbound endpoints in each Region
<a name="resolver-considerations-number-of-endpoints"></a>

When you want to integrate DNS for the VPCs in an AWS Region with DNS for your network, you typically need one Resolver inbound endpoint (for DNS queries that you're forwarding to your VPCs) and one outbound endpoint (for queries that you're forwarding from your VPCs to your network). You can create multiple inbound endpoints and multiple outbound endpoints, but one inbound or outbound endpoint is sufficient to handle the DNS queries for each respective direction. Note the following:
+ For each Resolver endpoint, you specify two or more IP addresses in different Availability Zones. Each IP address in an endpoint can handle a large number of DNS queries per second. (For the current maximum number of queries per second per IP address in an endpoint, see [Quotas on Route 53 VPC Resolver](DNSLimitations.md#limits-api-entities-resolver).) If you need VPC Resolver to handle more queries, you can add more IP addresses to your existing endpoint instead of adding another endpoint.
+ VPC Resolver pricing is based on the number of IP addresses in your endpoints and on the number of DNS queries that the endpoint processes. Each endpoint includes a minimum of two IP addresses. For more information about VPC Resolver pricing, see [Amazon Route 53 Pricing](https://aws.amazon.com/route53/pricing/).
+ Each rule specifies the outbound endpoint that DNS queries are forwarded from. If you create multiple outbound endpoints in an AWS Region and you want to associate some or all Resolver rules with every VPC, you need to create multiple copies of those rules.

## Using the same VPC for inbound and outbound endpoints
<a name="resolver-considerations-same-vpc-inbound-outbound"></a>

You can create inbound and outbound endpoints in the same VPC or in different VPCs in the same Region.

For more information, see [Best practices for Amazon Route 53](best-practices.md). 

## Inbound endpoints and private hosted zones
<a name="resolver-considerations-inbound-endpoint-private-zone"></a>

If you want VPC Resolver to resolve inbound DNS queries using records in a private hosted zone, associate the private hosted zone with the VPC that you created the inbound endpoint in. For information about associating private hosted zones with VPCs, see [Working with private hosted zones](hosted-zones-private.md).

## VPC peering
<a name="resolver-considerations-vpc-peering"></a>

You can use any VPC in an AWS Region for an inbound or an outbound endpoint regardless of whether the VPC that you choose is peered with other VPCs. For more information, see [Amazon Virtual Private Cloud VPC peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html).

## IP addresses in shared subnets
<a name="resolver-considerations-shared-subnets"></a>

When you create an inbound or outbound endpoint, you can specify an IP address in a shared subnet only if the current account created the VPC. If another account creates a VPC and shares a subnet in the VPC with your account, you can't specify an IP address in that subnet. For more information about shared subnets, see [Working with shared VPCs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html) in the *Amazon VPC User Guide*.

## Connection between your network and the VPCs that you create endpoints in
<a name="resolver-considerations-connection-between-network-and-vpcs"></a>

You must have one of the following connections between your network and the VPCs that you create endpoints in:
+ **Inbound endpoints** – You must set up either an [Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) connection or a [VPN connection](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html) between your network and each VPC that you create an inbound endpoint for.
+ **Outbound endpoints** – You must set up an [Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) connection, a [VPN connection](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html), or a [network address translation (NAT) gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) between your network and each VPC that you create an outbound endpoint for.

## When you share rules, you also share outbound endpoints
<a name="resolver-considerations-share-rules-share-outbound-endpoints"></a>

When you create a rule, you specify the outbound endpoint that you want VPC Resolver to use to forward DNS queries to your network. If you share the rule with another AWS account, you also indirectly share the outbound endpoint that you specify in the rule. If you used more than one AWS account to create VPCs in an AWS Region, you can do the following:
+ Create one outbound endpoint in the Region.
+ Create rules using one AWS account.
+ Share the rules with all the AWS accounts that created VPCs in the Region.

This allows you to use one outbound endpoint in a Region to forward DNS queries to your network from multiple VPCs even if the VPCs were created using different AWS accounts.

## Choosing protocols for the endpoints
<a name="resolver-endpoint-protocol-considerations"></a>

Endpoint protocols determine how data is transmitted to an inbound endpoint and from an outbound endpoint. Encrypting DNS queries for VPC traffic is not needed because every packet flow on the network is individually authorized against a rule to validate the correct source and destination before it is transmitted and delivered. It is highly improbable for information to arbitrarily pass between entities without specifically being authorized by both the transmitting and receiving entity. If a packet is being routed to a destination without a rule that matches it, the packet is dropped. For more information, see [VPC features](https://docs.aws.amazon.com/whitepapers/latest/logical-separation/vpc-and-accompanying-features.html).

The available protocols are:
+ **Do53:** DNS over port 53. The data is relayed by using the VPC Resolver without additional encryption. While the data cannot be read by external parties, it can be viewed within the AWS networks. Uses either UDP or TCP to send the packets. Do53 is primarily used for traffic within and between Amazon VPCs. Currently, this is the only protocol available for delegation inbound endpoints.
+ **DoH:** The data is transmitted over an encrypted HTTPS session. DoH adds an added level of security where data can't be decrypted by unauthorized users, and cannot be read by anyone except the intended recipient. Not available for delegation inbound endpoints.
+ **DoH-FIPS:** The data is transmitted over an encrypted HTTPS session that is compliant with the FIPS 140-2 cryptographic standard. Supported for inbound endpoints only. For more information, see [FIPS PUB 140-2](https://doi.org/10.6028/NIST.FIPS.140-2). Not available for delegation inbound endpoints.

For an inbound endpoint of type **Forward**, you can apply the protocols as follows:
+  Do53 and DoH in combination.
+ Do53 and DoH-FIPS in combination.
+ Do53 alone.
+ DoH alone.
+ DoH-FIPS alone.
+ None, which is treated as Do53.

For an outbound endpoint you can apply the protocols as follows:
+  Do53 and DoH in combination.
+ Do53 alone.
+ DoH alone.
+ None, which is treated as Do53.

See also [Values that you specify when you create or edit inbound endpoints](resolver-forwarding-inbound-queries-values.md) and [Values that you specify when you create or edit outbound endpoints](resolver-forwarding-outbound-queries-endpoint-values.md).

## Using VPC Resolver in VPCs that are configured for dedicated instance tenancy
<a name="resolver-considerations-dedicated-instance-tenancy"></a>

When you create a Resolver endpoint, you can't specify a VPC that has the [instance tenancy attribute](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html) set to `dedicated`. VPC Resolver doesn't run on single-tenant hardware.

You can still use VPC Resolver to resolve DNS queries that originate in a VPC. Create at least one VPC that has the instance tenancy attribute set to `default`, and specify that VPC when you create inbound and outbound endpoints.

When you create a forwarding rule, you can associate it with any VPC, regardless of the setting for the instance tenancy attribute.

# Route 53 VPC Resolver availability and scaling
<a name="resolver-availability-scaling"></a>

Route 53 VPC Resolver, running on the Amazon VPC CIDR \$1 2 address and fd00:ec2::253, is available by default in all VPCs, and responds recursively to DNS queries for public records, Amazon VPC-specific DNS names, and Route 53 private hosted zones. There are two highly available components, transparent to users, that make up the Route 53 VPC Resolver: the Nitro Resolver service and the Zonal Resolver fleet. The Nitro Resolver Service is a service that runs in the Nitro card on Nitro instances and in Dom0 in older generation instances, and consumes packets addressed to the Route 53 VPC Resolver locally on the host server. For more information, see [The Security Design of the AWS Nitro System](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html). 

The Nitro Resolver service carries a local cache which can help reduce latency by responding to repeat queries which are made over a short period of time by an instance. When the Nitro Resolver service receives a query which it does not have a cached answer for, it forwards the query to the Zonal Resolver fleet, a highly available fleet of resolvers typically in the same Availability Zone as the instance. When there are failures handling queries by upstream name servers or other components in the path, the Nitro Resolver service is frequently able to handle these failures transparently without impact to the workloads running on the instance. Furthermore, if the Resolver encounters query timeouts, refused connections, or SERVFAILS from the domain’s name servers, it may respond with a cached answer beyond the Time-To-Live (TTL) value to improve availability. Queries between the Nitro Resolver service and Zonal Resolver fleet are restricted to a tightly controlled network outside of the customer VPC, which is inaccessible to customers and subject to rigorous security controls. By handling queries between the Nitro Resolver service and Zonal Resolver fleet outside of the VPC, customers are prevented from intercepting DNS queries inside of their VPC. Queries destined to name servers outside of AWS will traverse the public internet, originating from public IP addresses belonging to the Zonal Resolver fleet. We do not support the EDNS0-Client Subnet attribute today, which means all queries destined to public DNS name servers do not include information about the originating customer IP address. 

The Nitro Resolver service is part of the Link-Local services on the instance. Link-Local services include Route 53 VPC Resolver, Amazon Time Service (NTP), Instance Metadata Service (IMDS) and Windows Licensing Service (for Windows instances). These services scale with each elastic network interface you create in your VPC, and each network interface allows 1024 packets per second (PPS) destined to Link-Local services. Packets exceeding this limit are rejected. You can determine if you have exceeded this limit from the `linklocal_allowance_exceeded` value returned by ethtool. For more information about the ethtool, see [Monitor network performance for your Amazon EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) in the *Amazon EC2 User Guide*. This metric can also be reported to CloudWatch metrics by the CloudWatch Agent. Since the Route 53 VPC Resolver is implemented per network interface, it scales and becomes more reliable as you add more instances in more Availability Zones. There is no per-VPC aggregate limit on the number of queries, thus the Route 53 VPC Resolver can scale within the bounds of a VPC, which is inherently based on network address usage (NAU). For more information, see [Network Address Usage for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/network-address-usage.html) in the *Amazon Virtual Private Cloud User Guide*.

The following diagram shows an overview of how Route 53 VPC Resolver resolves DNS queries within Availability Zones.

![\[Conceptual graphic that shows how Route 53 VPC Resolver resolves DNS queries within Availability Zones.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/Resolver-scale-availability2.png)


# Getting started with Route 53 VPC Resolver
<a name="resolver-getting-started"></a>

The Route 53 VPC Resolver console includes a wizard that guides you through the following steps for getting started with VPC Resolver:
+ Create endpoints: inbound, outbound, or both.
+ For outbound endpoints, create one or more forwarding rules, which specify the domain names for which you want to route DNS queries to your network.
+ If you created an outbound endpoint, choose the VPC that you want to associate the rules with.<a name="resolver-getting-started-procedure"></a>

**To configure Route 53 VPC Resolver using the wizard**

1. Sign in to the AWS Management Console and open the VPC Resolver console at [https://console.aws.amazon.com/route53resolver/](https://console.aws.amazon.com/route53resolver/).

1. On the **Welcome to Route 53 VPC Resolver** page, choose **Configure endpoints**.

1. On the navigation bar, choose the Region where you want to create a Resolver endpoint.

1. Under **Basic configuration**, choose the direction that you want to forward DNS queries:
   + **Inbound and outbound**: The wizard guides you through settings that let you both forward DNS queries from resolvers on your network to VPC Resolver in a VPC, and forward specified queries (such as example.com or example.net) from a VPC to resolvers on your network. 
   + **Inbound only**: The wizard guides you through settings that let you forward DNS queries from resolvers on your network to VPC Resolver in a VPC.
   + **Outbound only**: The wizard guides you through settings that let you forward specified queries from a VPC to resolvers on your network.

1. Choose **Next**.

1. If you chose **Inbound and outbound** or **Inbound only**, enter the applicable values for configuring an inbound endpoint. Then continue with step 7. For more information, see [Values that you specify when you create or edit inbound endpoints](resolver-forwarding-inbound-queries-values.md).

   If you choose **Outbound only**, skip to step 7.

1. Enter the applicable values for configuring an outbound endpoint. For more information, see [Values that you specify when you create or edit outbound endpoints](resolver-forwarding-outbound-queries-endpoint-values.md).

1. If you chose **Inbound and outbound** or **Outbound only**, enter the applicable values for creating a rule. For more information, see [Values that you specify when you create or edit rules](resolver-forwarding-outbound-queries-rule-values.md).

1. On the **Review and create** page, confirm that the settings that you specified on previous pages are correct. If necessary, choose **Edit** for the applicable section, and update settings. When you're satisfied with the settings, choose **Submit**.
**Note**  
Creating an outbound endpoint takes a minute or two. You can't create another outbound endpoint until the first one is created.

1. If you want to create more rules, see [Managing forwarding rules](resolver-rules-managing.md).

1. If you created an inbound endpoint, configure DNS resolvers on your network to forward the applicable DNS queries to the IP addresses for your inbound endpoint. For more information, refer to the documentation for your DNS application.

# Forwarding inbound DNS queries to your VPCs
<a name="resolver-forwarding-inbound-queries"></a>

To forward DNS queries from your network to VPC Resolver, you create an inbound endpoint. An inbound endpoint specifies the IP addresses (from the range of IP addresses available to your VPC) that you want DNS resolvers on your network to forward DNS queries to. Those IP addresses aren't public IP addresses, so for each inbound endpoint, you need to connect your VPC to your network using either an Direct Connect connection or a VPN connection.

When implementing inbound delegation, you're delegating DNS authority for a subdomain from your on-premises DNS infrastructure to VPC Resolver. To properly configure this delegation, you must use the inbound endpoint's IP addresses as glue records (NS records) on your on-premises name server for the subdomain being delegated. For example, if you're delegating the subdomain "aws.example.com" to VPC Resolver through an inbound delegation endpoint with IP addresses 10.0.1.100 and 10.0.1.101, you would create NS records on your on-premises DNS server pointing "aws.example.com" to these IP addresses. This makes sure that DNS queries for the delegated subdomain are properly routed to the VPC Resolver via the inbound endpoint, allowing the VPC Resolver to respond with records from the associated private hosted zone.

# Configuring inbound forwarding
<a name="resolver-forwarding-inbound-queries-configuring"></a>

To create an inbound endpoint, perform the following procedure.<a name="resolver-forwarding-inbound-queries-configuring-procedure"></a>

**To create an inbound endpoint**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, choose **Inbound endpoints**.

1. On the navigation bar, choose the Region where you want to create an inbound endpoint.

1. Choose **Create inbound endpoint**.

1. Enter the applicable values. For more information, see [Values that you specify when you create or edit inbound endpoints](resolver-forwarding-inbound-queries-values.md).

1. Choose **Create**.

1. Configure DNS resolvers on your network to forward the applicable DNS queries to the IP addresses for your inbound endpoint. For more information, refer to the documentation for your DNS application.

# Values that you specify when you create or edit inbound endpoints
<a name="resolver-forwarding-inbound-queries-values"></a>

When you create or edit an inbound endpoint, you specify the following values:

**Outpost ID**  
If you are creating the endpoint for a VPC Resolver on an AWS Outposts VPC, this is the AWS Outposts ID.

**Endpoint name**  
A friendly name that lets you easily find an inbound endpoint on the dashboard.

**Endpoint category**  
Choose either **Default** or **Delegation**. When the category is **Default**, the resolver on your network forwards the DNS requests to the IP address of the inbound endpoint. When the category is **Delegation**, the authority for a domain is delegated to the VPC Resolver.

**VPC in the *region-name* Region**  
All inbound DNS queries from your network pass through this VPC on the way to VPC Resolver.

**Security group for this endpoint**  
The ID of one or more security groups that you want to use to control access to this VPC. The security group that you specify must include one or more inbound rules. Inbound rules must allow TCP and UDP access on port 53. If you are using the DoH protocol, you will also have to allow port 443 in security group.You can't change this value after you create the endpoint.  
Some security group rules will cause your connection to be tracked and the overall maximum queries per second per IP address for an inbound endpoint can be as low as 1500. To avoid connection tracking caused by a security group, see [Untracked connections](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections).  
In order to add multiple security groups, use the AWS CLI command `create-resolver-endpoint`. For more information, see [create-resolver-endpoint](https://docs.aws.amazon.com/cli/latest/reference/route53resolver/create-resolver-endpoint.html)
For more information, see [Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) in the *Amazon VPC User Guide*.

**Endpoint type**  
The endpoint type can be either IPv4, IPv6, or dual-stack IP addresses. For a dual-stack endpoint, the endpoint will have both IPv4 and IPv6 address that your DNS resolver on your network can forward DNS query to.   
For security reasons, we are denying direct IPv6 traffic access from the public internet for all dual-stack and IPv6 IP addresses. 

**IP addresses**  
The IP addresses that you want DNS resolvers on your network to forward DNS queries to. We require you to specify a minimum of two IP addresses for redundancy. If you created a delegation inbound endpoint, use these IP addresses as the glue NS records for the subdomain for which you want to delegate the authority to VPC Resolver. Note the following:    
**Multiple Availability Zones**  
We recommend that you specify IP addresses in at least two Availability Zones. You can optionally specify additional IP addresses in those or other Availability Zones.  
**IP addresses and Amazon VPC elastic network interfaces**  
For each combination of Availability Zone, Subnet, and IP address that you specify, VPC Resolver creates an Amazon VPC elastic network interface. For the current maximum number of DNS queries per second per IP address in an endpoint, see [Quotas on Route 53 VPC Resolver](DNSLimitations.md#limits-api-entities-resolver). For information about pricing for each elastic network interface, see "Amazon Route 53" on the [Amazon Route 53 pricing page](https://aws.amazon.com/route53/pricing/). 
Resolver endpoint has a private IP address. These IP addresses will not change through the course of an endpoint's life.
For each IP address, specify the following values. Each IP address must be in an Availability Zone in the VPC that you specified in **VPC in the *region-name* Region**.    
**Availability Zone**  
The Availability Zone that you want DNS queries to pass through on the way to your VPC. The Availability Zone that you specify must be configured with a subnet.  
**Subnet**  
The subnet that contains the IP addresses you want assigned to your Resolver endpoint ENIs. These are the addresses you will send DNS queries to. The subnet must have an available IP address.  
The subnet IP address must match the **Endpoint type**.  
**IP address**  
The IP address that you want to assign to the inbound endpoints.  
Choose whether you want VPC Resolver to choose an IP address for you from among the available IP addresses in the specified subnet, or you want to specify the IP address yourself.  
If you choose to specify the IP address yourself, enter either an IPv4 or IPv6 address, or both.

**Protocols**  
Endpoint protocol determines how data is transmitted to the inbound endpoint. Choose a protocol, or protocols, depending on the level of security needed.  
+ **Do53:** (Default) The data is relayed using the Route 53 VPC Resolver without additional encryption. While the data cannot be read by external parties, it can be viewed within the AWS networks. This is the only protocol currently available for the **Delegation** inbound endpoint category.
+ **DoH:** The data is transmitted over an encrypted HTTPS session. DoH adds an added level of security where data can't be decrypted by unauthorized users, and can't be read by anyone except the intended recipient.
+ **DoH-FIPS:** The data is transmitted over an encrypted HTTPS session that is compliant with the FIPS 140-2 cryptographic standard. Supported for inbound endpoints only. For more information, see [FIPS PUB 140-2](https://doi.org/10.6028/NIST.FIPS.140-2).
**Note**  
For DoH/DoH-FIPS inbound endpoints, there is a known issue with incorrect source IP being published in the VPC Resolver query logging.
For an inbound endpoint you can apply the protocols as follows:  
+  Do53 and DoH in combination.
+ Do53 and DoH-FIPS in combination.
+ Do53 alone.
+ DoH alone.
+ DoH-FIPS alone.
+ None, which is treated as Do53.
 You can't change the protocol of an inbound endpoint directly from only Do53 to only DoH, or DoH-FIPS. This is to prevent a sudden disruption to incoming traffic that relies on Do53. To change the protocol from Do53 to DoH, or DoH-FIPS, you must first enable both Do53 and DoH, or Do53 and DoH-FIPS, to make sure that all incoming traffic has transferred to using the DoH protocol, or DoH-FIPS, and then remove the Do53.

**Tags**  
Specify one or more keys and the corresponding values. For example, you might specify **Cost center** for **Key** and specify **456** for **Value**.

# Managing inbound endpoints
<a name="resolver-forwarding-inbound-queries-managing"></a>

To manage inbound endpoints, perform the applicable procedure.

**Topics**
+ [Viewing and editing inbound endpoints](#resolver-forwarding-inbound-queries-managing-viewing)
+ [Viewing the status for inbound endpoints](#resolver-forwarding-inbound-queries-managing-viewing-status)
+ [Deleting inbound endpoints](#resolver-forwarding-inbound-queries-managing-deleting)

## Viewing and editing inbound endpoints
<a name="resolver-forwarding-inbound-queries-managing-viewing"></a>

To view and edit settings for an inbound endpoint, perform the following procedure.<a name="resolver-forwarding-inbound-queries-managing-viewing-procedure"></a>

**To view and edit settings for an inbound endpoint**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, choose **Inbound endpoints**.

1. On the navigation bar, choose the Region where you created the inbound endpoint.

1. Choose the option for the endpoint that you want to view settings for or want to edit.

1. Choose **View details** or **Edit**.

   For information about the values for inbound endpoints, see [Values that you specify when you create or edit inbound endpoints](resolver-forwarding-inbound-queries-values.md).

1. If you chose **Edit**, enter the applicable values, and choose **Save**.

## Viewing the status for inbound endpoints
<a name="resolver-forwarding-inbound-queries-managing-viewing-status"></a>

To view the status for an inbound endpoint, perform the following procedure.<a name="resolver-forwarding-inbound-queries-managing-viewing-status-procedure"></a>

**To view the status for an inbound endpoint**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, choose **Inbound endpoints**.

1. On the navigation bar, choose the Region where you created the inbound endpoint. The **Status** column contains one of the following values:  
**Creating**  
VPC Resolver is creating and configuring one or more Amazon VPC network interfaces for this endpoint.  
**Operational**  
The Amazon VPC network interfaces for this endpoint are correctly configured and able to pass inbound or outbound DNS queries between your network and VPC Resolver.  
**Updating**  
VPC Resolver is associating or disassociating one or more network interfaces with this endpoint.  
**Auto recovering**  
VPC Resolver is trying to recover one or more of the network interfaces that are associated with this endpoint. During the recovery process, the endpoint functions with limited capacity because of the limit on the number of DNS queries per IP address (per network interface). For the current limit, see [Quotas on Route 53 VPC Resolver](DNSLimitations.md#limits-api-entities-resolver).  
**Action needed**  
This endpoint is unhealthy, and VPC Resolver can't automatically recover it. To resolve the problem, we recommend that you check each IP address that you associated with the endpoint. For each IP address that isn't available, add another IP address and then delete the IP address that isn't available. (An endpoint must always include at least two IP addresses.) A status of **Action needed** can have a variety of causes. Here are two common causes:  
   + One or more of the network interfaces that are associated with the endpoint were deleted using Amazon VPC.
   + The network interface couldn't be created for some reason that's outside the control of VPC Resolver.  
**Deleting**  
VPC Resolver is deleting this endpoint and the associated network interfaces.

## Deleting inbound endpoints
<a name="resolver-forwarding-inbound-queries-managing-deleting"></a>

To delete an inbound endpoint, perform the following procedure.

**Important**  
If you delete an inbound endpoint, DNS queries from your network are no longer forwarded to VPC Resolver in the VPC that you specified in the endpoint. <a name="resolver-forwarding-inbound-queries-managing-deleting-procedure"></a>

**To delete an inbound endpoint**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, choose **Inbound endpoints**.

1. On the navigation bar, choose the Region where you created the inbound endpoint.

1. Choose the option for the endpoint that you want to delete.

1. Choose **Delete**.

1. To confirm that you want to delete the endpoint, enter the name of the endpoint and choose **Submit**.

# Forwarding outbound DNS queries to your network
<a name="resolver-forwarding-outbound-queries"></a>

To forward DNS queries that originate on Amazon EC2 instances in one or more VPCs to your network, you create an outbound endpoint and one or more rules:

**Outbound endpoint**  
To forward DNS queries from your VPCs to your network, you create an outbound endpoint. An outbound endpoint specifies the IP addresses that queries originate from. Those IP addresses, which you choose from the range of IP addresses available to your VPC, aren't public IP addresses. This means that, for each outbound endpoint, you need to connect your VPC to your network using Direct Connect connection, a VPN connection, or a network address translation (NAT) gateway. Note that you can use the same outbound endpoint for multiple VPCs in the same Region, or you can create multiple outbound endpoints. If you want your outbound endpoint to use DNS64, you can enable DNS64 using Amazon Virtual Private Cloud. For more information, see [DNS64 and NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-nat64-dns64) in the *Amazon VPC User Guide*.  
The target IP from the VPC Resolver rule is chosen at random by VPC Resolver and there is no preference on choosing a particular target IP over the other. If a target IP does not respond to the DNS request forwarded, the VPC Resolver will retry to a random IP address among the target IPs.  
Make sure that all the target IP addresses are reachable from the Resolver endpoints. If VPC Resolver is not able forward outbound DNS queries to any of the target IP, it can lead to extended DNS resolution times. 

**Rules**  
To specify the domain names of the queries that you want to forward to DNS resolvers on your network, you create one or more rules. Each forwarding rule specifies one domain name. You then associate rules with the VPCs for which you want to forward queries to your network.   
Outbound delegation rules follow specific delegation principles that differ from standard forwarding rules. When you create a delegation rule, VPC Resolver evaluates the delegation records in the rule against the NS records in DNS responses to determine if delegation should occur. The VPC Resolver will delegate authority to your on-premises resolvers only when there's a match between the delegation rule configuration and the actual NS records returned in the DNS response. Unlike forwarding rules that redirect queries based on domain name matching, delegation rules respect the DNS delegation chain and only activate when the authoritative name servers in the response match the delegation configuration.  
For more information, see the following topics:  
+ [Private hosted zones that have overlapping namespaces](hosted-zone-private-considerations.md#hosted-zone-private-considerations-private-overlapping)
+ [Private hosted zones and Route 53 VPC Resolver rules](hosted-zone-private-considerations.md#hosted-zone-private-considerations-resolver-rules)

# Configuring outbound forwarding
<a name="resolver-forwarding-outbound-queries-configuring"></a>

To configure VPC Resolver to forward DNS queries that originate in your VPC to your network, perform the following procedures.

**Important**  
After you create an outbound endpoint, you must create one or more rules and associate them with one or more VPCs. Rules specify the domain names of the DNS queries that you want to forward to your network.<a name="resolver-forwarding-outbound-queries-configuring-create-endpoint-procedure"></a>

**To create an outbound endpoint**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, choose **Outbound endpoints**.

1. On the navigation bar, choose the Region where you want to create an outbound endpoint.

1. Choose **Create outbound endpoint**.

1. Enter the applicable values. For more information, see [Values that you specify when you create or edit outbound endpoints](resolver-forwarding-outbound-queries-endpoint-values.md).

1. Choose **Create**.
**Note**  
Creating an outbound endpoint takes a minute or two. You can't create another outbound endpoint until the first one is created.

1. Create one or more rules to specify the domain names of the DNS queries that you want to forward to your network. For more information, see the next procedure.

To create one or more forwarding rules, perform the following procedure.<a name="resolver-forwarding-outbound-queries-configuring-create-rule-procedure"></a>

**To create forwarding rules and associate the rules with one or more VPCs**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, choose **Rules**.

1. On the navigation bar, choose the Region where you want to create the rule.

1. Choose **Create rule**.

1. Enter the applicable values. For more information, see [Values that you specify when you create or edit rules](resolver-forwarding-outbound-queries-rule-values.md).

1. Choose **Save**.

1. To add another rule, repeat steps 4 through 6. 

# Values that you specify when you create or edit outbound endpoints
<a name="resolver-forwarding-outbound-queries-endpoint-values"></a>

When you create or edit an outbound endpoint, you specify the following values:

**Outpost ID**  
If you are creating the endpoint for a VPC Resolver on an AWS Outposts VPC, this is the AWS Outposts ID.

**Endpoint name**  
A friendly name that lets you easily find an outbound endpoint on the dashboard.

**VPC in the *region-name* Region**  
All outbound DNS queries will flow through this VPC on the way to your network.

**Security group for this endpoint**  
The ID of one or more security groups that you want to use to control access to this VPC. The security group that you specify must include one or more outbound rules. Outbound rules must allow TCP and UDP access on the port that you're using for DNS queries on your network. You can't change this value after you create an endpoint.   
Some security group rules will cause your connection to be tracked and potentially impact the maximum queries per second from outbound endpoint to your target name server. To avoid connection tracking caused by a security group, see [Untracked connections](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections).  
For more information, see [Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) in the *Amazon VPC User Guide*.

**Endpoint type**  
The endpoint type can be either IPv4, IPv6, or dual-stack IP addresses. For a dual-stack endpoint, the endpoint will have both IPv4 and IPv6 address that your DNS resolver on your network can forward DNS query to.   
For security reasons, we are denying direct IPv6 traffic access to the public internet for all dual-stack and IPv6 IP addresses.

**IP addresses**  
The IP addresses in your VPC that you want VPC Resolver to forward DNS queries to on the way to resolvers on your network. These are not the IP addresses of the DNS resolvers on your network; you specify resolver IP addresses when you create the rules that you associate with one or more VPCs. We require you to specify a minimum of two IP addresses for redundancy.   
Resolver endpoint has a private IP address. These IP addresses will not change through the course of an endpoint's life.
Note the following:    
**Multiple Availability Zones**  
We recommend that you specify IP addresses in at least two Availability Zones. You can optionally specify additional IP addresses in those or other Availability Zones.  
**IP addresses and Amazon VPC elastic network interfaces**  
For each combination of Availability Zone, Subnet, and IP address that you specify, VPC Resolver creates an Amazon VPC elastic network interface. For the current maximum number of DNS queries per second per IP address in an endpoint, see [Quotas on Route 53 VPC Resolver](DNSLimitations.md#limits-api-entities-resolver). For information about pricing for each elastic network interface, see "Amazon Route 53" on the [Amazon Route 53 pricing page](https://aws.amazon.com/route53/pricing/).  
**Order of IP addresses**  
You can specify IP addresses in any order. When forwarding DNS queries, VPC Resolver doesn't choose IP addresses based on the order that the IP addresses are listed in.
For each IP address, specify the following values. Each IP address must be in an Availability Zone in the VPC that you specified in **VPC in the *region-name* Region**.    
**Availability Zone**  
The Availability Zone that you want DNS queries to pass through on the way to your network. The Availability Zone that you specify must be configured with a subnet.  
**Subnet**  
The subnet that contains the IP address that you want DNS queries to originate from on the way to your network. The subnet must have an available IP address.  
The subnet IP address must match the **Endpoint type**.  
**IP address**  
The IP address that you want DNS queries to originate from on the way to your network.  
Choose whether you want VPC Resolver to choose an IP address for you from among the available IP addresses in the specified subnet, or you want to specify the IP address yourself.  
If you choose to specify the IP address yourself, enter an IPv4 or IPv6 address, or both.

**Protocols**  
Endpoint protocol determines how data is transmitted from the outbound endpoint. Choose a protocol, or protocols, depending on the level of security needed.  
+ **Do53:** (Default) The data is relayed using the Route 53 VPC Resolver without additional encryption. While the data cannot be read by external parties, it can be viewed within the AWS networks.
+ **DoH:** The data is transmitted over an encrypted HTTPS session. DoH adds an added level of security where data can't be decrypted by unauthorized users, and can't be read by anyone except the intended recipient.
For an outbound endpoint you can apply the protocols as follows:  
+  Do53 and DoH in combination.
+ Do53 alone.
+ DoH alone.
+ None, which is treated as Do53.

**Tags**  
Specify one or more keys and the corresponding values. For example, you might specify **Cost center** for **Key** and specify **456** for **Value**.

# Values that you specify when you create or edit rules
<a name="resolver-forwarding-outbound-queries-rule-values"></a>

When you create or edit a forwarding rule, you specify the following values:

**Rule name**  
A friendly name that lets you easily find a rule on the dashboard.

**Rule type**  
Choose the applicable value:  
+ **Forward** – Choose this option when you want to forward DNS queries for a specified domain name to resolvers on your network.
+ **Delegate** – Choose this option when you want to delegate authority for a subdomain, hosted in a private hosted zone, to your on-premises resolver (or to a VPC Resolver on another VPC).
+ **System** – Choose this option when you want VPC Resolver to selectively override the behavior that is defined in a forwarding rule. When you create a system rule, VPC Resolver resolves DNS queries for specified subdomains that would otherwise be resolved by DNS resolvers on your network.
By default, forwarding rules apply to a domain name and all its subdomains. If you want to forward queries for a domain to a resolver on your network but you don't want to forward queries for some subdomains, you create a system rule for the subdomains. For example, if you create a forwarding rule for example.com but you don't want to forward queries for acme.example.com, you create a system rule and specify acme.example.com for the domain name.

**Delegation record – for delegate rule only**  
DNS queries that mach to this domain are forwarded to the resolvers on your network.  
As a prerequisite for a delegate rule you must create NS records in the private hosted zone, when using private hosted zone to outbound delegation The record is: NS - Nameservers to delegate via the Resolver outbound endpoint with delegate rule. For more information, see [NS record type](ResourceRecordTypes.md#NSFormat).

**VPCs that use this rule**  
The VPCs that use this rule to forward DNS queries for the specified domain name or names. You can apply a rule to as many VPCs as you want.

**Domain name – for forward rule only**  
DNS queries for this domain name are forwarded to the IP addresses that you specify in **Target IP addresses**. For example, you can specify a specific domain (example.com), a top-level domain (com), or a dot (.) to forward all DNS queries. For more information, see [How VPC Resolver determines whether the domain name in a query matches any rules](resolver-overview-forward-vpc-to-network-domain-name-matches.md).

**Outbound endpoint**  
VPC Resolver forwards DNS queries through the outbound endpoint that you specify here to the IP addresses that you specify in **Target IP addresses**.

**Target IP addresses**  
When a DNS query matches the name that you specify in **Domain name**, the outbound endpoint forwards the query to the IP addresses that you specify here. These are typically the IP addresses for DNS resolvers on your network.  
**Target IP addresses** is available only when the value of **Rule type** is **Forward**.  
Specify IPv4 or IPv6 addresses, the protocols, and ServerNameIndication you want to use for the endpoint. ServerNameIndication is applicable only when selected protocol is DoH.  
Resolving the target IP address of the FQDN of a DoH resolver on your network over the outbound endpoint is not supported. Outbound endpoints need the target IP address of DoH resolver on your network to forward the DoH queries to. If the DoH resolver on your network needs the FQDN in the TLS SNI and in the HTTP Host header, ServerNameIndication must be provided.

**ServerNameIndication**  
The Server Name Indication of the DoH server that you want to forward queries to. This is only used if the Protocol is DoH.

**Tags**  
Specify one or more keys and the corresponding values. For example, you might specify **Cost center** for **Key** and specify **456** for **Value**.  
These are the tags that AWS Billing and Cost Management provides for organizing your AWS bill. For more information about using tags for cost allocation, see [Using cost allocation tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) in the *AWS Billing User Guide*.

# Managing outbound endpoints
<a name="resolver-forwarding-outbound-queries-managing"></a>

To manage outbound endpoints, perform the applicable procedure.

**Topics**
+ [Viewing and editing outbound endpoints](#resolver-forwarding-outbound-queries-managing-viewing)
+ [Viewing the status for outbound endpoints](#resolver-forwarding-outbound-queries-managing-viewing-status)
+ [Deleting outbound endpoints](#resolver-forwarding-outbound-queries-managing-deleting)

## Viewing and editing outbound endpoints
<a name="resolver-forwarding-outbound-queries-managing-viewing"></a>

To view and edit settings for an outbound endpoint, perform the following procedure.<a name="resolver-forwarding-outbound-queries-managing-viewing-procedure"></a>

**To view and edit settings for an outbound endpoint**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, choose **Outbound endpoints**.

1. On the navigation bar, choose the Region where you created the outbound endpoint.

1. Choose the option for the endpoint that you want to view settings for or want to edit.

1. Choose **View details** or **Edit**.

   For information about the values for outbound endpoints, see [Values that you specify when you create or edit outbound endpoints](resolver-forwarding-outbound-queries-endpoint-values.md).

1. If you chose **Edit**, enter the applicable values, and then choose **Save**.

## Viewing the status for outbound endpoints
<a name="resolver-forwarding-outbound-queries-managing-viewing-status"></a>

To view the status for an outbound endpoint, perform the following procedure.<a name="resolver-forwarding-outbound-queries-managing-viewing-status-procedure"></a>

**To view the status for an outbound endpoint**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, choose **Outbound endpoints**.

1. On the navigation bar, choose the Region where you created the outbound endpoint. The **Status** column contains one of the following values:  
**Creating**  
VPC Resolver is creating and configuring one or more Amazon VPC network interfaces for this endpoint.  
**Operational**  
The Amazon VPC network interfaces for this endpoint are correctly configured and able to pass inbound or outbound DNS queries between your network and VPC Resolver.  
**Updating**  
VPC Resolver is associating or disassociating one or more network interfaces with this endpoint.  
**Auto recovering**  
VPC Resolver is trying to recover one or more of the network interfaces that are associated with this endpoint. During the recovery process, the endpoint functions with limited capacity because of the limit on the number of DNS queries per IP address (per network interface). For the current limit, see [Quotas on Route 53 VPC Resolver](DNSLimitations.md#limits-api-entities-resolver).  
**Action needed**  
This endpoint is unhealthy, and VPC Resolver can't automatically recover it. To resolve the problem, we recommend that you check each IP address that you associated with the endpoint. For each IP address that isn't available, add another IP address and then delete the IP address that isn't available. (An endpoint must always include at least two IP addresses.) A status of **Action needed** can have a variety of causes. Here are two common causes:  
   + One or more of the network interfaces that are associated with the endpoint were deleted using Amazon VPC.
   + The network interface couldn't be created for some reason that's outside the control of VPC Resolver.  
**Deleting**  
VPC Resolver is deleting this endpoint and the associated network interfaces.

## Deleting outbound endpoints
<a name="resolver-forwarding-outbound-queries-managing-deleting"></a>

Before you can delete an endpoint, you must first delete any rules that are associated to a VPC.

To delete an outbound endpoint, perform the following procedure.

**Important**  
If you delete an outbound endpoint, VPC Resolver stops forwarding DNS queries from your VPC to your network for rules that specify the deleted outbound endpoint.<a name="resolver-forwarding-outbound-queries-managing-deleting-procedure"></a>

**To delete an outbound endpoint**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, choose **Outbound endpoints**.

1. On the navigation bar, choose the Region where you created the outbound endpoint.

1. Choose the option for the endpoint that you want to delete.

1. Choose **Delete**.

1. To confirm that you want to delete the endpoint, enter the name of the endpoint, and then choose **Submit**.

# Managing forwarding rules
<a name="resolver-rules-managing"></a>

If you want VPC Resolver to forward queries for specified domain names to your network, you create one forwarding rule for each domain name and specify the name of the domain for which you want to forward queries.

**Topics**
+ [Viewing and editing forwarding rules](#resolver-rules-managing-viewing)
+ [Creating forwarding rules](#resolver-rules-managing-creating-rules)
+ [Adding rules for reverse lookup](#add-reverse-lookup)
+ [Associating forwarding rules with a VPC](#resolver-rules-managing-associating-rules)
+ [Disassociating forwarding rules from a VPC](#resolver-rules-managing-disassociating-rules)
+ [Sharing Resolver rules with other AWS accounts and using shared rules](#resolver-rules-managing-sharing)
+ [Deleting forwarding rules](#resolver-rules-managing-deleting)
+ [Forwarding rules for reverse DNS queries in VPC Resolver](#resolver-automatic-forwarding-rules-reverse-dns)

## Viewing and editing forwarding rules
<a name="resolver-rules-managing-viewing"></a>

To view and edit settings for a forwarding rule, perform the following procedure.<a name="resolver-rules-managing-viewing-procedure"></a>

**To view and edit settings for a forwarding rule**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, choose **Rules**.

1. On the navigation bar, choose the Region where you created the rule.

1. Choose the option for the rule that you want to view settings for or want to edit.

1. Choose **View details** or **Edit**.

   For information about the values for forwarding rules, see [Values that you specify when you create or edit rules](resolver-forwarding-outbound-queries-rule-values.md).

1. If you chose **Edit**, enter the applicable values, and then choose **Save**.

## Creating forwarding rules
<a name="resolver-rules-managing-creating-rules"></a>

To create one or more forwarding rules, perform the following procedure.<a name="resolver-rules-managing-creating-rules-procedure"></a>

**To create forwarding rules and associate the rules with one or more VPCs**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, choose **Rules**.

1. On the navigation bar, choose the Region where you want to create the rule.

1. Choose **Create rule**.

1. Enter the applicable values. For more information, see [Values that you specify when you create or edit rules](resolver-forwarding-outbound-queries-rule-values.md).

1. Choose **Save**.

1. To add another rule, repeat steps 4 through 6. 

## Adding rules for reverse lookup
<a name="add-reverse-lookup"></a>

If you need to control reverse lookups in your VPC, you can add rules to your outbound resolver endpoint.

**To create the reverse lookup rule**

1. Follow the steps in the previous procedure, up to step 5.

1. When you specify your rule, enter the PTR record for the IP address or addresses that you want a reverse lookup forwarding rule for.

   For example, if you need to forward lookups for addresses in the 10.0.0.0/23 range, enter two rules:
   + 0.0.10.in-addr.arpa
   + 1.0.10.in-addr.arpa

   Any IP address in those subnets will be referenced as a subdomain of those PTR records—for example, 10.0.1.161 will have a reverse lookup address of 161.1.0.10.in-addr.arpa, which is a subdomain of 1.0.10.in-addra.arpa.

1. Specify the server to forward these lookups to.

1. Add these rules to your outbound resolver endpoint.

Note that turning on `enableDNSHostNames` for your VPC automatically adds PTR records. See [What is Route 53 VPC Resolver?](resolver.md). The previous procedure is required only if you want to explicitly specify a resolver for given IP ranges—for example, when forwarding queries to an Active Directory server.

## Associating forwarding rules with a VPC
<a name="resolver-rules-managing-associating-rules"></a>

After you create a forwarding rule, you must associate the rule with one or more VPCs. The rules will only work after they are associated with a VPC. When you associate a rule with a VPC, VPC Resolver starts to forward DNS queries for the domain name that's specified in the rule to the DNS resolvers that you specified in the rule. The queries pass through the outbound endpoint that you specified when you created the rule.<a name="resolver-rules-managing-associating-procedure"></a>

**To associate a forwarding rule with one or more VPCs**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, choose **Rules**.

1. On the navigation bar, choose the Region where you created the rule.

1. Choose the name of the rule that you want to associate with one or more VPCs.

1. Choose **Associate VPC**.

1. Under **VPCs that use this rule**, choose the VPCs that you want to associate the rule with.

1. Choose **Add**.

## Disassociating forwarding rules from a VPC
<a name="resolver-rules-managing-disassociating-rules"></a>

You disassociate a forwarding rule from a VPC in the following circumstances:
+ For DNS queries that originate in this VPC, you want VPC Resolver to stop forwarding queries for the domain name specified in the rule to your network. 
+ You want to delete the forwarding rule. If a rule is currently associated with one or more VPCs, you must disassociate the rule from all VPCs before you can delete it.

If you want to disassociate a forwarding rule from one or more VPCs, perform the following procedure.<a name="resolver-rules-managing-disassociating-procedure"></a>

**To disassociate a forwarding rule from a VPC**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, choose **Rules**.

1. On the navigation bar, choose the Region where you created the rule.

1. Choose the name of the rule that you want to disassociate from one or more VPCs.

1. Choose the option for the VPC that you want to disassociate the rule from.

1. Choose **Disassociate**.

1. Type **disassociate** to confirm.

1. Choose **Submit**.

## Sharing Resolver rules with other AWS accounts and using shared rules
<a name="resolver-rules-managing-sharing"></a>

You can share the Resolver rules that you created using one AWS account with other AWS accounts. To share rules, the Route 53 VPC Resolver console integrates with AWS Resource Access Manager. For more information about Resource Access Manager, see the [Resource Access Manager User Guide](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html).

Note the following:

**Associating shared rules with VPCs**  
If another AWS account has shared one or more rules with your account, you can associate the rules with your VPCs the same way that you associate rules that you created with your VPCs. For more information, see [Associating forwarding rules with a VPC](#resolver-rules-managing-associating-rules).

**Deleting or unsharing a rule**  
If you share a rule with other accounts and then either delete the rule or stop sharing it, and if the rule was associated with one or more VPCs, Route 53 VPC Resolver starts to process DNS queries for those VPCs based on the remaining rules. The behavior is the same as if you disassociate the rule from the VPC.  
If a rule is shared to an Organizational Unit (OU) and an account in the OU is moved to a different OU, all associations with the shared rule to any VPC in the account will be deleted. However, if the VPC Resolver rule was already shared with destination OU, then the VPC association will stay intact and will not be dissociated.

**Maximum number of rules and associations**  
When an account creates a rule and shares it with one or more other accounts, the maximum number of rules per AWS Region applies to the account that created the rule.  
When an account that a rule is shared with associates the rule with one or more VPCs, the maximum number of associations between rules and VPCs per Region applies to the account that the rule is shared with.  
For current VPC Resolver quotas, see [Quotas on Route 53 VPC Resolver](DNSLimitations.md#limits-api-entities-resolver).

**Permissions**  
To share a rule with another AWS account, you must have permission to use the [PutResolverRulePolicy](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53resolver_PutResolverRulePolicy.html) action.

**Restrictions on the AWS account that a rule is shared with**  
The account that a rule is shared with can't change or delete the rule. 

**Tagging**  
Only the account that created a rule can add, delete, or see tags on the rule.

To view the current sharing status of a rule (including the account that shared the rule or the account that a rule is shared with), and to share rules with another account, perform the following procedure.<a name="resolver-rules-managing-sharing-procedure"></a>

**To view sharing status and share rules with another AWS account**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, choose **Rules**.

1. On the navigation bar, choose the Region where you created the rule.

   The **Sharing status** column shows the current sharing status of rules that were created by the current account or that are shared with the current account:
   + **Not shared**: The current AWS account created the rule, and the rule is not shared with any other accounts.
   + **Shared by me**: The current account created the rule and shared it with one or more accounts.
   + **Shared with me**: Another account created the rule and shared it with the current account.

1. Choose the name of the rule that you want to display sharing information for or that you want to share with another account.

   On the **Rule: *rule name*** page, the value under **Owner** displays ID of the account that created the rule. That's the current account unless the value of **Sharing status** is **Shared with me**. In that case, **Owner** is the account that created the rule and shared it with the current account.

1. Choose **Share** to view additional information or to share the rule with another account. A page in the Resource Access Manager console appears, depending on the value of **Sharing status**:
   + **Not shared**: The **Create resource share** page appears. For information about how to share the rule with another account, OU, or organization, skip to step 6.
   + **Shared by me**: The **Shared resources** page shows the rules and other resources that are owned by the current account and shared with other accounts.
   + **Shared with me**: The **Shared resources** page shows the rules and other resources that are owned by other accounts and shared with the current account.

1. To share a rule with another AWS account, OU, or organization, specify the following values.
**Note**  
You can't update sharing settings. If you want to change any of the following settings, you must reshare a rule with the new settings and then remove the old sharing settings.  
**Description**  
Enter a short description that helps you remember why you shared the rule.  
**Resources**  
Choose the check box for the rule that you want to share.  
**Principals**  
Enter the AWS account number, OU name, or organization name.  
**Tags**  
Specify one or more keys and the corresponding values. For example, you might specify **Cost center** for **Key** and specify **456** for **Value**.  
These are the tags that AWS Billing and Cost Management provides for organizing your AWS bill; you can use also tags for other purposes. For more information about using tags for cost allocation, see [Using cost allocation tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) in the *AWS Billing User Guide*.

## Deleting forwarding rules
<a name="resolver-rules-managing-deleting"></a>

To delete a forwarding rule, perform the following procedure.

Note the following:
+ If the forwarding rule is associated with any VPCs, you must disassociate the rule from the VPCs before you can delete the rule. For more information, see [Disassociating forwarding rules from a VPC](#resolver-rules-managing-disassociating-rules).
+ You can't delete the default **Internet Resolver** rule, which has a value of **Recursive** for **Type**. This rule causes Route 53 VPC Resolver to act as a recursive resolver for any domain names that you didn't create custom rules for and that VPC Resolver didn't create autodefined rules for. For more information about how rules are categorized, see [Using rules to control which queries are forwarded to your network](resolver-overview-forward-vpc-to-network-using-rules.md).<a name="resolver-rules-managing-deleting-procedure"></a>

**To delete a forwarding rule**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, choose **Rules**.

1. On the navigation bar, choose the Region where you created the rule.

1. Choose the option for the rule that you want to delete.

1. Choose **Delete**.

1. To confirm that you want to delete the rule, enter the name of the rule and choose **Submit**.

## Forwarding rules for reverse DNS queries in VPC Resolver
<a name="resolver-automatic-forwarding-rules-reverse-dns"></a>

When the `enableDnsHostnames` and `enableDnsSupport` are set to `true` for a virtual private cloud (VPC) from Amazon VPC, VPC Resolver automatically creates auto-defined system rules for reverse DNS queries. For more information about these settings, see [DNS attributes in your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support) in the *Amazon VPC Developer Guide*.

Forwarding rules for reverse DNS queries are particularly useful for services like SSH or Active Directory, which have an option to authenticate users by performing a reverse DNS lookup for the IP address from which a customer is attempting to connect to a resource. For more information about auto-defined system rules, see [Domain names that VPC Resolver creates autodefined system rules for](resolver-overview-forward-vpc-to-network-autodefined-rules.md). 

You can turn off these rules and modify all reverse DNS queries so that they are, for example, forwarded to your on-premises name servers for resolution.

After you turn off the automatic rules, create rules to forward the queries as needed to your on-premises resources. For more information about how to manage forwarding rules, see [Managing forwarding rules](#resolver-rules-managing).<a name="resolver-automatic-reverse-rules-disable-procedure"></a>

**To turn off auto-defined rules**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, under **VPC Resolver** choose **VPCs**, and then choose a VPC ID.

1. Under **Autodefined rules for reverse DNS resolution**, deselect the check box. If the check box is already deselected, you can select it to turn on auto-defined reverse DNS resolution.

For the related APIs, see [VPC Resolver configuration APIs](https://docs.aws.amazon.com/Route53/latest/APIReference/API-actions-by-function.html#actions-by-function-resolver-configuration).

# Resolver delegation rules tutorial
<a name="outbound-delegation-tutorial"></a>

 The delegation rule allows the VPC Resolver to reach the name servers that host the delegated zone through the specified outbound endpoint. While the forward rule informs the VPC Resolver to forward the DNS queries to the name servers that match the specified domain through outbound endpoint, the delegation rule informs VPC Resolver to reach the delegated name servers via the outbound endpoint specified when the delegated NS records are returned. VPC Resolver sends a query to the delegated name servers when the NS records in the DNS response match the domain name specified in the delegation record. 

## Steps to Use the Resolver endpoint outbound delegation
<a name="delegation-steps"></a>

1. Create a Resolver outbound endpoint in the VPC that you want DNS queries to originate from to the resolvers on your network. 

   You can use either the following API or the CLI command:
   + [`CreateResolverEndpoint` API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53resolver_CreateResolverEndpoint.html)
   + [`create-resolver-endpoint` CLI](https://docs.aws.amazon.com/cli/latest/reference/route53resolver/create-resolver-endpoint.html)

1. Create one or more delegation rules, which specify the domain names for which the queries should be delegated to your network through the specified outbound endpoint.

   Example delegation rule creation with CLI:

   ```
   aws route53resolver create-resolver-rule \
   --region REGION \
   --creator-request-id delegateruletest \
   --delegation-record example.com \
   --name delegateruletest \
   --rule-type DELEGATE \
   --resolver-endpoint-id outbound endpoint ID
   ```

1. Associate the delegation rule with the VPCs for which you want the queries to be delegated.

   You can use either the following API or the CLI command:
   + [AssociateResolverRule](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53resolver_AssociateResolverRule.html) API.
   + [associate-resolver-rules](https://docs.aws.amazon.com/cli/latest/reference/route53resolver/associate-resolver-rule.html) CLI command.

## Types of delegation supported by Resolver outbound endpoint
<a name="delegation-types"></a>

VPC Resolver supports two types of outbound delegation:
+ Route 53 private hosted zone to VPC Resolver outbound delegation:

   Delegates a sub-domain from a private hosted zone to either to on-premises DNS server or a public hosted zone on the internet using outbound delegation. This outbound delegation allows you to split management of your DNS records between the private hosted zone and the delegated zone. The delegation can be done with or without glue record in private hosted zone based on your DNS setup.For more information see [Private hosted zone to outbound](#phz-to-outbound-delegation). 
+ VPC Resolver outbound to outbound delegation:

   Delegates a subdomain from your on-premises DNS server to another on-premises server in a same or different location using outbound to outbound delegation. This is similar to delegating from a private hosted zone to an outbound endpoint, where you can delegate to zone hosted on your on-premises name server. For more information see [Outbound to outbound](#outbound-to-outbound-delegation). 

### Route 53 private hosted zone to VPC Resolver outbound delegation example configuration
<a name="phz-to-outbound-delegation"></a>

 Let's assume a DNS setup where the parent hosted zone is hosted in an Route 53 private hosted zone in an Amazon VPC and subdomains are being delegated to name servers hosted in Europe, Asia and North America. All the DNS queries are passed thorough the VPC Resolver. 

Follow the example steps to configure your private hosted zone and VPC Resolver.

**Configure private hosted zone for outbound delegation**

1. For the private hosted zone setup:

   Parent hosted zone: `hr.example.com`

   ```
   $TTL    86400 ; 24 hours
   $ORIGIN hr.example.com
   @  1D  IN     SOA @    root (20200322001 3H 15 1w 3h)
   @  1D  IN  NS @
   eu.hr.example.com IN NS ns1.eu.hr.example.com.
   apac.hr.example.com IN NS ns2.apac.hr.example.com.
   na.hr.example.com IN NS ns3.na.hr.example.net. # Out of Zone Delegation
   
   ns1.eu.hr.example.com IN A 10.0.0.30 # Glue Record
   ns2.apac.hr.example.com IN A 10.0.0.40 # Glue Record
   ```

1. For the on-premises name server in the Europe on-premises region:
   + Hosted Zone: `eu.hr.example.com` NS IP: `10.0.0.30`

   ```
   $TTL    86400 ; 24 hours
   $ORIGIN eu.hr.example.com
   @  1D  IN     SOA @    root (20200322001 3H 15 1w 3h)
   @  1D  IN  NS @
   
   test.eu.hr.example.com IN A 1.2.3.4
   ```

1. For the on-premises name server in the Asia on-premises region:

   Hosted Zone: `apac.hr.example.com`, `10.0.0.40`

   The apac name server can delegate the subdomain to other name servers.

   ```
   $TTL    86400 ; 24 hours
   $ORIGIN apac.hr.example.com
   @  1D  IN     SOA @    root (20200322001 3H 15 1w 3h)
   @  1D  IN  NS @
   
   test.apac.hr.example.com IN A 5.6.7.8
   engineering.apac.hr.example.com IN NS ns1.engineering.apac.hr.example.com
   sales.apac.hr.example.com IN NS ns2.sales.apac.hr.example.com
   ns1.engineering.apac.hr.example.com IN A 10.0.0.80
   ns2.sales.apac.hr.example.com IN A 10.0.0.90
   ```

   Hosted Zone: `engineering.apac.hr.example.com`, `10.0.0.80`

   ```
   $TTL 86400 ; 24 hours
   $ORIGIN engineering.apac.hr.example.com
   @ 1D IN SOA @ root (20200322001 3H 15 1w 3h)
   @ 1D IN NS @
   test.engineering.apac.hr.example.com IN A 1.1.1.1
   ```

1. For the on-premises name server in the North America on-premises region:

   Hosted Zone: `na.hr.example.net` NS IP: `10.0.0.50`

   ```
   $TTL    86400 ; 24 hours
   $ORIGIN na.hr.example.net
   @  1D  IN     SOA @    root (20200322001 3H 15 1w 3h)
   @  1D  IN  NS @
   ns3.na.hr.example.net. IN A 10.0.0.50
   test.na.hr.example.com  IN A 9.10.11.12
   ```

**VPC Resolver setup**
+ For the VPC Resolver you need to set up one forward rule and two delegation rules:

  **Forward rule**

  1. For forwarding the out-of-zone delegation record, so the Route 53 VPC Resolver knows the IP of the delegated NS to forward the initial request.

     domain-name: `hr.example.net` target-ips: `10.0.0.50`

  **Delegation rules**

  1. Delegation rule for in-zone delegation:

     delegation-record: `hr.example.com`

  1. Delegation rule for out-of zone delegation:

     delegation-record: `hr.example.net`

### Outbound to outbound delegation example configuration
<a name="outbound-to-outbound-delegation"></a>

 Instead of having the parent hosted zone in an Amazon VPC, let's assume a DNS setup where the parent hosted zone is in the central on-premises location and subdomains are being delegated to name servers hosted in Europe, Asia, and North America. All the DNS queries are passed thorough the VPC Resolver. 

Follow the example steps to configure your on-premises DNS and the VPC Resolver.

**Configure on-premise DNS**

1. For the on-premises name server in the central on-premises region:
   + **Parent hosted zone:** `hr.example.com`

     Hosted Zone `hr.example.com`, NS IP: `10.0.0.20`

   ```
   $TTL    86400 ; 24 hours
   $ORIGIN hr.example.com
   @  1D  IN     SOA @    root (20200322001 3H 15 1w 3h)
   @  1D  IN  NS @
   eu.hr.example.com IN NS ns1.eu.hr.example.com.
   apac.hr.example.com IN NS ns2.apac.hr.example.com.
   na.hr.example.com IN NS ns3.na.hr.example.net. # Out of zone delegation
   
   ns1.eu.hr.example.com IN A 10.0.0.30 # Glue record
   ns2.apac.hr.example.com IN A 10.0.0.40 # Glue record
   ```

1.  For the on-premises name server in the Europe on-premises region (the configuration for the Europe, Asia, and North America name servers is the same as for the private hosted zone to outbound delegation):
   + Hosted Zone: `eu.hr.example.com` NS IP: `10.0.0.30`

   ```
   $TTL    86400 ; 24 hours
   $ORIGIN eu.hr.example.com
   @  1D  IN     SOA @    root (20200322001 3H 15 1w 3h)
   @  1D  IN  NS @
   
   test.eu.hr.example.com IN A 1.2.3.4
   ```

1. For the on-premises name server in the Asia on-premises region:

   Hosted Zone: `apac.hr.example.com`, `10.0.0.40`

   The apac name server can delegate the subdomain to other name servers.

   ```
   $TTL    86400 ; 24 hours
   $ORIGIN apac.hr.example.com
   @  1D  IN     SOA @    root (20200322001 3H 15 1w 3h)
   @  1D  IN  NS @
   
   test.apac.hr.example.com IN A 5.6.7.8
   engineering.apac.hr.example.com IN NS ns1.engineering.apac.hr.example.com
   sales.apac.hr.example.com IN NS ns2.sales.apac.hr.example.com
   ns1.engineering.apac.hr.example.com IN A 10.0.0.80
   ns2.sales.apac.hr.example.com IN A 10.0.0.90
   ```

   Hosted Zone: `engineering.apac.hr.example.com`, `10.0.0.80`

   ```
   $TTL 86400 ; 24 hours
   $ORIGIN engineering.apac.hr.example.com
   @ 1D IN SOA @ root (20200322001 3H 15 1w 3h)
   @ 1D IN NS @
   test.engineering.apac.hr.example.com IN A 1.1.1.1
   ```

1. For the on-premises name server in the North America on-premises region:

   Hosted Zone: `na.hr.example.net` NS IP: `10.0.0.50`

   ```
   $TTL    86400 ; 24 hours
   $ORIGIN na.hr.example.net
   @  1D  IN     SOA @    root (20200322001 3H 15 1w 3h)
   @  1D  IN  NS @
   ns3.na.hr.example.net. IN A 10.0.0.50
   test.na.hr.example.com  IN A 9.10.11.12
   ```

**VPC Resolver setup**
+ For the VPC Resolver you need to set up forward rules and delegation rules:

  **Forward rules**

  1. For forwarding the initial request so the queries will be forwarded to the parent hosted zone `hr.example.com` in the central location:

     domain-name: `hr.example.com` target-ips: `10.0.0.20`

  1. For forwarding the out-of-zone delegation record, so the VPC Resolver knows the IP address of the delegated name server to forward the initial request:

     domain-name: `hr.example.net` target-ips: `10.0.0.50`

  **Delegation rules**

  1. Delegation rule for in-zone delegation:

     delegation record: `hr.example.com`

  1. Delegation Rule for out-of zone delegation:

     delegation-record: `hr.example.net`

# Enabling DNSSEC validation in Amazon Route 53
<a name="resolver-dnssec-validation"></a>

When you enable DNSSEC validation for a virtual private cloud (VPC) in Amazon Route 53, DNSSEC signatures are cryptographically checked to ensure that the response was not tampered with. You enable DNSSEC validation on your VPC detail page. 

DNSSEC validation is applied by VPC Resolver to public signed names when it is performing recursive DNS resolution. 

However, if the VPC Resolver is forwarding to another DNS resolver, that resolver is performing recursive DNS resolution and, therefore, must also apply the DNSSEC validation.

**Important**  
Enabling DNSSEC validation can impact DNS resolution for public DNS records from AWS resources in a VPC, which could result in an outage. Be aware that enabling or disabling DNSSEC validation can take several minutes. 

**Note**  
At this time, the Route 53 VPC Resolver in your VPC (aka AmazonProvidedDNS) ignores the DO (DNSSEC OK) EDNS header bit and the CD (Checking Disabled) bit in the DNS query. If you have configured DNSSEC, this means that while the VPC Resolver does perform DNSSEC validation, it doesn't return DNSSEC records nor set the AD bit in the response. Therefore, performing your own DNSSEC validation is not currently supported by the VPC Resolver. If you need to do this you will have to perform your own recursive DNS resolution.<a name="resolver-dnssec-validation-procedure"></a>

**To enable DNSSEC validation for a VPC**

1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. In the navigation pane, under **VPC Resolver**, choose **VPCs**.

1. Under **DNSSEC validation**, select the check box. If the check box is already selected, you can clear it to disable DNSSEC validation.

   Be aware that enabling or disabling DNSSEC validation can take several minutes.