Një grup studiuesish nga Universiteti i Tel Avivit dhe Qendra Ndërdisiplinore në Herzliya (Izrael)
Problemi lidhet me veçoritë e protokollit dhe prek të gjithë serverët DNS që mbështesin përpunimin rekurziv të pyetjeve, duke përfshirë
Sulmi bazohet në sulmuesin duke përdorur kërkesa që i referohen një numri të madh të regjistrimeve fiktive NS të paparë më parë, të cilave u delegohet përcaktimi i emrit, por pa specifikuar regjistrime ngjitëse me informacione për adresat IP të serverëve NS në përgjigje. Për shembull, një sulmues dërgon një pyetje për të zgjidhur emrin sd1.attacker.com duke kontrolluar serverin DNS përgjegjës për domenin sulmer.com. Në përgjigje të kërkesës së zgjidhësit për serverin DNS të sulmuesit, lëshohet një përgjigje që delegon përcaktimin e adresës sd1.attacker.com te serveri DNS i viktimës duke treguar të dhënat NS në përgjigje pa detajuar serverët IP NS. Meqenëse serveri NS i përmendur nuk është hasur më parë dhe adresa e tij IP nuk është e specifikuar, zgjidhësi përpiqet të përcaktojë adresën IP të serverit NS duke dërguar një pyetje te serveri DNS i viktimës që shërben domenin e synuar (victim.com).
Problemi është se sulmuesi mund të përgjigjet me një listë të madhe të serverëve NS që nuk përsëriten me emra fiktive të nëndomaineve të viktimave që nuk ekzistojnë (fake-1.victim.com, fake-2.victim.com,... fake-1000. viktima.com). Zgjidhësi do të përpiqet të dërgojë një kërkesë në serverin DNS të viktimës, por do të marrë një përgjigje se domeni nuk u gjet, pas së cilës do të përpiqet të përcaktojë serverin tjetër NS në listë, dhe kështu me radhë derisa të ketë provuar të gjitha Regjistrimet NS të listuara nga sulmuesi. Prandaj, për kërkesën e një sulmuesi, zgjidhësi do të dërgojë një numër të madh kërkesash për të përcaktuar hostet NS. Meqenëse emrat e serverëve NS krijohen në mënyrë të rastësishme dhe u referohen nëndomaineve joekzistente, ato nuk merren nga cache dhe çdo kërkesë nga sulmuesi rezulton në një mori kërkesash për serverin DNS që i shërben domenit të viktimës.
Studiuesit studiuan shkallën e cenueshmërisë së zgjidhësve publik DNS ndaj problemit dhe përcaktuan se kur dërgoni pyetje në zgjidhësin CloudFlare (1.1.1.1), është e mundur të rritet numri i paketave (PAF, Faktori i Përforcimit të Paketave) me 48 herë, Google (8.8.8.8) - 30 herë, FreeDNS (37.235.1.174) - 50 herë, OpenDNS (208.67.222.222) - 32 herë. Vërehen tregues më të dukshëm për
Niveli 3 (209.244.0.3) - 273 herë, Quad9 (9.9.9.9) - 415 herë
SafeDNS (195.46.39.39) - 274 herë, Verisign (64.6.64.6) - 202 herë,
Ultra (156.154.71.1) - 405 herë, Comodo Secure (8.26.56.26) - 435 herë, DNS.Watch (84.200.69.80) - 486 herë dhe Norton ConnectSafe (199.85.126.10 herë) Për serverët e bazuar në BIND 569, për shkak të paralelizimit të kërkesave, niveli i fitimit mund të arrijë deri në 9.12.3. Në Knot Resolver 1000, niveli i fitimit është afërsisht disa dhjetëra herë (5.1.0-24), që nga përcaktimi i Emrat NS kryhet në mënyrë sekuenciale dhe mbështetet në kufirin e brendshëm të numrit të hapave të zgjidhjes së emrave të lejuar për një kërkesë.
Ekzistojnë dy strategji kryesore të mbrojtjes. Për sistemet me DNSSEC
Burimi: opennet.ru