NXNSAttack is a DNS attack that abuses how recursive resolvers handle referral responses. A crafted referral makes the resolver send a very large number of extra queries, which can slow it down or turn it into a reflector against a victim. ISC tracked the BIND issue as CVE-2020-8616 and fixed it in May 2020.
What happened?
On 19 May 2020 the Internet Systems Consortium (ISC) published advisory CVE-2020-8616, titled "BIND does not sufficiently limit the number of fetches performed when processing referrals." The advisory rated it High, exploitable remotely, with a CVSS score of 8.0.
ISC credits Lior Shafir and Yehuda Afek of Tel Aviv University and Anat Bremler-Barr of the Interdisciplinary Center Herzliya with discovering and reporting it. The researchers wrote an academic paper on the technique. ISC noted it knew of no active exploits at the time of posting, though the paper had been published that month.
How does the attack work?
When a recursive resolver looks up a name, it asks authoritative servers. Sometimes the answer is a referral: not the record itself, but a pointer to other name servers that are responsible for that part of the namespace. The resolver then has to look up the addresses of those servers and ask them.
ISC explains that, in the original design of BIND and other name servers, the number of fetches performed while processing a referral was not sufficiently limited. A malicious actor can craft referrals that make a recursing server issue a very large number of fetches.
ISC lists at least two effects. The performance of the recursive server can degrade because of the extra work. And the attacker can use the recursing server as a reflector in a reflection attack, with a high amplification factor, meaning a small request triggers a much larger volume of traffic toward a target.
Which software was affected?
ISC's advisory names BIND versions from 9.0.0 through 9.11.18, 9.12.0 through 9.12.4-P2, 9.14.0 through 9.14.11, 9.16.0 through 9.16.2, and 9.17.0 through 9.17.1, along with obsolete development branches and the Supported Preview Edition. The advisory describes it as a design limitation shared with other name servers, so check any resolver you run, not only BIND, and read your vendor's notes.
Authoritative-only servers are not what this advisory describes, because the problem arises when a server performs recursion. Resolvers open to many clients are most exposed.
How do you protect resolvers?
ISC says there is no workaround. The solution it gave was to upgrade to a patched release closest to your branch: BIND 9.11.19, 9.14.12 or 9.16.3, with 9.11.19-S1 for the Supported Preview Edition. Newer releases carry later fixes.
Beyond the patch, general resolver hygiene limits how much damage any such flaw can do.
How to check or apply this
- Inventory every recursive resolver you operate, including ones inside appliances and cloud images.
- Record the software and version for each. Compare with the vendor advisory.
- Upgrade to a supported, patched release. If the product is end of life, plan replacement.
- Restrict recursion to the clients that need it. An open resolver on the internet is both a target and a tool for attackers.
- Monitor query rates per client and the number of upstream queries per client query. A sharp ratio change is a signal.
- Keep resolvers' logs and statistics where you can read them during an incident.
- Have a contact path with your upstream provider, who may be able to filter reflection traffic.
- Subscribe to advisories from your resolver vendor.
A constructed example
An internet provider runs six resolvers on a BIND version from 2018. Monitoring shows upstream queries per second creeping up at night without a matching rise in customer lookups. The ratio is the clue. A review of vendor notices finds the referral limit advisory. The team upgrades one resolver first, sees the ratio normalize in its graphs, then rolls the upgrade to the rest.
The detection came from a ratio nobody had been watching, which is cheap to add.
What is the lesson beyond DNS?
Protocols that make one party do more work than the requester spent are amplification risks. When you design a service that fans out to other systems on a client's behalf, cap the fan-out per request. ISC's finding was that an unbounded loop in normal behavior is a vulnerability once someone controls the input.
Quick check
Is there a workaround for CVE-2020-8616 other than upgrading?
ISC's advisory lists workarounds as none. The fix is to upgrade to a patched release.
Does this affect authoritative DNS servers?
The advisory describes a flaw in servers performing recursion. Authoritative-only servers that do not recurse are not the issue it describes, but confirm with your vendor.
Sources
- ISC: CVE-2020-8616, BIND does not sufficiently limit the number of fetches performed when processing referrals
- RFC 2827: Network Ingress Filtering
Last reviewed: 18 October 2026.
