Conditional forwarding is a DNS resolution policy based on the name being queried. For example, a resolver can send queries for corp.example.com and its descendants to corporate DNS servers while resolving unrelated names through its normal path. The destination server might answer authoritatively or perform further resolution. Forwarding does not transfer ownership of the namespace, replicate zone records, or change the application traffic path.
Rules normally match complete DNS labels and their descendants, not arbitrary text fragments. When multiple forwarding rules match, the most specific matching domain generally takes precedence. A rule for engineering.corp.example.com therefore takes priority over one for corp.example.com. Exact interactions between forwarding rules, locally authoritative zones, and default resolution policies depend on the resolver implementation and must be checked explicitly.
A typical hybrid design uses separate forwarding paths in each direction. Cloud workloads send queries for corp.example.com through a cloud resolver to on-premises DNS servers. Corporate DNS servers forward queries for aws.example.com to a cloud ingress resolver that can resolve the relevant private cloud zones. Neither direction automatically enables the other. Distinct namespace boundaries also help prevent loops in which both environments forward the same unresolved queries back to each other.
In AWS, workloads normally query the VPC-provided Route 53 Resolver. A forwarding rule associated with the workload VPC sends matching queries through a Route 53 Resolver outbound endpoint to specified DNS server IP addresses. For the reverse direction, an on-premises conditional forwarder targets the IP addresses of a Resolver inbound endpoint. That endpoint accepts queries into the resolver context of its VPC, where the required private hosted zones must be available. Do not target the VPC-provided resolver address directly from on-premises networks.
Resolver endpoints require network connectivity; they do not create it. AWS Direct Connect or a Site-to-Site VPN can provide the private path, but routes, security groups, network ACLs, and on-premises firewalls must also permit DNS traffic. For conventional DNS forwarding, support both UDP and TCP port 53: TCP is required for some responses and retries. Inbound endpoint security groups permit queries from approved clients, while outbound endpoint security groups permit queries to the target DNS servers. Deploy endpoint IP addresses across at least two Availability Zones and provide redundant upstream DNS servers.
Multi-account designs can centralize outbound endpoints and share forwarding rules through AWS Resource Access Manager. Each consuming VPC still needs the appropriate rule association; sharing a rule does not share private hosted zones or establish application connectivity. Resolver endpoints and rules are Regional resources, so multi-Region designs require deliberate regional deployment and associations. VPC peering or a transit network alone does not automatically expose every private DNS namespace.
Forwarding and delegation solve different problems. Delegation uses NS records in a parent zone to identify the authoritative servers for a child zone. Conditional forwarding is resolver configuration that selects an upstream destination. A private hosted zone stores authoritative records; a forwarding rule tells the resolver where to send queries. Route 53 alias records, traffic policies, and health checks influence answers or endpoint selection, not the conditional forwarding path.
Overlapping namespaces require particular care. In Route 53 Resolver, a forwarding rule takes precedence over a private hosted zone with the same domain name. When resolution selects a private hosted zone and the requested record is absent, Resolver does not fall back to the public version of that zone. Likewise, a negative response from an upstream server is not ordinarily a signal to try public DNS. Forwarding failures, authoritative negative responses, and cached negative responses are different troubleshooting cases.
The main trade-offs are added latency, endpoint and connectivity costs, and dependence on remote DNS availability. Caching reduces repeated queries but can delay visibility of record changes until TTLs expire. Configure reverse lookup forwarding separately when PTR resolution is required, using the appropriate in-addr.arpa or ip6.arpa namespace. Validate representative queries in both directions, inspect query logs and endpoint metrics, and test upstream-server and network-path failures rather than assuming multiple configured targets guarantee availability.