En gruppe forskere fra Tel Aviv University og det tværfaglige center i Herzliya (Israel)
Problemet er relateret til protokollens særegenheder og påvirker alle DNS-servere, der understøtter rekursiv forespørgselsbehandling, herunder
Angrebet er baseret på, at angriberen bruger anmodninger, der refererer til et stort antal hidtil usete fiktive NS-poster, hvortil navnebestemmelse er delegeret, men uden at specificere limrecords med information om IP-adresserne på NS-servere i svaret. For eksempel sender en angriber en forespørgsel for at løse navnet sd1.attacker.com ved at kontrollere den DNS-server, der er ansvarlig for domænet attacker.com. Som svar på resolverens anmodning til angriberens DNS-server udsendes et svar, der delegerer bestemmelsen af sd1.attacker.com-adressen til offerets DNS-server ved at angive NS-poster i svaret uden at angive IP NS-serverne. Da den nævnte NS-server ikke er stødt på før, og dens IP-adresse ikke er angivet, forsøger resolveren at bestemme IP-adressen på NS-serveren ved at sende en forespørgsel til offerets DNS-server, der betjener måldomænet (victim.com).
Problemet er, at angriberen kan reagere med en enorm liste over ikke-gentagende NS-servere med ikke-eksisterende fiktive underdomænenavne for offer (fake-1.victim.com, fake-2.victim.com,... fake-1000. victim.com). Resolveren vil forsøge at sende en anmodning til offerets DNS-server, men vil modtage et svar om, at domænet ikke blev fundet, hvorefter den vil forsøge at bestemme den næste NS-server på listen, og så videre, indtil den har prøvet alle de NS-poster opført af angriberen. Følgelig vil resolveren for én angribers anmodning sende et stort antal anmodninger for at bestemme NS-værter. Da NS-servernavne genereres tilfældigt og refererer til ikke-eksisterende underdomæner, hentes de ikke fra cachen, og hver anmodning fra angriberen resulterer i en byge af anmodninger til DNS-serveren, der betjener offerets domæne.
Forskere undersøgte graden af offentlige DNS-resolveres sårbarhed over for problemet og fastslog, at når man sender forespørgsler til CloudFlare-resolveren (1.1.1.1), er det muligt at øge antallet af pakker (PAF, Packet Amplification Factor) med 48 gange, Google (8.8.8.8) - 30 gange, FreeDNS (37.235.1.174) - 50 gange, OpenDNS (208.67.222.222) - 32 gange. Mere mærkbare indikatorer observeres for
Level3 (209.244.0.3) - 273 gange, Quad9 (9.9.9.9) - 415 gange
SafeDNS (195.46.39.39) - 274 gange, Verisign (64.6.64.6) - 202 gange,
Ultra (156.154.71.1) - 405 gange, Comodo Secure (8.26.56.26) - 435 gange, DNS.Watch (84.200.69.80) - 486 gange, og Norton ConnectSafe (199.85.126.10 gange) - 569 gange. For servere baseret på BIND 9.12.3 kan forstærkningsniveauet på grund af parallelisering af anmodninger nå op til 1000. I Knot Resolver 5.1.0 er forstærkningsniveauet cirka flere titusinder (24-48), da bestemmelsen af NS-navne udføres sekventielt og hviler på den interne grænse for antallet af navneopløsningstrin, der er tilladt for en anmodning.
Der er to hovedforsvarsstrategier. Til systemer med DNSSEC
Kilde: opennet.ru