A security engineer reports that all policy traffic through the FTD passes and connection events are being logged, but the firewall itself cannot resolve FQDN network objects, so those objects show as unresolved in access control entries. The DNS server sits on the outside network and the firewall sends its queries from its outside interface address. Which packet capture confirms whether the DNS replies reach the firewall's control path?
Select an answer to reveal the explanation.
Short Explanation
You need a control-path capture, because the traffic you're chasing is generated by the firewall itself rather than by a client. It's like listening at your own front door instead of the street's main line — filter on the firewall's address and UDP 53 and you'll see the replies land.
Full Explanation
Because the failing queries originate from the firewall itself, they travel the control path with the outside interface address as the source, so only a capture on that interface filtered on the device's own address and UDP port 53 isolates them from ordinary client traffic. Filtering a capture on the inside data interface shows the client queries that transit the device, which is a data-path view and never reveals whether a reply came back to the firewall. Capturing on the management interface assumes control traffic rides the management path, but an egress DNS lookup leaves through the data interface where the route points, so that capture returns nothing useful. Packet Tracer is a simulator rather than a capture tool, so it predicts which stage would reject a query but cannot show a real reply arriving on the wire. Exam caveat: control path means traffic to or from the device, rather than traffic passing through it. Practical check: start the filtered capture, wait for the next FQDN refresh, and look for a response sourced from the DNS server's address.