DNS-Resolved IP Validation: Testing Whether Your Egress Allowlist Actually Holds

TL;DR

AWS Network Firewall can now check every new outbound connection's destination IP against the addresses Route 53 Resolver actually returned, instead of trusting the domain name the client put in the request. That closes a gap most domain allowlists never covered: the client chooses the name, so the name is a claim, not evidence. The test is two-sided — the same destination IP, once with a resolver answer behind it and once without — read back from flow logs. If a connection succeeds when the policy says it should not, you have a finding rather than a configuration opinion.

What this is

Route 53 Resolved IP Validation is a Network Firewall policy setting plus a rule type that consumes DNS answers.

Amazon Route 53 Resolver answers DNS queries for resources in your VPC. With this feature, the addresses it returns are held in a resolved IP cache. On the first packet of each new outbound connection — before your stateful rules run — Network Firewall checks whether the destination address came from that cache. If it did, the connection continues to your rules. If it did not, Network Firewall applies the action you chose: Alert, Drop, or Reject.

Resolved-domain rules in your stateful rule groups then match a connection by the domain name its destination address was resolved for. They work with every protocol, not just HTTP and HTTPS, and they use the name your clients looked up.

The practitioner definition: this converts a domain allowlist from a statement about what the client claims into a statement about what your resolver answered. Those are different claims, and only the second one is enforceable.

Why it matters

Two groups are affected. Red teams and pentesters need to know whether an egress restriction they are told exists is real before they spend a week building around it. Cloud network defenders need to know whether the control they documented as a compensating control survives a client that lies.

Three things fail without it:

• SNI and Host-header spoofing. For HTTP and HTTPS, domain rules match the name in the request, and the client picks that name. An allowlist entry for a partner domain matches any connection that claims the name, pointed at any address.
• Non-web protocols. SSH, SFTP, MySQL and similar connections carry no hostname in the traffic. The client uses the name only for the lookup, then connects straight to the returned address — so rules for those protocols are usually written against IP addresses that change without warning.
• The assumption that the policy setting alone is an allowlist. It is not. It only requires that some client in scope resolved that destination at some point, in the same Availability Zone. Without resolved-domain rules you have a much weaker gate than most people reading a policy document assume.

If you ignore it, your egress findings are unfalsifiable. "Domain allowlist enforced" is a claim; a flow log record is evidence.

How it works

Three parts define the behaviour, and all three are documented in the AWS launch post:

1. A Route 53 Resolver DNS Firewall rule group defines scope. Answers returned in every VPC associated with that rule group go into the resolved IP cache. The group can be empty, in which case it only populates the cache and filters nothing.
2. The Network Firewall policy setting performs the per-connection check and decides Alert, Drop, or Reject. Reject refuses the connection actively, so a blocked client fails fast instead of waiting for a timeout.
3. Resolved-domain rules match connections by the looked-up name, which is what actually lets you write an allowlist that covers SFTP, SSH and database traffic.

Four behaviours decide whether your test is valid:

• The cache is shared, per address, per Availability Zone. When any client in an associated VPC looks up a name, that address passes the check for every client in scope in the same AZ. The resolver does not record who asked.
• Clients cache DNS answers. Enable alert mode first: a client that resolved a name before the rule group was associated will not have that answer in the cache.
• Hardcoded addresses fail the check. If a workload connects straight to an IP with no lookup, the connection fails validation. Bypass destination validation IP ranges exempt those addresses; a stateful pass rule does not, because validation runs before your rules.
• Cross-AZ routing breaks it. In distributed or Transit Gateway deployments, a client routed to a firewall endpoint in another Availability Zone fails the check even when the lookup was legitimate.

The validation approach follows directly: build a control connection and a test connection that differ in exactly one variable — whether a resolver answer exists for the destination — and compare what the firewall did with each.

Detection and response

The telemetry is specific. Connections blocked by the validation check appear in your flow logs with route53_resolved_ip set to false — not in your alert logs. That single field separates "the control fired" from "the control never saw the packet."

