Un grup de cercetători de la Universitatea Tel Aviv și Centrul Interdisciplinar din Herzliya (Israel)
Problema este legată de particularitățile protocolului și afectează toate serverele DNS care acceptă procesarea recursivă a interogărilor, inclusiv
Atacul se bazează pe faptul că atacatorul folosește solicitări care se referă la un număr mare de înregistrări NS fictive nevăzute anterior, cărora le este delegată determinarea numelui, dar fără a specifica înregistrări lipite cu informații despre adresele IP ale serverelor NS în răspuns. De exemplu, un atacator trimite o interogare pentru a rezolva numele sd1.attacker.com controlând serverul DNS responsabil pentru domeniul attacker.com. Ca răspuns la solicitarea rezolutorului către serverul DNS al atacatorului, este emis un răspuns care deleagă determinarea adresei sd1.attacker.com serverului DNS al victimei, indicând înregistrările NS în răspuns fără a detalia serverele IP NS. Deoarece serverul NS menționat nu a fost întâlnit înainte și adresa sa IP nu este specificată, rezolutorul încearcă să determine adresa IP a serverului NS trimițând o interogare către serverul DNS al victimei care deservește domeniul țintă (victim.com).
Problema este că atacatorul poate răspunde cu o listă uriașă de servere NS care nu se repetă cu nume de subdomenii de victimă fictive inexistente (fake-1.victim.com, fake-2.victim.com,... fake-1000. victim.com). Resolverul va încerca să trimită o cerere către serverul DNS al victimei, dar va primi un răspuns că domeniul nu a fost găsit, după care va încerca să determine următorul server NS din listă și așa mai departe până când va încerca toate Înregistrările NS listate de atacator. În consecință, pentru cererea unui atacator, soluția va trimite un număr mare de solicitări pentru a determina gazdele NS. Deoarece numele serverelor NS sunt generate aleatoriu și se referă la subdomenii inexistente, ele nu sunt preluate din cache și fiecare solicitare din partea atacatorului are ca rezultat un val de cereri către serverul DNS care deservește domeniul victimei.
Cercetătorii au studiat gradul de vulnerabilitate al rezolutorilor DNS publici la problemă și au stabilit că atunci când se trimit interogări către rezolutorul CloudFlare (1.1.1.1), este posibil să crească numărul de pachete (PAF, Packet Amplification Factor) de 48 de ori, Google. (8.8.8.8) - de 30 de ori, FreeDNS (37.235.1.174) - de 50 de ori, OpenDNS (208.67.222.222) - de 32 de ori. Se observă indicatori mai vizibili pentru
Nivelul 3 (209.244.0.3) - de 273 de ori, Quad9 (9.9.9.9) - de 415 ori
SafeDNS (195.46.39.39) - de 274 de ori, Verisign (64.6.64.6) - de 202 de ori,
Ultra (156.154.71.1) - de 405 de ori, Comodo Secure (8.26.56.26) - de 435 de ori, DNS.Watch (84.200.69.80) - de 486 de ori și Norton ConnectSafe (199.85.126.10) - de 569 de ori. Pentru serverele bazate pe BIND 9.12.3, datorită paralelizării solicitărilor, nivelul câștigului poate ajunge până la 1000. În Knot Resolver 5.1.0, nivelul câștigului este de aproximativ câteva zeci de ori (24-48), de la determinarea Numele NS se execută secvenţial şi se bazează pe limita internă a numărului de paşi de rezoluţie a numelor permise pentru o cerere.
Există două strategii principale de apărare. Pentru sisteme cu DNSSEC
Sursa: opennet.ru