A group of researchers from Tel Aviv University and the Interdisciplinary Center in Herzliya (Israel)
The problem is related to the peculiarities of the protocol and affects all DNS servers that support recursive query processing, including
The attack is based on the use by the attacker of requests referring to a large number of previously unseen dummy NS records, to which the definition of the name is delegated, but without specifying glue records with information about the IP addresses of NS servers in the response. For example, an attacker sends a request to determine the name sd1.attacker.com by controlling the DNS server responsible for the attacker.com domain. In response to the resolver's request to the attacker's DNS server, a response is issued delegating the determination of the address sd1.attacker.com to the victim's DNS server by specifying NS records in the response without specifying the IP of the NS servers. Since the mentioned NS server has not been previously encountered and its IP address is not specified, the resolver tries to determine the IP address of the NS server by forwarding a query to the DNS server of the victim serving the target domain (victim.com).
The problem is that the attacker can respond with a huge list of non-repeating NS servers with non-existent fictitious names of the victim's subdomains (fake-1.victim.com, fake-2.victim.com, ... fake-1000.victim.com). The resolver will try to send a request to the victim's DNS server, but will receive a response that the domain was not found, after which it will try to determine the next NS server in the list, and so on until it has gone through all the NS records listed by the attacker. Accordingly, for one attacker's request, the resolver will send a huge number of requests to determine NS hosts. Because NS server names are generated randomly and refer to non-existent subdomains, they are not retrieved from the cache, and each attacker's request results in a flurry of requests to the DNS server serving the victim's domain.
The researchers studied the degree of exposure to the problem of public DNS resolvers and determined that when sending requests to the CloudFlare (1.1.1.1) resolver, you can achieve an increase in the number of packets (PAF, Packet Amplification Factor) by 48 times, Google (8.8.8.8) - 30 times, FreeDNS (37.235.1.174) - 50 times, OpenDNS (208.67.222.222) - 32 times. More significant results are observed for
Level3 (209.244.0.3) - 273 times, Quad9 (9.9.9.9) - 415 times
SafeDNS (195.46.39.39) - 274 times, Verisign (64.6.64.6) - 202 times,
Ultra (156.154.71.1) - 405 times, Comodo Secure (8.26.56.26) - 435 times, DNS.Watch (84.200.69.80) - 486 times, and Norton ConnectSafe (199.85.126.10) - 569 times. For servers based on BIND 9.12.3, the amplification level can reach up to 1000 due to query parallelization. limit on the number of name resolution steps allowed per request.
There are two main defense strategies. For systems with DNSSEC
Source: opennet.ru