What a defender checks:

• Which destinations fail validation legitimately. A workload talking to a fixed IP with no DNS lookup will fail forever. Enumerate those before enforcing and put only those addresses in the bypass ranges.
• Whether resolved-domain rules exist at all. A policy in Drop mode with no resolved-domain rules drops unresolved destinations but permits every address that any in-scope client happened to look up.
• Whether the firewall endpoint is in the path for every subnet. A subnet whose route table bypasses the endpoint produces no validation decision, no flow log record and no alert. Confirm with VPC flow logs and route table review, not with the console summary of the policy.
• Cross-AZ failures after enforcement, which look like an outage rather than a security event.
• Bypass range breadth. An entry wider than the handful of hardcoded addresses it was meant to cover silently exempts everything inside it.

What to do

1. Map the path first. Identify which subnets route through the firewall endpoint and which do not. A test from an unrouted subnet proves nothing about the rule.
2. Establish a control connection. From an in-scope workload, resolve an allowlisted name and connect to the returned address. Confirm a flow log record exists with route53_resolved_ip true. Without that control, a later failure is ambiguous.
3. Test name spoofing. Resolve a destination you do not control, then connect to that same IP with the SNI of an allowlisted domain — for example openssl s_client -connect 203.0.113.10:443 -servername files.partner.example.com. Before this change it commonly passes, because the rule matched the claim. With resolved-domain rules in place it should not match, because the address was cached under the other name.
4. Test the shared cache. From workload A in one subnet, look up a name you control that returns an address of your choosing. Then from workload B in a different subnet, same AZ and same rule group, connect to that address directly. If B's connection passes, the control is "someone in this AZ resolved it," not "this workload is allowed to reach it." That is the finding.
5. Inspect the bypass ranges. Pull the policy with aws network-firewall describe-firewall-policy and check the bypass destination validation IP ranges against the set of genuinely hardcoded destinations.
6. Test DNS paths that skip the resolver. A workload using DNS over HTTPS, or a hardcoded external resolver, never populates the cache. In alert mode this shows up as a validation failure; in enforce mode it becomes an outage if the answer was legitimately needed.
7. Confirm the setting and the rules together. A resolved-domain rule without the policy setting enabled will not behave the way the name suggests.
8. Attach the evidence. Two flow log records and the policy JSON, or two commands and their transcripts. A finding that names the connection, the intended decision, the observed decision and the log line is one a second person can reproduce.

Where this fits in a program

A scanner hit is not proof. A finding needs evidence a second person can check: what the connection reached and which log line shows it. Trusteed is an AI workspace for security research built around that order — attack surface and traffic context to define what is worth testing, investigation workers to check a hypothesis, and validation that separates an exploitable result from noise. The two-sided test above is still yours to run.

FAQ

Does this replace TLS inspection? No. It removes the need for TLS inspection to catch SNI manipulation on outbound connections, but you still lose payload visibility inside TLS.

Why does my workload that connects to a fixed IP break? Because the destination was never resolved through Route 53 Resolver, so it is not in the cache. Add only those addresses to the bypass destination validation IP ranges.

Is the resolved IP cache per workload? No. The check is per address, and an answer returned to any client in scope passes for every client in the same Availability Zone. That is the behaviour most worth testing.

Does alert mode change traffic? No. It records the decision. It is the right first step because clients cache DNS answers, so enforcing immediately after association produces failures that are timing artifacts rather than policy decisions.

Where do blocked connections show up? In flow logs, with route53_resolved_ip as false — not in alert logs. If you look for validation drops in the alert log, you will conclude the control is quiet when it is actually working.

Sources

• Introducing Route 53 Resolved IP Validation for AWS Network Firewall — AWS Security Blog
• What is AWS Network Firewall? — AWS Network Firewall Developer Guide
• Route 53 Resolver DNS Firewall — Amazon Route 53 Developer Guide
• Trusteed