Attacks on DNS answer integrity
DNS response spoofing attempts to make a resolver accept forged data. Cache poisoning extends the impact when incorrect data is stored and reused for subsequent requests. Response binding, referral checks, and DNSSEC validation of signed data address different parts of this trust problem.
DNS rebinding presents a different concern: an answer can direct a client toward a destination prohibited by policy. In Raven, enabled post-resolution inspection evaluates returned addresses and targets using indicators and the configured rebinding restrictions. A valid DNS signature alone does not make a destination acceptable.
Attacks on DNS availability
DNS amplification and reflection abuse DNS servers to send responses toward a victim, often using a forged source address. A query flood instead aims to consume DNS processing capacity. Both can affect availability, but limiting request work and reducing reflected responses are distinct controls.
Raven combines listener scope and client ACLs with admission limits, response controls, and bounded resolver work. These controls help constrain abuse at the resolver. They do not guarantee availability when an upstream network link is saturated; that condition requires protection in the surrounding network.
DNS tunneling, exfiltration, and C2
DNS tunneling carries information through DNS messages. It can support command-and-control (C2) communication or DNS-based data exfiltration. High-entropy names, unusually long labels, changing subdomains, and unusual TXT activity can provide investigation signals, but legitimate applications can generate similar traffic.
DGA activity uses algorithmically generated domains and may appear alongside abnormal NXDOMAIN activity. Raven has independently enabled anomaly detectors for DGA-like patterns, entropy, TXT rates, NXDOMAIN rates, long names, and unique subdomains. Their configured thresholds and observation windows matter when interpreting a result.
Investigate signals in context
Start with the affected client and the symptom: wrong answers, failed lookups, excess workload, or suspicious domain activity. Review response codes, DNSSEC status, matched policy, and the action taken. A SERVFAIL result by itself is not proof of an attack; upstream failure and validation failure can also produce it.
Raven Guard events and bounded incident evidence help relate signals to policy decisions. Correlate them with endpoint and network evidence before attributing activity to a threat. Domain filtering, trust validation, access restrictions, and anomaly analysis each cover a different part of the DNS attack surface.
What should you check when you suspect a DNS attack?
First separate a security signal from a service fault. Identify which clients and domains are affected, compare response codes with the normal baseline, and check upstream reachability. A rise in NXDOMAIN can reflect application mistakes as well as suspicious domain generation; a DNSSEC failure may reflect a signing problem rather than an attack.
Next identify the control that acted. A policy refusal, a workload limit, and a failed signature check have different remediation paths. Preserve relevant events and configuration context, then correlate with network and endpoint evidence before expanding blocks or changing trust settings.
- Wrong or unexpected answers: examine resolver choice, answer sources, DNSSEC state, and response policy.
- Slow or failed resolution: review load, admission limits, upstream failures, and network capacity.
- Repeated unusual names: review the client, detector window, domain samples, and legitimate application behavior.
- Unexpected outbound communication: confirm whether the connection used the controlled resolver and investigate the endpoint.