En gruppe forskere fra Tel Aviv University og det tverrfaglige senteret i Herzliya (Israel)
Problemet er relatert til særegenhetene ved protokollen og påvirker alle DNS-servere som støtter rekursiv spørringsbehandling, inkludert
Angrepet er basert på at angriperen bruker forespørsler som refererer til et stort antall tidligere usett fiktive NS-poster, som navnebestemmelse er delegert til, men uten å spesifisere limposter med informasjon om IP-adressene til NS-servere i svaret. For eksempel sender en angriper en spørring for å løse navnet sd1.attacker.com ved å kontrollere DNS-serveren som er ansvarlig for attacker.com-domenet. Som svar på løserens forespørsel til angriperens DNS-server, utstedes et svar som delegerer bestemmelsen av sd1.attacker.com-adressen til offerets DNS-server ved å indikere NS-poster i svaret uten å spesifisere IP NS-serverne. Siden den nevnte NS-serveren ikke har blitt møtt før og dens IP-adresse ikke er spesifisert, prøver resolveren å bestemme IP-adressen til NS-serveren ved å sende en spørring til offerets DNS-server som betjener måldomenet (victim.com).
Problemet er at angriperen kan svare med en enorm liste over ikke-gjentakende NS-servere med ikke-eksisterende fiktive underdomenenavn for offer (fake-1.victim.com, fake-2.victim.com,... fake-1000. victim.com). Resolveren vil prøve å sende en forespørsel til offerets DNS-server, men vil motta et svar om at domenet ikke ble funnet, hvoretter den vil prøve å finne neste NS-server i listen, og så videre til den har prøvd alle NS-poster oppført av angriperen. Følgelig, for en angripers forespørsel, vil løseren sende et stort antall forespørsler for å bestemme NS-verter. Siden NS-servernavn genereres tilfeldig og refererer til ikke-eksisterende underdomener, hentes de ikke fra hurtigbufferen, og hver forespørsel fra angriperen resulterer i en mengde forespørsler til DNS-serveren som betjener offerets domene.
Forskere studerte graden av sårbarhet for offentlige DNS-løsere for problemet og slo fast at når du sender forespørsler til CloudFlare-resolveren (1.1.1.1), er det mulig å øke antall pakker (PAF, Packet Amplification Factor) med 48 ganger, Google (8.8.8.8) - 30 ganger, FreeDNS (37.235.1.174) - 50 ganger, OpenDNS (208.67.222.222) - 32 ganger. Mer merkbare indikatorer er observert for
Nivå 3 (209.244.0.3) - 273 ganger, Quad9 (9.9.9.9) - 415 ganger
SafeDNS (195.46.39.39) - 274 ganger, Verisign (64.6.64.6) - 202 ganger,
Ultra (156.154.71.1) - 405 ganger, Comodo Secure (8.26.56.26) - 435 ganger, DNS.Watch (84.200.69.80) - 486 ganger, og Norton ConnectSafe (199.85.126.10 ganger) - 569 ganger. For servere basert på BIND 9.12.3, på grunn av parallellisering av forespørsler, kan forsterkningsnivået nå opp til 1000. I Knot Resolver 5.1.0 er forsterkningsnivået omtrent flere titalls ganger (24-48), siden bestemmelsen av NS-navn utføres sekvensielt og hviler på den interne grensen for antall tillatte navneløsningstrinn for én forespørsel.
Det er to hovedforsvarsstrategier. For systemer med DNSSEC
Kilde: opennet.ru