What does a DNS security platform do?
A resolver answers DNS questions. A DNS firewall applies policy to those questions and their answers. A broader platform connects resolution and enforcement with configuration, health monitoring, and investigation, so a security team can understand both what happened and which control produced the result.
Raven focuses on the recursive DNS path used by your clients. It is not an authoritative DNS hosting service or a substitute for endpoint protection. Clients must use the managed resolver for its query policies to apply; devices using other resolvers or direct IP connections need controls elsewhere in the network.
From DNS request to policy decision
Raven first checks the listener and client access boundary and limits admitted work. When request inspection is enabled, DNS Guard evaluates the queried name against configured policy and available domain, threat-feed, and RPZ indicators before cache or upstream resolution.
Accepted queries follow the configured resolver mode. Optional local DNSSEC validation checks signed data. Enabled answer inspection then evaluates returned addresses and targets, including IP/CIDR indicators and configured rebinding restrictions, before the answer reaches the client.
These are complementary controls. A DNSSEC signature does not establish that a destination is safe, and DNS filtering does not encrypt traffic. Upstream DoT and DoH protect the transport when configured; plaintext fallback is enabled by default and must be disabled where transport confidentiality is required.
Connect threat signals to explicit actions
DNS Guard supports REFUSED, NXDOMAIN, validated sinkhole, and log-only outcomes. The policy and active configuration determine enforcement. Request and answer inspection can be enabled independently; log-only records a signal without blocking the lookup.
Configurable anomaly detectors examine patterns such as high-entropy names, DGA-like activity, long labels, unusual TXT rates, NXDOMAIN rates, and unique subdomains. These signals help investigate possible tunneling or command-and-control activity. Legitimate services can produce similar patterns, so thresholds, observation windows, and exceptions require evaluation.
Give operators evidence they can act on
Review DNS Guard events alongside client, domain, response-code, DNSSEC, and action context. Incident evidence is bounded, and Live Query keeps recent requests in RAM rather than providing a permanent packet archive. Establish retention and external collection requirements before treating a view as a forensic record.
Raven supports event forwarding through Syslog and webhooks for integration with a wider investigation workflow. Delivery depends on the configured destination and network. Test the receiving system and correlate DNS evidence with endpoint and network observations instead of treating a DNS alert as a complete incident diagnosis.
Deploy with clear service boundaries
Raven separates the management plane from the DNS runtime. Configuration is validated and compiled before publication, and query processing uses prepared runtime snapshots rather than synchronous management API or configuration database calls for its main decisions.
Each appliance operates independently. Built-in clustering, configuration synchronization, and internal Anycast are not provided. Validate sizing, hypervisor compatibility, licensing, upstream availability, and recovery in your environment; a successful demonstration does not establish a production capacity guarantee.
What should a platform demonstration prove?
Bring a representative client, a controlled test domain, your intended resolver mode, and a legitimate business application. Ask to follow one allowed query, one policy match, and one failure from the client response to the supporting event. Define acceptance criteria before enabling enforcement broadly.
- Policy: show the matched rule and distinguish an enforced block from a log-only event.
- Trust: test signed, unsigned, and invalid DNS data with validation settings and the client CD flag recorded.
- Availability: exercise upstream failures and confirm the chosen fallback behavior.
- Operations: verify event delivery, investigation context, and the recovery procedure.