View a markdown version of this page

Resolved IP validation log fields - AWS Network Firewall

Resolved IP validation log fields

When a firewall policy uses resolved IP validation, Network Firewall adds the following fields to the EVE flow and alert log events. For more information about the feature, see Resolved IP validation in AWS Network Firewall.

  • route53_resolved_ip – Whether the Amazon Route 53 Resolver resolved the connection's destination IP address for a domain. true means it was validated; false means it wasn't. This field doesn't appear for connections that validation skipped. Examples are sources outside the configured ranges and bypassed destinations. It appears in flow events (as flow.route53_resolved_ip) and at the top level of an alert event. In the flow log entry for the to-server direction, it appears inside the netflow object (as netflow.route53_resolved_ip).

  • route53_ttl_expiry_triggered – Appears and is set to true when the firewall validated the connection but a resolution later expired and the firewall applied the DNS expiry exception policy. Otherwise, the field is omitted. Appears in the same events as route53_resolved_ip.

  • route53_domain_validated – Present and set to true in an alert event when the alert is from a rule that uses the aws_route_53_resolved_domain keyword and the destination IP address was resolved for the matched domain. The rule can come from the AWS_ROUTE_53_RESOLVED_DOMAIN target type or from a Suricata rule.

  • route53_domain – The matched domain name, included in the alert event alongside route53_domain_validated.

Example flow log entry with resolved IP validation

The following listing shows a flow log entry for a connection whose destination IP address was not resolved through the Amazon Route 53 Resolver. The policy's action is ALERT, so Network Firewall tags the connection but doesn't block it:

{ "firewall_name": "test-firewall", "availability_zone": "us-east-1b", "event_timestamp": "1760000000", "event": { "timestamp": "2026-10-09T08:00:00.000000+0000", "flow_id": 1234567890123456, "event_type": "netflow", "src_ip": "10.0.100.55", "src_port": 49208, "dest_ip": "203.0.113.24", "dest_port": 443, "proto": "TCP", "app_proto": "tls", "netflow": { "pkts": 12, "bytes": 2318, "start": "2026-10-09T07:59:58.402136+0000", "end": "2026-10-09T08:00:00.000000+0000", "age": 2, "min_ttl": 63, "max_ttl": 63, "state": "closed", "reason": "timeout", "alerted": false, "route53_resolved_ip": false }, "tcp": { "tcp_flags": "1b", "syn": true, "fin": true, "psh": true, "ack": true } } }
Example alert log entry from a resolved-domain rule

The following listing shows an alert log entry generated by a domain list deny list that uses the AWS_ROUTE_53_RESOLVED_DOMAIN target type. The connection's destination IP address was resolved for malware.example.com, so the rule matched and dropped the connection:

{ "firewall_name": "test-firewall", "availability_zone": "us-east-1b", "event_timestamp": "1760000000", "event": { "timestamp": "2026-10-09T08:00:00.000000+0000", "flow_id": 1234567890123457, "event_type": "alert", "src_ip": "10.0.100.55", "src_port": 49210, "dest_ip": "203.0.113.40", "dest_port": 443, "proto": "TCP", "alert": { "action": "blocked", "signature_id": 2, "rev": 1, "signature": "matching resolved domain denylisted FQDNs", "category": "", "severity": 1 }, "verdict": { "action": "drop" }, "route53_resolved_ip": true, "route53_domain_validated": true, "route53_domain": "malware.example.com", "direction": "to_server", "aws_metadata": { "resource_arn": "arn:aws:network-firewall:us-east-1:111122223333:stateful-rulegroup/example-rule-group" } } }
Note

Network Firewall evaluates resolved IP validation once for each connection. The route53_resolved_ip value reflects the direction that was checked, which is the connection's originating (client-to-server) direction, and applies for the life of the connection. A false value doesn't indicate why validation didn't pass. To tell those cases apart, use the DnsUnresolvedFlows, DnsResolutionErrorFlows, and DnsAzUnavailableFlows metrics. For more information about troubleshooting resolved IP validation, see Monitoring and troubleshooting resolved IP validation.