The NXNSAttack is a new vulnerability that exploits the way DNS recursive resolvers operate when receiving NS referral response that contains nameservers but without their corresponding IP addresses (i.e., missing glue-records). The number of DNS messages exchanged in a typical resolution process might be much higher in practice than what is expected in theory, mainly due to a proactive resolution of name-servers’ IP addresses. This inefficiency becomes a bottleneck and might be used to mount a devastating attack against either or both, recursive resolvers and authoritative servers. The NXNSAttack is more effective than the NXDomain attack: i) It reaches an amplification factor of more than 1620x on the number of packets exchanged by the recursive resolver. ii) Besides the negative cache, the attack also saturates the ’NS’ resolver caches.
A responsible coordinated disclosure procedure has been performed following the discovery of the NXNSAttack described in the paper below. Several DNS software vendors and service providers have adopted measures to protect against the destructive measures of the NXNSAttack.
NXNSAttack was discovered and reported by:
The core building block of the NXNSAttack is the amplifier, which is composed of three components: two attacker components and one innocent recursive resolver. The two attacker’s components are a client and an authoritative name-server. Essentially the attacker issues many requests for sub-domains of domains authorized by its own authoritative server (step 1 above). Each such request is crafted to have a different sub-domain to make sure it is not in the resolver’s cache, thus forcing the resolver to communicate with the attacker’s authoritative server to resolve the queried subdomains (step 2). The attacker authoritative name-server then returns an NS referral response with n name-server names but without their glue records (step 3), i.e., without their associated IP addresses, forcing the resolver to start a resolution query for each one of the name-server names in the response, whether these name-servers are in-bailiwick or out-of-bailiwick because it does not have their IP addresses in its cache (step 4). The attacker’s authoritative referral response issues n new and different delegated name-servers each time it receives a query for a sub-domain from the recursive resolver.
Illustration of the double amplification attack using self delegations in the first referral response. This attack variant (c) reaches a firepower of 19,980.
Here the attacker uses the self delegations technique to increase the number of concurrent referrals to the ROOT name-servers. In our empirical tests, the victim processes up to 81,428 packets (14,126,945 bytes) for each client request (and corresponding 75 referral packets) that the attacker generates (it is “only” 81,428 because many were lost).
|ISC BIND||Security Advisory / CVE-2020-8616|
|NLnet Labs Unbound||CVE-2020-12662|
|NIC.CZ Knot Resolver||Blog Post / CVE-2020-12667|
|has been patched.|
|Microsoft||Security Advisory / Guidance for ADV200009|
|Cloudflare||has been patched.|
|Amazon||has been patched.|
|Oracle (DYN)||Oracle Critical Patch Update Advisory.|
|Verisign||has been patched.|
|Quad9||has been patched.|
|ICANN||has been patched.|
We would like to thank Michael McNally and Cathy Almond of ISC, Ralph Dolmans, Wouter Wijngaards and Benno Overeinder of NLnet Labs, Petr Spacek of NIC.CZ, Francis Perron of Google, Remi Gacogne and Peter van Dijk of PowerDNS, John Todd of Quad9, Tim April and Ralf Weber of Akamai and James Adair and Matthew Pozun of Verisign for their cooperation and helpful discussions upon disclosing this issue, as well as Eyal Ronen and Yair Kaldor for their help with this project.