A fintech firm's threat feed names a domain used for command-and-control callbacks and a set of source ranges behind repeated scans. The engineer must stop DNS lookups for that domain at the DNS layer, drop traffic involving those ranges automatically, and avoid maintaining a separate address object for each range. Which DNS and Security Intelligence configuration meets all three requirements?
Select an answer to reveal the explanation.
Short Explanation
You're working two different sensors here, and neither one covers the other's territory. Your DNS policy reads the query name like a librarian checking a title before handing the book over. Reputation data then drops flagged addresses early.
Full Explanation
The DNS policy inspects the query itself at layer 7, so a rule there can act on the requested domain name and drop the lookup before an answer returns, which stops resolution of the callback domain. Security Intelligence runs earlier in the traffic processing order than access control rule matching, so enabling Cisco reputation lists drops connections involving the listed ranges with no network objects authored for them. Building an access control rule from address objects fails the no-maintenance requirement, because every new range must still be added by hand. Relying on Security Intelligence network lists alone fails the DNS-layer requirement, because blocking the domain’s resolved addresses only cuts later connections while the lookup itself still succeeds. URL filtering fails because a plain DNS query is not a URL; it applies to web requests over HTTP or HTTPS and keys on the server name rather than the DNS message. Exam caveat: a DNS policy only sees queries crossing the interfaces where it is applied, so a query aimed straight at an unmanaged resolver can bypass it. Practical check: add logging to the DNS rule and the intelligence lists, then watch events for the first blocked query.