We publicly release the following items:
|Security Advisory||Recommendations for Operators and Developers of DNS software|
|Technical report||For researchers and folks interested in the details|
|CycleHunter||Open-source tool to detect cyclic dependencies in DNS zone files|
In the meantime, two large Public Resolver DNS providers (Google Public DNS and Cisco OpenDNS) have fixed their software. We thank both Google and Cisco for fixing that vulnerability, given they are among the largest DNS services on the Internet. However, there are many other resolvers that may be vulnerable to tsuNAME.
Before this public disclosure, we disclosed tsunNAME to a series of trusted parties in trusted events, such as DNS-OARC, APTLD, LACTLD, and CENTR (all DNS-community events). Please see our Security Advisory for more details.
RFC1536 describes cyclic dependencies (albeit not using this term) on section 2:
"2. Recursion Bugs: ... In another situation, more difficult to detect, a set of servers might form a loop wherein A refers to B and B refers to A. This loop might involve more than two servers."
Even though RFC1536 says "loop can exist", it does not say how they can become amplification vectors. We show that these loops(cyclic dependencies), in combination with vulnerable resolvers and triggerng queries, can be used to DDoS authoritative DNS servers.
Our technical report describes a tsuNAME related event observed in 2020 at the .nz authroritative servers, when two domains were misconfigured with cyclic dependencies. It caused the total traffic to growth by 50%. In the report, we show how an EU-based ccTLD experienced a 10x traffic growth due to cyclic dependent misconfigurations.
In the case of .nz, we found that most queries were originated from Google Public DNS, but not all. Google has then fixed their software after our notification, and even kindly awarded us on their Vulnerability Award program (we will donate the award to an Internet charity). Similarly, Cisco OpenDNS has also been fixed after our notification.
We are happy that both Google and Cisco have mitigated this vulnerability in their resolver software. However, many old resolver software may still be vulnerable to tsuNAME, so we encourage resolver operators to follow our recommendations on our Security Advisory.
Last, given that the victims of tsuNAME related events are authoritative server operators, we recommend them to use CycleHunter periodically, so they can detect and eliminate cyclic dependencies from their zones ,which is the real trigger for vulnerable resolvers.
We have tested some resolvers in our technical report. Here we include the official statementes provided by resolver developers and operators:
|Giovane Moura||giovane.moura AT sidn.nl||SIDN Labs||The Netherlands|
|John Heidemann||johnh AT isi.edu||USC/ISI||USA|
|Sebastian Castro||sebastian AT internetnz.net.nz||InternetNZ||New Zealand|
|Wes Hardaker||hardaker AT isi.edu||USC/ISI||USA|