🥇En af funktionerne i Chromium skaber en enorm belastning på de primære DNS-servere

Chromium-browser, som aktivt udvikles som open-source-variant af Google Chrome og den nye Microsoft Edge, har tiltrukket sig alvorlig negativ opmærksomhed på grund af en funktion, der var tænkt med de bedste intentioner: den kontrollerer, om din udbyder "stjæler" ikke-eksisterende forespørgsler fra domæner.

Intranet Redirect Detector, der genererer falske forespørgsler for tilfældige „domæner“, hvis eksistens statistisk set er usandsynlig, står for cirka halvdelen af den samlede trafik modtages af rotdns-servere verden over. Ingeniør hos Verisign, Matt Thomas, har skrevet en udførlig post blogindlæg på APNIC, der beskriver problemet og vurderer dens omfang.

Hvordan DNS-omdannelse normalt udføres

Disse servere er den øverste instans, man skal kontakte for at opløse .com, .net og så videre, så de kan fortælle dig, at frglxrtmpuf ikke er et topdomæne (TLD).

DNS, eller Domain Name System ("system for domænenavne"), er et system, som gør det muligt for computere at omdanne mindeværdige domænenavne som arstechnica.com til langt mindre brugervenlige IP-adresser som 3.128.236.93. Uden DNS ville internettet ikke kunne eksistere i en menneskelig tilgængelig form, hvilket gør unødvendig belastning på topinfrastruktur til en reel problematik.

Det kan kræve en ubegribelig mængde DNS-søgeoperationer for at indlæse en enkelt moderne webside. For eksempel, da vi analyserede ESPN's forside, tællede vi 93 separate domænenavne, fra a.espncdn.com til z.motads.com. Alle er nødvendige for at indlæse siden fuldt ud!

For at sådan en belastning kan håndteres af et søgesystem, der skal betjene hele verden, er DNS designet som en multilags-hierarki. Øverst i denne pyramide er roden servere – hver topdomæne, som .com, har sin egen familie af servere, der er den øverste instans for hvert domæne nedenfor dem. Et niveau højere disse servere er selve roden servere, fra a.root-servers.net op til m.root-servers.net.

Hvor ofte sker dette?

Takket være den mange lag af cache-hierarkiet i DNS-infrastrukturen når en meget lille procent af verdens DNS-forespørgsler de rodservere. De fleste mennesker får DNS-oplysninger direkte fra deres udbyder. Når en brugers enhed skal finde ud af, hvordan man kommer til en bestemt hjemmeside, sendes forespørgslen først til en DNS-server, der styres af denne lokale udbyder. Hvis den lokale DNS-server ikke har svaret, videresender den forespørgslen til sine egne "videresendingsservere" (hvis de er angivet).

Hvis hverken DNS-serveren hos den lokale udbyder eller de angivne "videresendingsservere" har et cachelagret svar, bliver forespørgslen sendt direkte til den autoritative domæneserver. over den, du forsøger at konvertere. I tilfælde af domæne.com betyder det, at forespørgslen sendes til den autoritative server for selve domænet. com, som findes på adressen gtld-servers.net.

System gtld-servers, som blev spurgt, svarer med en liste over autoritative navneservere for domænet domæne.com, samt mindst én bindende post, der indeholder IP-adressen til en sådan navneserver. Derefter sendes svarene ned ad kæden — hver videresendingsserver sender disse svar ned til den server, der anmodede om dem, indtil svaret endelig når den lokale udbyders server og brugerens computer. Alle cacher dette svar, så de ikke behøver at belaste systemerne på højere niveau.

I de fleste tilfælde vil optegnelserne fra navneservere for domæne.com allerede være cachelagret på en af disse videresendingsservere, så rodserverne bliver ikke generet. Men så længe vi taler om den sædvanlige type URL — den, der konverteres til en almindelig hjemmeside. Forespørgsler i Chrome henviser til niveauet over dette, på selve klyngens trin root-servers.net.

Chromium og NXDomain hijack-tjek

Chromiums tjek "Lurer denne DNS-server mig?" udgør næsten halvdelen af al trafik, der når klyngen af rod DNS-servere hos Verisign.

Webbrowseren Chromium, der er moderprojektet til Google Chrome, den nye Microsoft Edge og utallige andre mindre kendte browsere, ønsker at give brugerne en enkel søgning i ét felt, nogle gange kaldet "Omnibox". Med andre ord indtaster brugeren både rigtige URL'er og søgeforespørgsler i det samme tekstfelt i toppen af browservinduet. Ved at tage et yderligere skridt mod forenkling, tvinger det heller ikke brugeren til at indtaste dele af URL'en med http:// eller https://.

