Chromium-browseren, den blomstrende open source-forælder til Google Chrome og den nye Microsoft Edge, har fået betydelig negativ opmærksomhed for en funktion, der var tiltænkt med gode hensigter: den tjekker, om brugerens internetudbyder "stjæler" ikke-eksisterende domæneforespørgselsresultater .
, som skaber falske forespørgsler for tilfældige "domæner", der statistisk usandsynligt eksisterer, er ansvarlig for cirka halvdelen af den samlede trafik modtaget af root-DNS-servere på verdensplan. Verisign-ingeniør Matt Thomas skrev en lang på APNIC-bloggen, der beskriver problemet og vurderer dets omfang.
Hvordan DNS-opløsning normalt udføres
Disse servere er den højeste autoritet, du bør kontakte for at løse .com, .net osv., så de vil fortælle dig, at frglxrtmpuf ikke er et top-level domæne (TLD).
DNS, eller Domain Name System, er et system, hvormed computere kan opløse mindeværdige domænenavne som arstechnica.com til meget mindre brugervenlige IP-adresser som 3.128.236.93. Uden DNS ville internettet ikke eksistere på en måde, som mennesker kunne bruge, hvilket betyder, at unødvendig belastning af infrastrukturen på øverste niveau er et reelt problem.
At indlæse en enkelt moderne webside kan kræve utroligt mange DNS-opslag. For eksempel, da vi analyserede ESPN's hjemmeside, talte vi 93 separate domænenavne, lige fra a.espncdn.com til z.motads.com. Alle er nødvendige for at siden kan indlæses fuldt ud!
For at imødekomme denne type arbejdsbyrde for en søgemaskine, der skal tjene hele verden, er DNS designet som et multi-level hierarki. Øverst i denne pyramide er rodserverne - hvert domæne på topniveau, såsom .com, har sin egen familie af servere, der er den højeste autoritet for hvert domæne under dem. Et skridt op Disse servere er selve rodserverne fra a.root-servers.net til m.root-servers.net.
Hvor ofte sker dette?
Takket være Caching-hierarkiet på flere niveauer i DNS-infrastrukturen når en meget lille procentdel af verdens DNS-forespørgsler til rodserverne. De fleste mennesker får deres DNS-resolveroplysninger direkte fra deres internetudbyder. Når en brugers enhed skal vide, hvordan man kommer til et bestemt websted, sendes en anmodning først til en DNS-server, der administreres af den lokale udbyder. Hvis den lokale DNS-server ikke kender svaret, videresender den anmodningen til sine egne "viderestillere" (hvis angivet).
Hvis hverken den lokale udbyders DNS-server eller de "videresendelsesservere", der er angivet i dens konfiguration, har et cache-svar, sendes anmodningen direkte til den autoritative domæneserver ovenfor den du forsøger at konvertere. Hvornår домен.com dette vil betyde, at anmodningen sendes til de autoritative servere på selve domænet com, som er placeret kl gtld-servers.net.
System gtld-servers, som anmodningen blev foretaget på, svarer med en liste over autoritative navneservere for domænet domain.com, samt mindst én linkpost, der indeholder IP-adressen på en sådan navneserver. Dernæst bevæger svarene sig ned i kæden - hver videresender sender disse svar ned til den server, der anmodede om dem, indtil svaret endelig når frem til den lokale udbyders server og brugerens computer. Alle af dem cache dette svar for ikke at forstyrre systemer på højere niveau unødigt.
I de fleste tilfælde registrerer navneserveren for domæne.com vil allerede være cachelagret på en af disse videresender, så rodserverne vil ikke blive forstyrret. Men indtil videre taler vi om den type URL, vi kender - den, der er konverteret til en almindelig hjemmeside. Chrome-anmodninger er på niveau ovenfor dette på trappen af selve klyngerne root-servers.net.
Chromium og NXDomain tyverikontrol
Chromium tjekker "narre denne DNS-server mig?" står for næsten halvdelen af al trafik, der når Verisigns klynge af rod-DNS-servere.
Chromium-browseren, Google Chromes moderprojekt, den nye Microsoft Edge og utallige mindre kendte browsere, ønsker at give brugerne letheden ved at søge i en enkelt boks, nogle gange kaldet en "Omnibox". Med andre ord indtaster brugeren både rigtige URL'er og søgemaskineforespørgsler i det samme tekstfelt øverst i browservinduet. Ved at tage endnu et skridt mod forenkling, tvinger det heller ikke brugeren til at indtaste en del af URL'en med http:// eller https://.
Hvor praktisk dette end er, kræver denne tilgang, at browseren forstår, hvad der skal betragtes som en URL, og hvad der skal betragtes som en søgeforespørgsel. I de fleste tilfælde er dette ret indlysende - for eksempel kan en streng med mellemrum ikke være en URL. Men tingene kan blive sværere, når du overvejer intranet – private netværk, der også kan bruge private topdomæner til at løse rigtige websteder.
Hvis en bruger på deres virksomheds intranet skriver "marketing", og virksomhedens intranet har en intern hjemmeside med samme navn, så viser Chromium en informationsboks, der spørger brugeren, om de vil søge efter "marketing" eller gå til https://marketing. Dette er muligvis ikke tilfældet, men mange internetudbydere og offentlige Wi-Fi-udbydere "kaprer" enhver forkert stavet URL og omdirigerer brugeren til en side fyldt med banner.
Tilfældig generation
Chromium-udviklerne ønskede ikke, at brugere på almindelige netværk skulle se en informationsboks, der spørger, hvad de mente, hver gang de søgte efter et enkelt ord, så de implementerede en test: Når de starter en browser eller skifter netværk, udfører Chromium DNS-opslag på tre tilfældigt genererede "domæner" på øverste niveau, syv til femten tegn lange. Hvis to af disse anmodninger returnerer med den samme IP-adresse, antager Chromium, at det lokale netværk "kaprer" fejlene NXDOMAIN, som den skal modtage, så browseren betragter alle indtastede enkeltordsforespørgsler som søgeforsøg indtil videre.
Desværre i netværk, at nej stjæler resultaterne af DNS-forespørgsler, disse tre operationer stiger normalt til toppen, helt til selve rodnavneserverne: den lokale server ved ikke, hvordan den skal løses qwajuixk, så videresender denne anmodning til sin speditør, som gør det samme, indtil endelig a.root-servers.net eller en af hans "brødre" vil ikke blive tvunget til at sige "Undskyld, men dette er ikke et domæne."
Da der er ca. 1,67*10^21 mulige falske domænenavne med en længde fra syv til femten tegn, er den mest almindelige hver fra disse test udført på det "ærlige" netværk, kommer det til rodserveren. Dette svarer til lige så meget halvt af den samlede belastning på root-DNS, ifølge statistik fra den del af klyngerne root-servers.net, som ejes af Verisign.
Historien gentager sig
Det er ikke første gang, at et projekt er skabt med de bedste intentioner eller nærmest oversvømmede en offentlig ressource med unødvendig trafik - dette mindede os straks om den lange og triste historie om D-Link og Poul-Henning Kamps NTP-server (Network Time Protocol) i midten af 2000'erne.
I 2005 modtog FreeBSD-udvikler Poul-Henning, som også ejede Danmarks eneste Stratum 1 Network Time Protocol-server, en uventet og stor regning for transmitteret trafik. Kort sagt var årsagen, at D-Link-udviklere skrev adresserne på Stratum 1 NTP-servere, inklusive Kampa-serveren, ind i firmwaren på virksomhedens linje af switches, routere og adgangspunkter. Dette øgede øjeblikkeligt Kampas servertrafik ni gange, hvilket fik Dansk Internet Exchange (Danmarks Internet Exchange Point) til at ændre sin takst fra "Gratis" til "$9 pr. år."
Problemet var ikke, at der var for mange D-Link-routere, men at de var "ude af linje." Ligesom DNS skal NTP fungere i en hierarkisk form - Stratum 0-servere videregiver information til Stratum 1-servere, som videregiver information til Stratum 2-servere og så videre ned i hierarkiet. En typisk hjemmerouter, switch eller adgangspunkt som det D-Link havde programmeret med NTP-serveradresser ville sende anmodninger til Stratum 2- eller Stratum 3-serveren.
Chromium-projektet, sandsynligvis med de bedste intentioner, replikerede NTP-problemet i DNS-problemet, idet det indlæste internettets rodservere med anmodninger, de aldrig var beregnet til at håndtere.
Der er håb om en hurtig løsning
Chromium-projektet har en open source , hvilket kræver, at Intranet Redirect Detector som standard deaktiveres for at løse dette problem. Vi må give kredit til Chromium-projektet: fejlen blev fundet inden dahvordan Verisigns Matt Thomas bragte ham meget opmærksomhed med sin på APNIC-bloggen. Fejlen blev opdaget i juni, men forblev glemt indtil Thomas' indlæg; Efter faste begyndte han at være under nøje opsyn.
Det er håbet, at problemet snart vil blive løst, og root DNS-servere vil ikke længere skulle svare på de anslåede 60 milliarder falske forespørgsler hver dag.
Om reklamernes rettigheder
Episke servere - Er eller Linux med kraftfulde AMD EPYC-familieprocessorer og meget hurtige Intel NVMe-drev. Skynd dig at bestille!
Kilde: www.habr.com