DNS cache poisoning occurs when a resolver stores incorrect DNS information and reuses it for later queries. The authoritative zone may remain correct, so investigating only the domain owner’s control panel can miss the affected layer.
What it is
Recursive resolvers cache answers to reduce repeated lookups and improve response time. Cache poisoning concerns incorrect information entering that cache and being reused as though it were a valid response. The affected scope can include many clients that rely on the same resolver.
This differs from an authorized but malicious change to the authoritative zone. In a poisoning scenario, the authoritative server may continue to publish the intended data. It also differs from ordinary stale caching, where an earlier legitimate answer remains valid in a cache for its expected lifetime.
How it works
A resolver must associate a received response with the query it issued and decide which information is acceptable to cache. Protocol and implementation safeguards reduce the chance that unrelated or forged responses are accepted. Modern resolver behavior, network protections and DNSSEC validation all influence the conditions under which poisoning is possible.
Transaction matching and trust boundaries
DNS implementations use details of a query and response to determine whether they belong together. Robust response matching and appropriate handling of additional records reduce opportunities for accepting unrelated data. The practical security of a resolver depends on its implementation and configuration, not just the fact that it speaks DNS.
Authentication is a separate protection
DNSSEC adds cryptographic validation for signed DNS data with a valid chain of trust. This provides a different kind of assurance from transaction matching alone. Validation must be correctly configured, and the relevant data must participate in a valid signed chain. DNSSEC does not make every unsigned answer authenticated.
Persistence and scope
An incorrect cached entry can influence later clients until it expires, is removed or is replaced according to resolver behavior. The impact depends on which records are affected and which clients use the resolver. A single client’s report should lead to comparison across appropriate perspectives, not an assumption that the entire internet sees the same answer.
Technical references: IETF RFC 5452 · DNS Forged-Answer Resilience · IETF RFC 4033 · DNSSEC Services and Limitations
How attackers use it
An attacker may try to make clients connect to an unintended destination or interfere with service discovery. The downstream effect depends on the application protocol and its identity checks. A browser that rejects an invalid TLS identity may show an error rather than silently connect, while other service paths require their own analysis.
The defender’s objective is to identify the incorrect answer, locate the affected resolver and remove the conditions that allowed it to be trusted. Operational exploitation details are not needed to build an effective baseline, compare evidence or verify a corrected resolver configuration.
Warning signs
Investigate a resolver returning an unexpected destination while authoritative data and independent trusted perspectives show the intended one. Record the queried name, record type, answer, resolver identity and time. Check whether ordinary caching, geographic routing or split-horizon DNS explains the difference first.
Validation failures need context
A validating resolver may reject data when signatures or the chain of trust are invalid. That can signal manipulation, but it can also result from a broken key rollover, expired signatures or other operational errors. A failure establishes a validation problem; determining its cause requires additional DNS and provider evidence.
Business impact
Incorrect cached data can affect many users without any change to the organization’s own zone. The result may be intermittent access problems, misdirected connections or a prolonged investigation involving multiple network teams and providers.
Because symptoms can vary by resolver and time, incomplete evidence can lead to premature closure. Keep the affected population and observation windows clear. A successful lookup from an unaffected network does not establish that the impacted resolver has recovered.
Prevention and remediation
Maintain supported resolver software and use documented secure configuration. Enable DNSSEC validation where appropriate and monitor its operation. Limit unnecessary resolver exposure and apply network controls suitable for the environment. Resolver administration and client configuration also need protection because not every incorrect answer arrives through a forged response.
Recovery checks
- Preserve the unexpected answer and identify the resolver that supplied it. - Compare with authoritative data and expected routing behavior. - Correct the resolver or trust-path issue and remove affected cached data as appropriate. - Repeat checks from the previously affected client perspective. - Confirm validation behavior and monitor for recurrence.
Clearing a cache can be part of recovery, but it should not substitute for finding the cause. If the evidence instead identifies an authoritative change or altered client resolver settings, use the corresponding response path rather than retaining an unsupported poisoning diagnosis.
How Ariema detects or handles it
Ariema compares resolver agreement and DNS targets, which can provide evidence of an unexpected resolution difference. Linking that difference with hosting and certificate observations can help reviewers identify an affected service path and a useful investigation window.
A difference alone cannot confirm cache poisoning. Resolver logs, configuration and authoritative data are needed to distinguish it from legitimate routing, stale answers or other manipulation. Ariema’s repeat observations can support verification that the externally observed discrepancy has ended.
Common questions
Is every stale cached answer poisoned?
No. A resolver can legitimately retain an earlier answer until its caching lifetime expires. Poisoning involves acceptance of incorrect data, not ordinary cache persistence.
Does clearing a cache fix the underlying weakness?
It can remove the current incorrect entry, but the resolver’s configuration, software or trust path may still need correction.
Can DNSSEC protect unsigned zones?
DNSSEC validation provides authenticity for a valid signed chain. An unsigned answer does not gain equivalent authentication merely because the resolver supports DNSSEC.
Sources & further reading
Primary technical references for this guide. Scenarios are illustrative; they are not customer observations.
IETF RFC 5452 · DNS Forged-Answer ResilienceIETF RFC 4033 · DNSSEC Services and LimitationsIETF RFC 9364 · DNS Security Extensions