DNS poisoning versus response spoofing
Response spoofing concerns the acceptance of a forged answer. Cache poisoning concerns the retained state: bad information can affect more than the original lookup while it remains reusable. A wrong address may divert clients away from the intended service, so cache integrity is part of DNS security as well as resolver correctness.
Checking only that a packet looks like DNS is insufficient. Resolvers must associate responses with outstanding questions and carefully handle referrals and additional address records. RFC 5452 describes safeguards against forged answers; cryptographic validation adds a separate basis for trusting signed DNS data.
Raven checks responses and referrals
Raven requires strict response-to-question binding. During iterative resolution, it checks referral progression and bailiwick: attached name-server addresses are trusted only within the relevant scope. Out-of-bailiwick name-server addresses are resolved independently rather than used directly as a trusted destination.
Its cache matches request identity and the active generation, respects expiry, and does not serve stale answers after a lookup failure. These rules support consistent cache behavior, but cache freshness alone is not proof that a DNS answer is authentic.
What DNSSEC validation adds
When enabled, Raven validates DNSKEY, DS, RRSIG, and authenticated denial evidence locally. It does not trust an upstream resolver’s AD flag as proof. A valid chain for signed data can establish authenticity and integrity; unsigned data cannot receive the same cryptographic assurance.
Client flags change the response. With CD=0, a Bogus result returns SERVFAIL, with additional error information when possible. With CD=1 (Checking Disabled), unchecked data may be returned with AD=0. An Insecure result means there is no complete signed chain, not that the domain has been classified as malicious.
Keep authenticity, privacy, and policy distinct
DNSSEC does not encrypt DNS traffic or decide whether a correctly signed domain is safe to visit. DNS over TLS and DNS over HTTPS protect a transport connection. DNS firewall policy evaluates destinations. These controls answer different questions and should be evaluated separately.
Investigate failed lookups using the DNSSEC result, response code, client flags, and upstream conditions. A SERVFAIL can reflect a resolution problem or validation failure. Temporary Negative Trust Anchors in Raven require an exact non-root domain, a reason, and an expiry; they are exceptions to trust validation, not a general repair for poisoning.