What does a DNS firewall inspect?
A DNS lookup connects a name to the information a client needs to reach a service. Policy at this point can refuse a lookup for a known malicious domain or inspect the addresses returned by a lookup. This is useful for protective DNS, including restricting DNS access to known phishing, malware, and command-and-control infrastructure.
The inspection scope matters. A network firewall controls traffic between network endpoints; DNS filtering evaluates names and DNS answers. DNS policy does not inspect every application payload or remove malware from a device. Its coverage depends on clients using the controlled DNS path.
How Raven DNS Guard applies policy
Before resolution, enabled request inspection checks the requested domain using policy, domain indicators, threat feeds, and Response Policy Zone (RPZ) sources. Policies can distinguish clients, source ranges, query types, domain matches, and priority. RPZ supplies DNS response policy data; it is one policy source rather than a separate guarantee of threat coverage.
After resolution, enabled answer inspection checks A and AAAA addresses, IP/CIDR indicators, CNAME and NS targets, and configured rebinding restrictions. Request and answer inspection have independent switches. Disabling either removes that stage of policy enforcement.
Choose an explicit response
Raven validates and compiles policy before activation, including checks for conflicting outcomes. The matched rule and active configuration determine the response. A log-only rule records evidence without blocking the lookup.
- REFUSED: reject the DNS request according to policy.
- NXDOMAIN: return a name-not-found policy response.
- Sinkhole: use a configured destination after its prerequisites have been validated.
- Log-only: retain the security signal for investigation without enforcing a block.
Evaluate coverage and false positives
Review which clients use the resolver, which inspection stages are enabled, and which indicators feed the policy. Use legitimate business domains alongside known test indicators when evaluating a change. Monitor Guard events to connect the client, domain, action, and policy context before expanding enforcement.
A signed DNS answer can still point to an unwanted destination. DNSSEC validates authenticity of signed data; the DNS firewall applies destination policy. Unknown malicious infrastructure may not match available indicators, so filtering, anomaly investigation, and endpoint response remain complementary activities.
How do you test a DNS firewall policy?
Use an approved test domain and a client that sends queries through Raven. Confirm that the configured rule matches, observe the returned DNS response, and find the associated event. Repeat with a legitimate domain that should remain available. This checks enforcement and avoids mistaking an unrelated lookup failure for a successful block.
Record the enabled inspection stages and selected action with the result. A log-only match is evidence of detection, not prevention. A cached application connection may also continue after a DNS policy changes; test a fresh lookup rather than assuming that a policy terminates existing network sessions.
DNS firewall, DNSSEC, or a network firewall?
A DNS firewall applies policy to names and DNS answers. DNSSEC checks the authenticity of signed DNS data. A network firewall governs network traffic. They address different questions and can be used together: whether a destination is permitted, whether signed data can be trusted, and whether a connection is allowed.
A DNS firewall can help restrict access to known phishing or malware infrastructure when its indicators and active policy match. It does not inspect every URL path, clean an infected endpoint, or guarantee detection of a previously unknown malicious domain.