Suspected DNS poisoning calls for a structured investigation of unexpected DNS data. Record what the client observed, which resolver path it used and how the result differs from the expected configuration. An unfamiliar address or a difference between two answers is a reason to investigate, not sufficient evidence to label an incident poisoning.
The following is a defensive triage framework for an organization's authorized operations team. Use the organization's incident process for containment, escalation and recovery decisions.
Preserve the original observation
Record the queried name, record type, time, client context and answer received. Include the resolver used and any visible error or response status. Capture the business symptom separately: a failed login, an unexpected destination or an application warning is not the same thing as a DNS response.
Before making broad cache or configuration changes, preserve the information needed to understand the original state, where the incident process permits. If urgent containment is required, record what changed and when so investigators can interpret later differences.
Check legitimate reasons for a different answer
Compare the observation with the organization's expected resolver configuration, internal zones and planned changes. Ask whether the client moved between networks, used a different approved resolver or reached a service with intentionally variable answers.
Use independent checks as additional evidence rather than treating any public resolver as a universal source of truth. The expected answer may depend on the legitimate architecture. Ask the responsible DNS and application owners to explain that context.
Build an investigation timeline
- Client observation. Question it helps answer: What did the affected user actually receive?
- Resolver path. Question it helps answer: Which systems handled the request?
- DNS and configuration records. Question it helps answer: What was expected at that time?
- Change history. Question it helps answer: Did an authorized change explain the difference?
- Scope checks. Question it helps answer: Which other clients or names show the symptom?
- Recovery observations. Question it helps answer: What changed after the approved action?
Keep raw observations and interpretation distinguishable. If the team has only established an incorrect answer, say that; record the suspected cause as a hypothesis until the investigation supports it.
Review validation without overclaiming its coverage
RFC 4033 describes DNSSEC's authentication and integrity functions. Ask where validation occurs and what was actually validated for the affected query. Do not assume every name is signed or every resolver in the path performs validation.
Transport protection is another layer. RFC 7858 describes DNS over TLS; an encrypted connection does not by itself establish that every DNS answer is authentic. Keep transport observations separate from validation evidence.
Turn findings into infrastructure requirements
After recovery, identify which evidence was available and what the team could not establish. Propose improvements to logging, configuration review, resolver-path visibility or validation tests based on that gap. Avoid purchasing a feature solely because its name resembles the incident label.
ZDNS presents enterprise resolution functions on its DNS page. Use your evidence and visibility requirements to ask what the proposed configuration can record and verify.
Questions about suspected poisoning
Does a different DNS answer prove an attack?
No. Investigate the expected configuration and legitimate resolution behavior first.
Should I clear every cache immediately?
Follow the incident process and consider evidence preservation alongside containment needs.
Does TLS prove that DNS data is valid?
Transport protection and DNS data validation address different requirements.
What should the incident summary contain?
Separate observations, confirmed causes, actions taken and unresolved questions.
What can I discuss with ZDNS afterward?
Share the architecture and evidence requirements. Request confirmation of relevant logging, resolution and validation functions for the intended deployment.