Så bekvemt som dette er, kræver denne tilgang, at browseren forstår, hvad der skal betragtes som en URL, og hvad der er en søgeforespørgsel. I de fleste tilfælde er det ret tydeligt - for eksempel kan en streng med mellemrum ikke være en URL. Men det kan blive mere kompliceret, når intranet tages i betragtning - private netværk, der også kan bruge private topdomæner til at opløse rigtige websteder.

Hvis en bruger på virksomhedens intranet indtaster "marketing", og der på virksomhedens intranet findes en intern hjemmeside med samme navn, viser Chromium en dialogboks, der spørger brugeren, om de vil søge efter "marketing" eller gå til https://marketing. Det er acceptabelt, men mange internetudbydere og udbydere af offentlige Wi-Fi-netværk "kaprer" hver indtastet stavefejl i URL'er ved at omdirigere brugeren til en eller anden bannerfyldt reklameside.

Tilfældig generering

Udviklerne af Chromium ønskede ikke, at brugere på almindelige netværk skulle se en dialogboks, der spørger, hvad de mente, hver gang de søgte på ét ord, så de implementerede en test: når browseren startes eller netværket skiftes, udfører Chromium DNS-opslag på tre tilfældigt genererede "domæner" på toppen, der spænder fra syv til femten tegn. Hvis nogen to af disse forespørgsler returneres med den samme IP-adresse, antager Chromium, at det lokale netværk "kaprer" fejlene NXDOMAIN, som det burde modtage, så betragter browseren indtil videre alle indtastede enkeltord forespørgsler som søgninger.

Desværre, i netværk, der ikke kaprer DNS-forespørgsler, bliver disse tre operationer normalt sendt helt op til roden af navneserverne: den lokale server ved ikke, hvordan man konverterer qwajuixk, derfor videresender den denne anmodning til sin videresendingsserver, som gør det samme, indtil endelig, a.root-servers.net eller en af dens "brødre" tvinges til at sige "Undskyld, men det er ikke et domæne."

Da der findes cirka 1,67*10^21 mulige falske domænenavne med en længde på mellem syv og femten tegn, er det oftest hver af disse tests, udført i et "ærlig" netværk, når frem til den rodserver. Det udgør hele halvdelen af den samlede belastning på roden DNS, hvis man skal tro statistikkerne fra den del af klyngerne root-servers.net, som tilhører Verisign.

Historien gentager sig

Det er ikke første gang, at et projekt oprettet med de bedste intentioner har belastet eller næsten belastet en offentlig ressource med unødvendig trafik — det minder os straks om den lange og sørgelige historie om D-Link og NTP-serveren (Network Time Protocol) Paul-Henning Kamps fra midten af 2000'erne.

I 2005 modtog udvikleren af FreeBSD Paul-Henning, som også havde den eneste Stratum 1 NTP-server i Danmark, en uventet og stor regning for den overførte trafik. Kort sagt, årsagen var, at D-Link-udviklerne indskrev adresserne til Stratum 1 NTP-servere, herunder Kamps server, i firmabets firmware til en række switches, routere og adgangspunkt. Det forøgede straks trafikken på Kamps server ni gange, hvilket fik Danish Internet Exchange (Danmarks internettrafikudvekslingspunkt) til at ændre hans takst fra "Gratis" til "9.000 dollars om året."

Problemet lå ikke i, at der var for mange D-Link-routere, men i, at de "brød hierarkiet". Cirkus som DNS, skal NTP arbejde i en hierarkisk struktur — Stratum 0-servere videresender information til Stratum 1-servere, som videresender information til Stratum 2-servere, og så videre ned ad hierarkiet. En almindelig hjemme-router, switch eller adgangspunkt som dem, D-Link har indskrevet adresserne til NTP-servere i, burde have sendt forespørgsler til en Stratum 2 eller Stratum 3-server.

Chromium-projektet, formodentlig med de bedste intentioner, gentog problemet med NTP i DNS-problemet, ved at overbelaste de rodservere for internettet med forespørgsler, som de aldrig burde have behandlet.

Der er håb om en hurtig løsning

Der er en åben fejl i projektet Chromium, der kræver at deaktivere Intranet Redirect Detector som standard for at løse dette problem. Man må give kredit til Chromium-projektet: fejlen blev fundet før, som Matt Thomas fra Verisign trak enorm opmærksomhed til med sin post på APNIC-bloggen. Fejlen blev rapporteret i juni, men forblev i glemsel indtil Thomas' indlæg; efter indlægget begyndte den at være under nøje overvågning.

Der er håb om, at problemet snart vil blive løst, og at de primære DNS-servere ikke længere skal svare på omkring 60 milliarder falske forespørgsler dagligt.