DNS security protects the integrity and availability of name resolution and helps control malicious use of DNS. Apply request and response policies, validate signed data, and investigate suspicious activity with Raven.
DNS security is the set of controls used to protect name resolution and reduce malicious use of DNS. It includes policies for unwanted destinations, validation of signed answers, restrictions on resolver access and workload, and investigation of suspicious query patterns.
A DNS firewall, DNSSEC, and encrypted DNS solve different problems. Filtering applies destination policy; DNSSEC checks signed data; DoT and DoH protect the transport. None of these alone covers every DNS threat.
Choose the right next step
Match the control to your requirement.
Start with the client traffic you need to protect and the failure you want to prevent. Raven applies its configured controls to queries using the managed resolver. Direct IP connections and clients using other DNS paths require complementary network and endpoint controls.
Evaluate DNS security solutions by coverage, deployment, policy, DNSSEC, investigation evidence, and failure handling. See where Raven fits your requirements.
Understand DNS firewall filtering with Raven DNS Guard: domain policies, RPZ threat feeds, request and response inspection, and explicit enforcement actions.
Explore Raven as a virtual DNS appliance: recursive resolution, DNS firewall policies, local DNSSEC validation, deployment boundaries, and operational visibility.
Compare DNS attack types: amplification, cache poisoning, tunneling, rebinding, query floods, and DGA activity, with their distinct controls and limits.
Learn how DNS amplification and reflection work, why open resolvers matter, and how Raven access controls, rate limits, and response controls reduce abuse.
Understand DNS poisoning, forged responses, and cache integrity. Explore Raven response binding, bailiwick checks, and optional local DNSSEC validation.
Explore DNS tunneling and data exfiltration signals: entropy, TXT rates, long names, and unique subdomains, with Raven anomaly controls and investigation context.
Know the threat. See the control.
Different attack paths. One DNS defense layer.
Explore eleven DNS threat scenarios and the Raven controls that help detect, restrict, or reject them.
Showing controls for Phishing.
THREAT EXPLORER11 SCENARIOS
Malicious destinations01 / 11
Phishing
THREAT SIGNAL
A requested domain matches a phishing indicator.
RAVEN / REQUEST INSPECTION
Apply domain policy before the lookup continues.
CONFIGURED RESPONSE
Enforce the matched policy
DNS Guard evaluates domain indicators, threat feeds, and RPZ sources. A matching rule can refuse, sinkhole, or return NXDOMAIN for the request.
Domain indicators
Threat feeds
RPZ policies
Coverage depends on the available indicators and the active policy.
Malicious destinations02 / 11
Malware Infrastructure Communication
THREAT SIGNAL
A domain or returned target matches known malware infrastructure.
RAVEN / REQUEST & ANSWER INSPECTION
Inspect the requested name and returned addresses.
CONFIGURED RESPONSE
Restrict matching destinations
Pre-resolution domain rules and post-resolution IP/CIDR indicators provide two opportunities to enforce policy on DNS lookups associated with malware infrastructure.
Pre/post inspection
IP & CIDR indicators
Policy actions
DNS controls apply to traffic using Raven; they are not endpoint malware removal.
Malicious destinations03 / 11
Botnet & Command-and-Control (C2) Communication
THREAT SIGNAL
Lookups target listed C2 domains or show unusual domain activity.
RAVEN / POLICY & ANOMALY CHECKS
Combine destination indicators with anomaly context.
CONFIGURED RESPONSE
Disrupt matching DNS paths
Domain policies, RPZ, threat feeds, and independently enabled anomaly detectors help identify and constrain DNS activity associated with botnet command infrastructure.
C2 indicators
RPZ sources
Anomaly context
Enforcement follows configured matches and thresholds; unknown C2 is not guaranteed to be identified.
Suspicious DNS behavior04 / 11
DNS Tunneling
THREAT SIGNAL
Unusual TXT activity, high entropy, or repeated unique subdomains.
RAVEN / BEHAVIOR INSPECTION
Evaluate behavior across bounded detection windows.
CONFIGURED RESPONSE
Detect and apply configured action
TXT-rate, entropy, and unique-subdomain detectors expose suspicious DNS patterns. Configured risk windows and recovery behavior govern anomaly enforcement.
TXT-rate detection
Entropy analysis
Unique subdomains
These are behavioral signals; legitimate services can show similar patterns.
Suspicious DNS behavior05 / 11
DNS-Based Data Exfiltration
THREAT SIGNAL
Long or encoded-looking names appear across many subdomains.
RAVEN / BEHAVIOR & INCIDENT ANALYSIS
Correlate abnormal query patterns with incident evidence.
CONFIGURED RESPONSE
Constrain suspicious query activity
Long-name, entropy, TXT, and unique-subdomain checks help surface possible data movement through DNS. Bounded incident samples support investigation and policy response.
Long-name checks
Entropy signals
Incident evidence
This is DNS behavior analysis, not inspection of the contents of every exfiltrated payload.
Suspicious DNS behavior06 / 11
Domain Generation Algorithm (DGA) Activity
THREAT SIGNAL
Generated-looking names combine with abnormal NXDOMAIN activity.
RAVEN / ANOMALY CHECKS
Assess entropy and query-rate signals.
CONFIGURED RESPONSE
Apply anomaly policy
Independently enabled DGA-like, entropy, NXDOMAIN-rate, and unique-subdomain detectors evaluate the query stream using configured thresholds.
DGA-like detection
NXDOMAIN rates
Risk windows
A DGA-like signal is an indicator for policy and investigation, not proof of a specific malware family.
Answer integrity07 / 11
DNS Rebinding
THREAT SIGNAL
An answer returns a target prohibited by the rebinding policy.
RAVEN / POST-RESOLUTION INSPECTION
Check returned addresses and name targets.
CONFIGURED RESPONSE
Enforce response policy
When post-resolution inspection is enabled, Raven checks A/AAAA addresses and CNAME/NS targets against indicators and the configured rebinding policy.
Rebinding policy
A / AAAA inspection
CNAME / NS checks
Protection depends on post-resolution inspection and the configured target restrictions.
Protocol & availability08 / 11
DNS Query Flooding & Resource Exhaustion
THREAT SIGNAL
Query rate or concurrent work exceeds configured capacity.
RAVEN / ADMISSION & RESOLUTION BUDGETS
Bound admission before expensive processing.
CONFIGURED RESPONSE
Limit excess work
Global, transport, and client admission controls combine with bounded resolver work, endpoint, hop, and depth budgets to constrain resource consumption.
Admission limits
Client concurrency
Resolver budgets
Resolver controls do not replace upstream protection against network-link saturation.
Protocol & availability09 / 11
DNS Amplification & Reflection
THREAT SIGNAL
Requests attempt to use the resolver as a response amplifier.
RAVEN / EXPOSURE & RESPONSE CONTROLS
Restrict access and bound DNS responses.
CONFIGURED RESPONSE
Reduce resolver abuse
Listener scope, firewall rules, and client ACLs reduce open-resolver exposure. DNS Cookies, Response Rate Limiting, minimal ANY answers, and UDP fitting constrain abuse.
Client ACLs
Response Rate Limiting
DNS Cookies · Minimal ANY
Deployment boundaries and source-address filtering remain important.
Answer integrity10 / 11
DNS Response Spoofing & Cache Poisoning
THREAT SIGNAL
A response fails request binding, referral checks, or signature validation.
RAVEN / RESPONSE & TRUST VALIDATION
Validate the answer before trusting its data.
CONFIGURED RESPONSE
Reject invalid DNS data
Strict response-to-question binding, bailiwick and glue checks, local DNSSEC when enabled, and generation-safe caching work together to protect answer integrity.
Response binding
Bailiwick & glue
Native DNSSEC
DNSSEC behavior remains CD-aware; unsigned data cannot be treated as cryptographically verified.
Protocol & availability11 / 11
Malformed DNS Queries
THREAT SIGNAL
A packet lacks a valid header or complete single question.
RAVEN / PROTOCOL PARSING
Validate message structure at the protocol boundary.
CONFIGURED RESPONSE
Reject malformed input
Raven requires one complete, valid question. Malformed-query handling produces an appropriate protocol error or drops packets that cannot safely receive a response.
Strict single-question parsing
Safe error handling
Early rejection
Drop versus error response depends on whether the packet can be safely answered.
Controls depend on enabled inspection, policy, indicators, and deployment. The scenarios illustrate behavior, not live incident data.
Complementary controls
Inspect. Validate. Control.
Each layer has a distinct role in the DNS request lifecycle.
01
Apply your policy
DNS Guard
Inspect requested domains before resolution and returned names and addresses before the answer reaches the client.
Domain rules, threat feeds, and RPZ sources
Returned IP and CIDR indicators
Policies by source, query type, and domain
Request and answer inspection can be enabled independently.
02
Validate the answer
Native DNSSEC
Validate DNS signatures locally, using the chain of trust rather than an upstream server’s AD flag.
DNSKEY, DS, and RRSIG chain validation
Authenticated denial of existence
Secure, Insecure, Bogus, and Indeterminate states
Validation runs when enabled and respects the client’s CD flag.
03
Bound the workload
Access & abuse controls
Control who can use the resolver and constrain work before expensive DNS processing takes place.
Explicit listener binding and client ACLs
Per-client rate and concurrency limits
Strict parsing and malformed-query handling
Exposure and limits follow the active configuration.
Enforcement
Make the outcome explicit.
DNS Guard can apply REFUSED, NXDOMAIN, validated sinkhole, or log-only actions according to the matched policy. A security signal and its configured response stay connected.
REFUSEDNXDOMAINSinkholeLog-only
Investigation
Understand the decision.
Review Guard events with client, domain, response-code, DNSSEC, and action context. Use bounded incident evidence and event exports to support investigation.
RAVEN