Public Disclosure

We publicly release the following items:

We have disclosed tsuNAME during the DNS OARC35 workshop. You can check our slides too (video will be later posted).

Responsible Disclosure

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.

tsuNAME in a nutshell

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.

Resolver vendors statement

We have tested some resolvers in our technical report. Here we include the official statementes provided by resolver developers and operators:

• ISC official statement on BIND9 and tsuNAME (2021-05-11)
• PowerDNS official statement (2021-05-10)
• NLnet Labs statement on Unbound and tsuNAME (2021-05-10)

Contact