A school district with 30 sites allows local DIA for students but suffers malware from malicious domains. It wants DNS requests filtered before resolution without deploying branch appliances, using SD-WAN policy to redirect queries. Which DNS security integration should the engineer configure to block malicious domains centrally?
Select an answer to reveal the explanation.
Short Explanation
You need a librarian who checks every book request against a banned list. Cloud-DNS-filtering redirects lookups for instant blocking with no boxes.
Full Explanation
The correct design uses SD-WAN DNS security policy to steer branch queries to a cloud resolver that applies reputation and categorization before returning an IP, blocking malicious domains centrally while preserving local DIA with no branch appliance. The headquarters-redirect approach fails architecturally by backhauling DNS to on-premises servers, which centralizes logs but sacrifices DIA locality, cloud elasticity, and performance for 30 sites. The locally-resolve-then-filter-on-response approach fails temporally by permitting malicious resolution and relying on later URL or HTTP inspection, allowing direct-to-IP and non-web callbacks in violation of the before-resolution mandate. The edge-local filtering without central redirection approach fails operationally by distributing enforcement across WAN Edges, fragmenting policy and visibility instead of using mandated centralized redirect. Exam caveat is to distinguish DNS-layer pre-resolution blocking from URL-layer post-resolution filtering and cloud redirect from headquarters forwarding or local caching based on precise stem keywords. Practical check is to stage the policy on a pilot template, dig a vendor test malicious domain, and verify central cloud block logs with preserved DIA throughput for benign student queries.