Happy holidays from ISC!
ISC is fortunate to have staff members in so many different countries around the world: our software development benefits from all the different perspectives - and we benefit personally!
Read post
Recently announced TsuNAME vulnerability does not impact BIND 9
Last week researchers announced the TsuNAME vulnerability that impacted several of the largest hosted DNS services on the Internet, including Google’s public DNS and Cisco’s OpenDNS. ISC was notified of the vulnerability long before the public disclosure, and we verified that BIND already had defenses against this problem.
TsuNAME is a problem that affects authoritative zone operators hosting zones that have cyclical dependences between the NS RRsets in their zones. This causes some resolvers to loop, endlessly sending queries while following the referrals. The result is the authority servers are overwhelmed and the resolver resources are consumed with these unending queries. This has actually happened with at least two ccTLD operators. The solution is for zone operators to detect and remove cyclical dependencies. In addition, all DNS resolvers should have limits in place to curb excessive looping that might occur due to following cyclical NS delegations.
BIND already has recursion limits that prevent looping. As it says in the advisory:
“We configure a test zone with cyclic dependency and evaluate popular DNS resolvers: Unbound (v 1.6.7) [8], BIND (v 9.11.3) [5], and KnotDNS (v 5.1.3) [1], on a VM on AWS EC2 (FRA). We found that none of the start looping in the presence of cyclic dependent domains, hence are not vulnerable to it.”
ISC has tested and evaluated BIND and confirmed it is not vulnerable to this problem. All modern BIND Resolvers are unaffected by this issue because of these two resolver limits (tunable) that prevent BIND from looping endlessly:
max-recursion-queries
This sets the maximum number of iterative queries that may be sent while servicing a recursive query. If more queries are sent, the recursive query is terminated and returns SERVFAIL.
max-recursion-depth
This sets the maximum number of levels of recursion that are permitted at any one time while servicing a recursive query.
Resolving a name may require looking up a name server address, which in turn requires resolving another name, etc.; if the number of recursions exceeds this value, the recursive query is terminated and returns SERVFAIL.
Our advice to DNS operators:
Resolver operators: Run a modern version of BIND that includes max-recursion-depth and max-recursion-queries feature options. The default settings should be appropriate in almost all situations (they do not need to configured explicitly).
See also CVE-2020-8616 in which we ensured that there are no exceptions to these checks:
- [security] Further limit the number of queries that can be triggered from a request. Root and TLD servers are no longer exempt from max-recursion-queries. Fetches for missing name server address records are limited to 4 for any domain. (CVE-2020-8616) [GL #1388]
Authoritative zone owners and hosts: It is not possible via simple inspection of individual zones to see if they could be involved in a cyclical dependency as described in the authors of the TsuNAME paper (with one exception - that being that all nameservers for a zone are within that actual zone itself). Therefore we recommend using a cyclical dependency checker tool to test your zones now, and on a regular basis hereafter. The authors of the TsuNAME paper suggest using this tool: