Conditional DNS forwarding is a resolver policy that selects a destination DNS server according to the name being queried. For example, a resolver can forward queries for corp.example.com and its subdomains to corporate DNS servers while resolving public internet names normally. Where multiple forwarding rules match, resolvers generally select the most specific matching domain suffix. A rule for engineering.corp.example.com therefore takes precedence over a broader rule for corp.example.com.
The forwarding resolver does not become authoritative for the forwarded namespace and does not replicate its records. Instead, it asks a designated server to resolve matching queries and typically caches the responses according to their TTLs. This differs from DNS delegation, which uses authoritative DNS records to direct resolution toward servers responsible for a child zone. Conditional forwarding is configured on the resolver serving the client, rather than established through the authoritative DNS hierarchy.
In a hybrid deployment, cloud applications might need to resolve database.corp.example.com using an on-premises DNS server. The cloud resolver forwards matching queries through an outbound DNS path over a VPN or private connection. In the opposite direction, corporate DNS servers can conditionally forward a private cloud namespace, such as aws.example.com, to an inbound cloud resolver endpoint. These are separate query directions; configuring one does not automatically enable the other.
On AWS, Amazon Route 53 Resolver outbound endpoints and forwarding rules provide the cloud-to-corporate path. Associate the relevant rules with the VPCs whose workloads need them. For corporate-to-cloud resolution, configure corporate forwarders to use Route 53 Resolver inbound endpoint IP addresses. The private hosted zone must be associated with the VPC receiving inbound queries, or otherwise be available through supported DNS configuration. Do not target the VPC-provided resolver address directly from on premises; use supported inbound endpoints.
Across accounts, a shared networking account can host outbound endpoints and share forwarding rules through AWS Resource Access Manager. Participating accounts associate those rules with their VPCs. Resolver endpoints and forwarding rules are Regional resources, so a multi-Region design needs explicit regional deployment and association planning. VPC peering or a transit gateway supplies network connectivity, but neither automatically shares forwarding rules nor makes every private hosted zone visible to every connected VPC.
Successful forwarding requires more than a correct suffix. Routing, return paths, security groups, network ACLs, and DNS server access controls must permit the exchange. Standard DNS commonly uses UDP port 53, but TCP port 53 is also necessary for responses that require TCP, including fallback after truncation. Use redundant target servers and endpoint addresses across failure domains, and verify reachability from the actual forwarding endpoints. A private network path does not by itself encrypt DNS traffic.
Namespace overlap requires careful planning. A private zone can hide public records under the same domain, and a negative answer from the selected private namespace does not generally trigger a search of the public namespace. In Route 53 Resolver, an equally named forwarding rule takes precedence over a private hosted zone. Avoid forwarding loops in which corporate and cloud resolvers send the same namespace back to each other. Broad root-domain forwarding also needs caution because it can send unrelated queries across the hybrid link and make cloud resolution depend on corporate DNS availability.
Centralized forwarding reduces configuration duplication but adds endpoint cost, network dependency, and operational concentration. Distributed forwarding can improve regional independence at the expense of more infrastructure and policy management. Validate both directions with known records, check negative responses and TTL behavior, and use resolver query logs alongside network diagnostics. Finally, distinguish name resolution from application connectivity: receiving a private IP address does not establish a route, authorize access, or open the application's port.