DNS attacks target the integrity or availability of name resolution. Understanding where an answer came from—registrar, authoritative server, recursive resolver or cache—is essential to distinguishing an unauthorized change from a normal difference in resolution.
What it is
DNS connects names to records such as addresses, mail destinations and service configuration. Its operation spans several administrative and technical layers. A registrar controls registration and delegation settings; authoritative servers publish zone data; recursive resolvers obtain answers for clients and cache them. An incident at one layer can look different from an incident at another.
DNS attacks include unauthorized management changes, forged or poisoned resolution data and disruption of DNS service. A stale but correctly published record can also create a security problem without any attacker altering the DNS system. Classify the condition before choosing a response.
Explore this topic in depth
Subdomain takeover5 min readDNS hijacking5 min readDNS cache poisoning5 min readDNSSEC and DNS integrity5 min readHow it works
A client commonly asks a recursive resolver for an answer. The resolver may use a cached response or consult the DNS hierarchy to obtain authoritative data. Records carry a time to live that influences caching. Changing an authoritative record does not instantly replace every cached answer already held elsewhere.
Control-plane changes
A compromised registrar or DNS management account can alter delegation or zone records through legitimate administrative mechanisms. The resulting answer may be delivered consistently by authoritative servers. Consistency therefore does not prove that the change was authorized by the business.
Resolution-path manipulation
A different class of attack targets what a resolver or client accepts as an answer. Cache poisoning concerns incorrect data stored and reused by a resolver. Local configuration changes can redirect a client to an untrusted resolver. Investigating these cases requires attention to the resolution path, not just the public zone.
Availability failures
DNS service can become unavailable through overload, configuration errors or infrastructure failure. From the user’s perspective, an otherwise healthy application may seem offline. Record whether the failure is name resolution, network connection or application response; those are different stages.
Technical references: IETF RFC 4033 · DNSSEC Services and Limitations · IETF RFC 5452 · DNS Forged-Answer Resilience
How attackers use it
An altered destination can redirect users, mail or service traffic. Unauthorized mail records may affect delivery, while changed nameserver delegation can shift control over a wider zone. Attackers may also disrupt resolution to interfere with access or distract response teams.
The effect depends on downstream controls. Correct TLS identity validation can prevent a client from silently accepting some unintended HTTPS destinations. It does not restore DNS availability or validate every non-web protocol. Follow the specific service path rather than making a universal claim about redirection impact.
Warning signs
Investigate unapproved nameserver or record changes, unexpected mail destinations, unexplained resolution failures and differences that conflict with the known routing design. Review registrar and provider audit records where available. Compare current authoritative answers with resolver observations and the previous intended state.
Benign causes worth ruling out
CDNs and geographic policies can return different addresses by location. Split-horizon DNS deliberately provides different internal and external answers. Cached records can remain after a migration. A DNSSEC validation failure can result from an operational mistake rather than malicious tampering. These explanations still need evidence; they should not be used to dismiss an unexplained change automatically.
Business impact
DNS problems can affect web access, email delivery, authentication flows and integrations simultaneously. A single shared dependency can create a broad outage. Integrity failures can also undermine trust in where users and applications connect.
Response costs increase when teams lack a known-good zone state, registrar contacts or clear authority to change records. DNS should be treated as a critical dependency with recovery procedures, not merely a supporting configuration that is examined only after an outage begins.
Prevention and remediation
Protect registrar and DNS management accounts with strong authentication, limited privileges and monitored change processes. Maintain known-good configurations and test recovery responsibilities. Use DNSSEC where appropriate with the operational processes needed to maintain a valid chain of trust; it is not a replacement for account security.
Investigation sequence
- Identify the affected name, record type, resolver perspective and observation time. - Compare delegation and authoritative data with the approved baseline. - Review cached answers and expected routing differences. - Check administrative changes and account activity through trusted provider channels. - Restore the intended state and verify relevant services after caching effects are considered. - Investigate potential downstream misuse separately from restoring resolution.
How Ariema detects or handles it
Ariema compares DNS targets and resolver agreement, linking observations with hosting and domain lifecycle context. This can help establish when a visible relationship changed and which related services need review.
Ariema’s external evidence does not identify every cause of a discrepancy. Registrar audit logs, resolver telemetry and endpoint configuration may be needed to distinguish administrative hijacking, cache behavior and local manipulation. Retest evidence can document restored public resolution without implying that all incident consequences have been resolved.
Common questions
Do different DNS answers mean an attack?
No. Caching, geographic routing, load balancing and split-horizon configurations can legitimately produce differences. Investigate unexpected changes against the intended design and authoritative state.
Does HTTPS prevent every DNS-related incident?
No. Correct certificate validation helps resist some redirection scenarios, but DNS disruption can still cause outages and compromised control paths can affect services beyond a browser connection.
Are DNSSEC and encrypted DNS interchangeable?
No. DNSSEC authenticates signed DNS data. Encrypted DNS protects a transport connection to a resolver. They address different threats and have different trust boundaries.
Sources & further reading
Primary technical references for this guide. Scenarios are illustrative; they are not customer observations.
IETF RFC 4033 · DNSSEC Services and LimitationsIETF RFC 5452 · DNS Forged-Answer ResilienceCISA · DNS Infrastructure Hijacking CampaignCISA · Mitigate DNS Infrastructure Tampering