DNS cache poisoning has been a named attack since Dan Kaminsky's 2008 disclosure rewired the industry around source-port randomization and DNSSEC. For a while it felt like a solved problem. 2025 research argues that for one specific application — software update checks — the problem is unsolved enough to matter. The combination of update clients that trust DNS-resolved hostnames, resolvers that have rolled back DNSSEC validation for performance, and modern off-path attack primitives like SAD DNS has produced a plausible path from cache poisoning to malicious binary delivery, even against signed update channels.
This post walks through the 2025 state of DNS cache poisoning as applied to software update infrastructure, the specific techniques, and the defenses that actually interrupt the chain.
Why Did Kaminsky's Fix Not End This?
Kaminsky's 2008 attack exploited predictable DNS transaction IDs and predictable source ports. The industry response was source-port randomization, giving attackers roughly sixteen additional bits of entropy to guess. Combined with rate limits on NXDOMAIN responses, the attack was widely declared infeasible. DNSSEC was pushed as a longer-term fix but adoption has been slow; as of 2025 ICANN's public metrics show under 35% of .com domains with DNSSEC records, and the proportion of resolvers validating those records is meaningfully lower due to operational friction.
What reopened the door was 2020-2024 research into side channels that leak information about a resolver's source port. The SAD DNS paper by Keyu Man and colleagues, published at CCS 2020, demonstrated that ICMP error messages from UDP sockets could leak source-port information through rate-limit side channels, reducing the attacker's guessing space significantly. Follow-on work in 2022 and 2024 extended the technique to other operating systems and to additional leakage channels including TCP RST rate limits. Each of those papers received real patches in Linux, BSD, and Windows, but the pattern of patch-then-new-variant has continued.
2025 work by teams at Tsinghua University and UC Riverside showed that the side-channel primitives continue to produce usable leakage in specific configurations, particularly on middleboxes and home routers that have not received recent patches. The takeaway is not that DNS is catastrophically broken. It is that for a determined off-path attacker targeting a specific resolver used by a specific organization, the window to poison a cache entry is narrow but real.
What Makes Software Updates the Target of Choice?
Software update checks are uniquely attractive for a cache-poisoning campaign. They happen on a known schedule, usually at startup and on a timer. They resolve a well-known hostname, often with a long TTL. They fetch code that is signed, but they do so from the URL returned by the resolver, which means poisoning the DNS is sufficient to redirect the download to an attacker-controlled server. If the update client's signature verification is permissive, or has any fallback path, or is scoped to a CA rather than a specific key, the poisoned path can deliver a malicious update.
The 2025 research I'm citing includes a proof-of-concept against a synthetic update client modeled on patterns found in widely deployed enterprise software. The PoC demonstrates that a poisoned DNS response, combined with a non-validating resolver, can redirect an update check to a response server that serves a signed binary from a historical release that contains a since-patched vulnerability, re-exposing the victim to a known exploit. That specific variant — serving a legitimately signed but outdated binary — bypasses signature checks entirely, because the binary is signed by the correct vendor.
Which Update Clients Are Vulnerable in Practice?
The research identified a set of behaviors that render an update client vulnerable. First, accepting the resolver's result for the update hostname without any secondary check like certificate pinning or HPKP-equivalent. Second, downloading updates over plain HTTP, which still occurs in some embedded and network-appliance update flows. Third, accepting any binary signed by the vendor's CA rather than a specific signing key, enabling downgrade to an old-but-legitimate artifact. Fourth, running without version-rollback protection. Fifth, caching the resolved update host IP in-client for long periods, so that one poisoning event persists through reboots.
The specific clients documented in the 2025 research range from consumer antivirus update engines to industrial control system firmware updaters. The exact list is not fully public, but CISA's ICS advisories in 2024 and 2025 include several cases where update channel weaknesses of this shape were called out, including advisories against specific Schneider Electric and Siemens automation product lines.
How Does DoH and DoT Change the Picture?
DNS over HTTPS and DNS over TLS remove the on-path attacker from the equation by encrypting queries between client and resolver. They do not remove the off-path attacker from the resolver-to-authoritative leg of DNS, and the SAD DNS class of attacks targets that leg. An update client that resolves via DoH to a reputable resolver like 1.1.1.1 or 8.8.8.8 is harder to attack from a local network perspective but still inherits the resolver's upstream cache hygiene. If the resolver itself accepts a poisoned response from an authoritative server impersonator, the DoH client receives the poisoned answer.
Resolvers that validate DNSSEC and discard unvalidated responses meaningfully reduce the attack surface. The counter-pressure is that large public resolvers have occasionally disabled validation for specific zones to work around operational issues, and enterprise resolvers are a mixed bag. The 2024 KeyTrap DNSSEC vulnerability disclosure (CVE-2023-50387) caused several operators to disable or downgrade validation temporarily, creating a window where cache poisoning of affected zones was more feasible.
What Downgrade Tricks Extend the Attack?
Several extensions of the basic attack broaden its utility. DNS zone-walk discovery against NSEC-signed zones can enumerate update endpoints worth targeting. Predictable ephemeral port allocation on embedded devices with small kernels remains a contributing factor; several 2025 disclosures against home-router vendors' update clients exploited predictable source ports specifically because the kernel did not randomize them adequately. MITM on the TLS leg, after DNS redirection, can succeed if the update client does not strictly validate the server certificate against the intended hostname. Certificate transparency logs have reduced the feasibility of obtaining a fraudulently-issued certificate, but CT-log monitoring is not universal and CT-deficient CAs do appear periodically.
Finally, the 2025 research emphasizes that an attacker does not need to deliver new malware. Replaying an older signed update with a known vulnerability re-opens the vulnerability for re-exploitation by a separate toolchain. This is a downgrade attack and it works against any client that does not enforce minimum-version policies.
Which Defenses Actually Stop the Chain?
The defenses that interrupt the full chain, rather than one link, include: update clients that pin the public signing key of the vendor, not just the CA chain. Version-rollback protection that refuses to install a version older than the currently installed one. TLS certificate pinning for the update endpoint, such that a redirected IP address cannot present an otherwise-valid certificate for the legitimate hostname. DNSSEC validation in the resolver path, with hard-fail when records fail validation. Short cache TTLs for update endpoint resolutions so that any poisoning has limited persistence. Out-of-band update integrity checks, such as a periodic sync with a second-source update manifest delivered over a different channel.
For enterprise environments, the practical recommendation is to route update traffic from sensitive endpoints through a vetted outbound resolver that validates DNSSEC strictly and, where possible, to host an internal mirror of vendor update manifests that has its own integrity controls. This adds operational complexity but removes the ambient-DNS attack surface for the highest-value targets.
How Safeguard.sh Helps
DNS-based update redirection is a supply-chain attack where the tampered input never shows up in your source code, your build pipeline, or your SBOM. It shows up in the binary your running system fetches at 3am. Safeguard.sh's reachability analysis inventories every component that reaches out for updates, from language-runtime auto-updaters to embedded appliance firmware, and maps which of those update channels your workloads actually depend on. Griffin AI correlates DNS-related advisories, resolver CVEs, and vendor update-client weaknesses against your specific inventory, flagging the update paths most exposed to the cache-poisoning class.
Eagle watches for the moment a new update-client vulnerability or a new SAD DNS variant lands, triggering continuous scanning of affected components and enforcing guardrails like minimum-version policies and update-channel whitelists before a poisoned download can complete. 100-level transitive dependency tracing catches update paths buried inside libraries you did not know were phoning home. Container self-healing refreshes images from trusted registries when a base-image update channel is suspected of poisoning. For teams whose security posture assumes their signed binaries came from the right place, Safeguard.sh helps you verify that assumption end-to-end.