Security analysis · Reviewed October 24, 2026
A forgotten DNS record can outlive the server, supplier or campaign it once supported. If somebody else gains control of its destination, the record can keep directing trust to the wrong place. But not every attack involving DNS is a configuration mistake: some attackers steal administrative access, while others interfere with internet routing.
These five documented cases show the difference. They are selected for the quality of their public evidence, not ranked by popularity or financial damage. The first three involve stale records or broken delegation. The final two are related attacks that should not be mislabeled as incidents caused simply by a missing DNS record.
1. SubdoMailing: abandoned dependencies became email infrastructure
In its February 26, 2024 investigation, Guardio Labs described malicious email using neglected domain relationships. One example involved marthastewart.msn.com, whose CNAME still pointed to a former promotional domain. Guardio reported that the destination had been registered again in September 2022 and used to provide attacker-controlled SPF authorization. The same investigation documented abuse of abandoned domains referenced by SPF policies. Read Guardio’s investigation.
The evidence included email headers and DNS records. Importantly, Guardio explicitly distinguished the observed malicious email from a hypothetical phishing website demonstration. Its sample’s passing DMARC result concerned the visible From domain shown in that sample; it was not proof that every message impersonating the brand would pass DMARC.
Practical lesson: review the ownership and purpose of CNAME targets and SPF dependencies, not just whether the records exist. Remove obsolete authorizations through a controlled change process. Signing stale information with DNSSEC does not make its destination trustworthy.
2. Sitting Ducks: delegation without effective ownership checks
Infoblox and Eclypsium’s July 31, 2024 report described actual domain hijacking through a combination of lame delegation and an exploitable DNS provider. A domain still delegated authority to a service that lacked its active zone, while an attacker could claim that domain at the provider without controlling the legitimate owner’s registrar account. A broken delegation alone does not establish that a takeover is possible. See the original conditions and mitigation guidance.
Infoblox’s November follow-up described campaigns using hijacked domains for malicious traffic distribution, investment fraud and phishing. These were reported observations, not merely counts of potentially vulnerable names. Read the follow-up research.
Practical lesson: reconcile registrar delegation with the authoritative service you actually control, and ask how the provider verifies a new claim. DNSSEC needs an intact trust chain and validation; it does not repair abandoned hosting relationships or guarantee availability.
3. TrackJS: an old A record reached a new server owner
In a September 2026 firsthand account, Todd Gardner described discovering an unauthorized Search Console owner on August 27. An old development-documentation hostname, dev-docs.trackjs.com, still had an A record pointing to an address released after its cloud server was retired. Someone controlling that address hosted SEO spam under the hostname and obtained a TLS certificate. Read the owner’s account.
The reported outcome was unwanted content, not demonstrated theft of customer credentials. The account says the team removed the stale record and recovered the Search Console property. It is a useful recent example, not a claim that this is one of history’s largest attacks.
Practical lesson: remove obsolete DNS references as part of resource retirement. A working address and valid certificate do not prove that your organization still controls the destination. DNSSEC would authenticate the published record, including a stale one.
Related, but different: two DNS hijacking incidents
4. MyEtherWallet, April 24, 2018: the route to DNS was intercepted
Cloudflare’s firsthand analysis documented unauthorized BGP announcements affecting routes to Amazon Route 53 DNS addresses. Affected resolvers received false answers for MyEtherWallet. Cloudflare also described the fraudulent site’s untrusted certificate warning. This was routing interception and forged DNS responses, not evidence that a forgotten CNAME or missing MX record caused the incident. Read Cloudflare’s analysis.
Practical lesson: routing security, DNS validation and certificate verification address different boundaries. Do not bypass a certificate warning to make a connection work. DMARC would not authenticate the website or secure the route.
5. Netnod, December 2018–January 2019: unauthorized DNS changes
Netnod’s own statement describes three attacks in short windows from December 14, 2018 to January 2, 2019. Two involved DNS changes affecting a small number of customers. For the third, involving portal and API traffic, Netnod said its forensic work found no affected customers who used those services during the window, partly because its zones were signed and responses validated with DNSSEC. Read Netnod’s statement and recommendations.
Practical lesson: protect the DNS administration path as well as answers: strong authentication, appropriate registration locks, account review and monitoring matter. Do not generalize this incident into a claim that the public DNS root was compromised; Netnod explicitly rejected that implication.
Start with the dependency, not a security score
Ask who owns each destination, who can change it, and what evidence confirms that control. A missing policy can deserve investigation without proving an attack occurred. For the protocol boundaries, continue with our guides to DNSSEC validation, DANE service authentication and SPF, DKIM and DMARC alignment.
For a starting view of public configuration evidence, try the SysSeder DNS Inspector. Read its coverage and unknowns: it is not a complete zone inventory, takeover audit or security certification.