Temporary workaround for SAD DNS
Ahead of Linux’s patch taking effect, BlueCat Labs has a temporary workaround for protecting against the revived Kaminsky DNS cache poisoning attack.
Researchers discovered SAD DNS, a side-channel variant of the Kaminsky DNS cache poisoning attack that abuses static ICMP rate limits to infer DNS source ports. Linux developers added a kernel change on October 16, 2020 to randomize ICMP rate limiting to mitigate the attack, but widespread adoption may take time, leaving many systems exposed. BlueCat is tracking the issue, providing guidance and a workaround script via its BlueCat Labs GitHub, recommending DNSSEC and advising against blocking ICMP outright.
What is SAD DNS and how does it differ from the original Kaminsky attack?
SAD DNS is a side-channel variant of the Kaminsky DNS cache poisoning attack that leverages information leaked through static ICMP rate limits to discover DNS source ports. Unlike the original Kaminsky attack, which focused on predicting transaction IDs and source ports through high-volume spoofed queries, SAD DNS uses the attacker’s ability to observe how a target’s ICMP rate limiting responds to probes; the static, predictable rate value becomes a side channel that reveals port information. This enables an attacker to reduce the entropy of source port selection and increase the likelihood of successful cache poisoning.
What mitigation did Linux developers introduce and why might additional measures still be necessary?
Linux developers implemented a kernel change on October 16, 2020 that randomizes ICMP rate limits, preventing attackers from exploiting a static rate value to infer DNS port numbers. However, David Maxwell of BlueCat noted that it may take time for this kernel change to be adopted widely across systems, leaving many servers unprotected in the interim. Therefore, additional measures such as deploying BlueCat’s provided shell script to randomize ICMP rate limits on affected systems and implementing DNSSEC are recommended until the kernel-level fix is broadly available.
What practical steps does BlueCat recommend for customers and the broader community?
BlueCat advises customers to consult the customer care portal article KI-024626 for up-to-date guidance and states it is continually assessing risk to BlueCat products and suggesting actions. For the wider community running public BIND-based DNS servers, BlueCat has published a small shell script in its BlueCat Labs GitHub repository that randomizes ICMP rate limits as a viable workaround to reduce SAD DNS risk. BlueCat also recommends implementing DNSSEC for stronger DNS integrity and explicitly advises against blocking ICMP entirely, noting that this recommendation has appeared on the internet but is not endorsed by BlueCat.
Recently, researchers identified a new way to carry out the Kaminsky DNS cache poisoning attack. Its name is SAD DNS, short for Side-channel AttackeD DNS.
Linux developers have made a change to block this. But it was only introduced into the kernel on October 16, 2020. It may be a while before the change is adopted across most systems, David Maxwell, BlueCat’s Software Security Director, told BleepingComputer.
For BlueCat customers: The customer care portal contains a KI article (KI-024626) that BlueCat is keeping up to date. BlueCat is continually assessing the risk to you and your BlueCat products and suggested steps to take.
For the rest of the community running public BIND-based DNS servers: There is a viable workaround. Linux’s change, once implemented, will randomize ICMP rate limits to stop an attacker from abusing the static rate value to identify a port number. You can achieve a similar outcome with a small shell script.
BlueCat’s GitHub repository, BlueCat Labs, now contains the script that members of the broader community can use to randomize ICMP rate limits and reduce risk against SAD DNS.

In addition, BlueCat recommends implementing DNSSEC. BlueCat has also noticed some advice on the internet suggesting to block ICMP altogether; BlueCat recommends against this.