Network Firewall can now check that a destination IP address is one your Route 53 Resolver actually returned, which extends domain filtering to protocols that carry no domain name. The thing to read before enabling it is which resolutions count as valid.
“This includes VPCs that are associated with the rule group but don't send traffic through this firewall. A destination IP address that any associated VPC resolved for a domain is considered resolved for all of them.”
Executive summary
The gap being closed is specific and old: “A standard domain rule matches on the host name that a client asserts —the TLS Server Name Indication (SNI) or the HTTP Host header.” A client controls both of those. So: “Resolved IP validation adds a check on the provenance of the destination IP address: whether your VPC's Amazon Route 53 Resolver returned this IP address when it resolved the domain.”
That closes one hole and opens one door.
“This closes the gap where a client sets Host: allowed.example.com but connects to an
unrelated IP address.” And:
“Because the check is based on the destination IP address rather than on an application-layer
header, it also extends domain-based rules to traffic that carries no domain name at
all.” That is where SFTP and SSH come in.
What decides whether a destination passes is not your firewall's configuration but a DNS Firewall rule group association, and the scope of that association is wider than most people will assume.
What changed
| Aspect | What AWS says |
|---|---|
| What is checked | “the provenance of the destination IP address” — whether your Resolver returned it |
| Why it matters | Standard domain rules match “the host name that a client asserts” |
| New reach | “traffic that carries no domain name at all”; the announcement names “SFTP and SSH” |
| Two levels | Policy level alone, or rule level on top — the rule level “requires the policy-level setting” |
| Enforcement | ALERT, DROP or REJECT, required |
| Validation scope | The VPCs associated with the referenced DNS Firewall rule group |
| Evaluation | “once for each connection, on the connection's first packet” |
| Cost | “at no additional charge”, all commercial Regions where both services are available |
Architecture
The validation scope is an association, not a traffic path
“The validation scope is the set of VPCs that are associated with the Amazon Route 53 Resolver DNS Firewall rule group that you reference in the policy.”
“Every VPC that is associated with it contributes its resolutions to a single shared pool, and the firewall validates against that whole pool.”
And the consequence, which AWS spells out rather than leaving to be discovered: “This includes VPCs that are associated with the rule group but don't send traffic through this firewall.”
So a VPC that has nothing to do with this firewall — attached to the same DNS Firewall rule group for DNS filtering reasons, by someone solving a different problem — contributes resolutions that this firewall will accept. The recommendation page states the risk in its own words: “Sharing a rule group across unrelated deployments therefore widens what each firewall accepts. Use a separate rule group for each firewall deployment.”
Worth noting what kind of object the rule group is. A DNS Firewall rule group is usually associated with VPCs to apply DNS filtering, and those associations are often managed centrally and by a different team from whoever owns a Network Firewall policy. This feature gives that association a second meaning.
Two ways legitimate traffic fails the check
Cross-zone traffic. “Resolutions are recorded for each Availability Zone, and validation is scoped to the zone”, and: “A connection can cross zones to reach a firewall endpoint. In that case, the firewall can't tell that the client is in a different zone. The connection fails validation as unresolved, and Network Firewall applies your Action setting to it.”
With Action set to DROP, that is legitimate traffic silently blocked for a routing
reason rather than a security one. The documented remedy:
“The exception is a firewall attached through a transit gateway, which carries the
client's zone with the traffic.”
A cold cache. Validation only knows destinations the Resolver has returned, so at the
moment you switch it on, resolutions clients are already using may not be recorded. Which is why AWS gives
a rollout instruction rather than leaving it to you:
“set Action to ALERT and keep it there for about 24 hours before you
switch to DROP or REJECT”, and
“switch to enforcement after the rate of unresolved flows settles”.
Evaluated once, for the life of the connection
“Network Firewall evaluates resolved IP validation once for each connection, on the connection's first packet… The result applies for the life of the connection, in the connection's originating (client-to-server) direction.”
That is a sensible design for a stateful firewall and it has one consequence worth holding: a long-lived connection carries whatever verdict it got at setup. A connection established while a resolution was valid is not re-checked when that resolution changes.
“DNS expiry exception policy (required) – The action to take when a recorded resolution has expired from the resolved IP cache but the firewall still sees traffic to that IP address. Valid values: CONTINUE | DROP | REJECT. CONTINUE treats the expired resolution as still valid.”
There is no default to fall back on — it is required, so you pick. And AWS removes one worry up front: “Resolved IP validation keeps a resolution in the resolved IP cache for longer than the DNS record's time to live (TTL), so a short TTL alone doesn't cause connections to fail.”
Business value
The old shape of egress domain filtering was that it worked where there was a header to read. HTTP and HTTPS have one; SFTP, SSH and most other protocols do not. Checking IP provenance instead of a header is what makes the rest of your outbound traffic filterable by domain at all, and the announcement names the cases: “protocols such as SFTP and SSH”.
The second gain is against the client's own assertion. A rule that matches “the host name that a client asserts” trusts the client. Tying the decision to what your Resolver returned moves the source of truth from the connection to your own DNS infrastructure, which is the right place for it.
Security considerations
The shared pool is the thing to get right. Everything else in this feature tightens control; the rule group association can loosen it, and the loosening is not determined by the firewall's own configuration. The policy names the rule group by ID — “DNS Firewall rule group ID (required)” — while the VPC associations that define the scope live on the Route 53 Resolver side, managed separately.
Scope the source side too. “Source IP ranges (optional) – The client source IP address ranges whose connections are validated. Specify up to 100 IPv4 or IPv6 addresses or CIDR ranges. If you don't specify any ranges, validation applies to the firewall's VPC CIDR ranges.” The default is the firewall's own VPC, which is a reasonable default and worth knowing is a default rather than everything.
ALERT needs logging on to mean anything.
“ALERT tags the matching connection in the firewall's flow logs without blocking it,
and requires that you enable logging.” An alert-mode rollout with logging off
is a rollout that tells you nothing.
Cost considerations
“at no additional charge” for the validation itself. The costs that appear are the ones the rollout requires: flow logging enabled during the alert window, and Route 53 Resolver DNS Firewall in place, since the feature references one of its rule groups.
Operational considerations
Changing the rule group is not instant.
“Changing this value swaps the DNS Firewall rule group association and is processed
asynchronously. While a swap is in progress, further changes to resolved IP validation are
rejected until the policy returns to the ACTIVE state.” So correcting a
mis-scoped rule group is a single operation you then wait on, which matters if you are doing it under
pressure.
REJECT does not apply uniformly.
“REJECT blocks the connection and sends a TCP reset to the client. Reject
applies to TCP. Network Firewall drops non-TCP traffic.” So for UDP the behaviour is a
silent drop whatever you chose, and a client sees a timeout rather than a reset.
Zone alignment becomes a security control. Routing that crosses zones produces failed validations, so the question "is our routing zone-aligned" stops being purely about latency and cost.
Tradeoffs
| What you gain | What it costs |
|---|---|
| Domain filtering for protocols with no domain in them | A dependency on clients using the VPC Resolver |
| A check that does not rest on what the client asserts | Validation scope set by a rule group association, not by traffic |
| Policy level usable on its own | Rule-level domain matching requires the policy setting first |
| Per-zone recording, which keeps the data local | Cross-zone connections fail as unresolved |
| One decision per connection, cheap at scale | A long-lived connection keeps its original verdict |
Implementation guidance
- Use a dedicated DNS Firewall rule group for this firewall. AWS says it plainly: “Use a separate rule group for each firewall deployment.”
- List the VPCs currently associated with the rule group you plan to reference. That list, not your traffic pattern, is what the firewall will accept.
- Check zone alignment before enabling enforcement, or use a transit gateway attachment for centralized inspection.
- Enable flow logging, then set
ALERTand leave it for about 24 hours. - Watch the unresolved-flow rate and switch to
DROPorREJECTonly once it settles. - Choose the DNS expiry exception policy deliberately — it is required, and
CONTINUEtrades strictness for availability. - Set source IP ranges if the firewall's own VPC CIDRs are not the scope you want.
Best practices
- Treat the rule group association as part of your firewall policy, because it is, and review it when either side changes.
- Do not run the alert window with logging off. AWS requires logging for
ALERTto record anything. - Prefer the policy level first, since it works alone and the rule level cannot be used without it.
- Expect UDP to be dropped rather than rejected, regardless of the Action you chose.
- Re-test long-lived connections after changing anything, since each one was decided on its first packet.
Who should adopt this and when
Soon, if you egress SSH or SFTP and have wanted domain rules for it. That is the case the feature exists for and there is no charge for the validation.
Soon also, if you already rely on SNI or Host matching — because that is the control this closes a documented gap in, where a client asserts an allowed name and connects elsewhere.
Carefully, if your DNS Firewall rule groups are shared or centrally managed. The scope question has to be answered before enforcement, and the answer lives outside your firewall.
With a transit gateway, if your inspection is centralized across zones — otherwise cross-zone connections will fail validation.
Key takeaways
- The check is on “the provenance of the destination IP address” rather than a header the client controls.
- It reaches “traffic that carries no domain name at all”, which is how SFTP and SSH become filterable by domain.
- Validation scope is the VPCs associated with the referenced DNS Firewall rule group, including ones that “don't send traffic through this firewall”.
- AWS's own warning: “Sharing a rule group across unrelated deployments therefore widens what each firewall accepts.”
- A cross-zone connection “fails validation as unresolved” unless the firewall is attached through a transit gateway.
- Start in
ALERTfor “about 24 hours” with logging enabled, because validation only knows what the Resolver has already returned. - Evaluated “once for each connection, on the connection's first packet”, and the verdict lasts the connection's life.
Official AWS references
- AWS Network Firewall now supports Route 53 Resolved IP Validation — the extension beyond HTTP/HTTPS to protocols such as SFTP and SSH, the provenance check against the VPC Resolver, and Region and cost availability
- Resolved IP validation in AWS Network Firewall — what a standard domain rule matches on, the provenance check it adds, the Host-header gap it closes, the extension to traffic carrying no domain name, and the policy and rule levels
- How resolved IP validation works — the validation scope as the rule group's associated VPCs, the single shared pool including VPCs that send no traffic through the firewall, once-per-connection evaluation on the first packet, per-Availability-Zone recording, the cross-zone failure as unresolved, and the transit gateway exception
- Configuring resolved IP validation on the firewall policy — the Action values and what each does, the logging requirement for ALERT, the TCP-only scope of REJECT, the required DNS expiry exception policy, the cache outliving the DNS TTL, the 100-range source scope and its default, and the asynchronous rule group swap
- Recommendations for configuring resolved IP validation — the 24-hour ALERT window and its reason, the instruction to use a separate rule group per firewall deployment, and the zone-alignment and transit gateway guidance
- Matching specific domains with resolved-domain rules — further reading on the rule level; no claims in this post are drawn from it
Comments