How to Create AWS Route53 Resolver Profile Entry-Point-Aware Rules

Select Language:

When using Cloud WAN Network Function Groups (NFG) with send-via inspection and Route53 Resolver Profiles for DNS security, there’s a common issue during multi-region failovers. Specifically, private DNS queries can’t be routed through inspection appliances (which are third-party security tools behind a Gateway Load Balancer) during a region switch. This happens because Route53 Resolver profiles evaluate the same way whether the DNS query comes from an inbound resolver endpoint or from a VPC’s default DNS server, with no way to tell the difference.

Here’s how this situation looks in a typical setup:

You have a multi-region Cloud WAN deployment spanning regions like us-east-1 and us-west-2. The setup includes landing zone (LZ) VPCs for production and development, inspection VPCs equipped with Gateway Load Balancers (GWLB) and security appliances, Route53 Resolver profiles set on both inspection and LZ VPCs, private hosted zones for cross-segment DNS, and a Lambda function ready to switch policies if inspection appliances fail.

Under normal operation, DNS queries from the landing zone VPC for internal domains like *.internal.example.com are handled smoothly. The process involves forwarding DNS requests to an app profile, which then sends them to an outbound resolver endpoint, passing through the route table to the GWLB. The appliances inspect the DNS query, and if it matches, it gets forwarded to the internal VPC for final resolution without issues.

During a failover, if the primary region’s appliances go down, the Lambda automatically updates the resolver targets to point to the remaining region’s inbound resolver IPs via VPC peering. Now, DNS queries from the landing zone go into the inspection VPC based on the new setup, but they never pass through the security appliances because the traffic doesn’t reach the GWLB — it enters directly through the inbound resolver. This means the appliances can’t inspect these queries, and they bypass the security layer entirely.

Trying to fix this isn’t straightforward, as no simple workaround exists. For example:

Removing the forward rule to appliances causes an infinite loop where DNS queries cycle endlessly between the appliances and the VPC, because the catch-all forwarding directs queries back into the inspection profile and the appliances keep inspecting and forwarding in a loop.
Forwarding appliance DNS directly to the shared inbound resolver avoids the loop but causes the appliances to never see the DNS queries in the first place.
Adding multiple rules with different targets for different entry points doesn’t work because Route53 Resolver evaluates the same rule regardless of where the query originates, lacking awareness of the source.

In essence, Route53 Resolver profiles are stateless and independent of the entry point they evaluate from. They don’t have the ability to differentiate whether a query came from the inbound resolver endpoint or a VPC after inspection. This creates a fundamental limitation: the system can’t apply different rules based on the query source.

The ideal solution would involve one of the following features:

Entry-point-aware profiles: Allow resolver rules to be aware of the source, enabling different rules for inbound and after-inspection queries.
Query tagging or inspection flags: Permit the inbound resolver to tag queries as “not inspected,” so the profiles can route them through GWLB accordingly, updating the tag once inspected.
Support for shared segment routes in NFG route tables: Enable propagation of shared routes into NFG route tables, so appliance-originated traffic can reach shared services VPCs, preventing loops.
Per-entry-point profile assignments: Allow assigning different resolver profiles depending on whether the query originates from the inbound resolver or VPC+2, tailoring the rule evaluation to the source.

Without these capabilities, DNS security inspection via GWLB and third-party appliances cannot be maintained during regional failovers. While public DNS queries and data plane traffic are still inspected, private DNS resolution bypasses the security layer entirely when a region fails, exposing a significant gap in security architecture that cannot be remedied through existing automation or configuration options.