En av funktionerna i Chromium skapar en enorm belastning på de primära DNS-servrarna

Webbläsaren Chromium, som är en aktivt utvecklad open-source-version av Google Chrome och nya Microsoft Edge, har uppmärksammats för en funktion som ursprungligen var avsedd för gott: den kontrollerar om användarens leverantör "stjäl" ogiltiga sökresultat från domäner.

Intranet Redirect Detector, som skapar falska förfrågningar till slumpmässiga "domäner" vars existens statistiskt sett är osannolik, står för ungefär hälften av den totala trafik som tas emot av de rot-DNS-servrar som finns över hela världen. Ingenjör vid Verisign, Matt Thomas, skrev en utförlig inlägg post på APNIC-bloggen som beskriver problemet och bedömer dess omfattning.

Hur DNS-upplösning vanligtvis utförs

Dessa servrar är den högsta instansen som bör kontaktas för att lösa .com, .net och så vidare, för att informera er om att frglxrtmpuf inte är en toppdomän (TLD).

DNS, eller Domain Name System ("domännamnssystem"), är ett system som gör att datorer kan översätta minnesvärda domännamn som arstechnica.com till mycket mindre användarvänliga IP-adresser, såsom 3.128.236.93. Utan DNS skulle Internet inte kunna existera i en användarvänlig form, vilket innebär att onödig belastning på toppinfrastrukturen är ett verkligt problem.

För att ladda en enda modern webbsida kan en otrolig mängd DNS-sökningar krävas. Till exempel, när vi analyserade ESPN:s startsida, räknade vi 93 olika domännamn, från a.espncdn.com till z.motads.com. Alla dessa behövs för att fullständigt ladda sidan!

För att ett söksystem som måste betjäna hela världen ska kunna klara denna belastning, är DNS utformat som en flerlagershierarki. På toppen av denna pyramid finns rotservrarna – varje toppdomän, till exempel .com, har sin egen familj av servrar som är den högsta instansen för varje domän under dem. En nivå upp från dessa servrar är själva rotservrarna, från a.root-servers.net till m.root-servers.net.

Hur ofta händer detta?

Tack vare den flerstegs cachningshierarkin i DNS-infrastrukturen når endast en mycket liten procent av världens DNS-förfrågningar de primära rotservrarna. De flesta får DNS-informationen direkt från sin leverantör. När en användares enhet behöver ta reda på hur man når en specifik webbplats skickas förfrågan först till en DNS-server som hanteras av den lokala leverantören. Om den lokala DNS-servern inte har ett svar, vidarebefordrar den förfrågan till sina egna "vidarebefordringsservrar" (om sådana anges).

Om varken DNS-servern hos den lokala leverantören eller de vidarebefordringsservrar som anges i dess konfiguration har ett cachelagrat svar, höjs förfrågan direkt till den auktoritativa servern för domänen metoden. som du försöker omvandla. I så fall domen.com innebär detta att förfrågan skickas till de auktoritativa servrarna för själva domänen com, som finns på adressen gtld-servers.net.

Systemet gtld-servrar, som förfrågan gjordes till, svarar med en lista över auktoritativa namnservrar för domänen domen.com samt minst en bindande post som innehåller IP-adressen för en sådan namnserver. Sedan sänds svaren ner i kedjan — varje vidarebefordringsserver skickar dessa svar ner till den server som begärde dem, tills svaret äntligen når den lokala leverantörens server och användarens dator. Alla cachar detta svar för att inte behöva störa system på högre nivåer.

I de flesta fall kommer namnserverregistreringarna för domen.com redan att vara cacherade på en av dessa vidarebefordringsservrar, så rotservrarna störs inte. Men medan vi pratar om den typ av URL vi är vana vid — den som omvandlas till en vanlig webbplats. Förfrågningar från Chrome rör nivå metoden. detta, på steg av själva klusterna root-servers.net.

Chromium och NXDomain-hijackningskontroller

Kontrollerna i Chromium "lurar inte denna DNS-server mig?" utgör nästan hälften av all trafik som når klustret av rot-DNS-servrar från Verisign.

Webbläsaren Chromium, moderprojektet för Google Chrome, den nya Microsoft Edge och otaliga mindre kända webbläsare, vill ge användarna enkelhet i att söka i ett fält som ibland kallas "Omnibox". Med andra ord skriver användaren både verkliga URL:er och sökfraser i samma textfält högst upp i webbläsarfönstret. För att ytterligare förenkla processen kräver den inte att användaren skriver in en del av URL:en. http:// eller https://.

Hur praktiskt det än må vara, kräver denna metod att webbläsaren förstår vad som ska betraktas som en URL och vad som är en sökfråga. I de flesta fall är det ganska uppenbart; till exempel kan en sträng med mellanslag inte vara en URL. Men det kan bli mer komplicerat när intranät beaktas – privata nätverk som också kan använda privata toppdomäner för att lösa riktiga webbplatser.

Om en användare i företagets intranät skriver "marketing" och det finns en intern webbplats med samma namn, visar Chromium ett meddelande som frågar användaren om de vill söka på "marketing" eller gå till https://marketing. Det är okej, men många internetleverantörer och offentliga Wi-Fi-leverantörer "kapar" varje felstavad URL genom att omdirigera användaren till någon reklamfylld sida.

Slumptalsgenerering

Utvecklarna av Chromium ville inte att användare i vanliga nätverk skulle se ett meddelande som frågade vad de menade vid varje sökning av ett enda ord, så de implementerade ett test: när webbläsaren startas eller när nätverket ändras gör Chromium DNS-sökningar på tre slumpmässigt genererade toppdomäner som är mellan sju och femton tecken långa. Om några två av dessa förfrågningar returneras med samma IP-adress, antar Chromium att det lokala nätverket "kapar" felen. NXDOMAIN, som det bör ta emot, så webbläsaren antar utan vidare meddelande att alla inmatade förfrågningar av ett enda ord är sökförsök.

Tyvärr, i nätverk som inte kapar DNS-förfrågningar, lyfts dessa tre operationer vanligtvis högst upp, ända tills själva rotserverarna: den lokala servern vet inte hur den ska konvertera qwajuixk, därför vidarebefordrar den här begäran till sin omdirigeringsserver, som gör detsamma, tills till slut, a.root-servers.net eller en av dess "syskon" tvingas säga "Förlåt, men det är ingen domän".

Eftersom det finns ungefär 1,67*10^21 möjliga falska domännamn mellan sju och femton tecken, är det oftast varje av dessa tester, gjorda i ett "ärligt" nätverk, når rotservern. Det utgör faktiskt hälften av den totala belastningen på rot-DNS:en, om man ska tro statistiken från den del av klustren root-servers.net, som tillhör företaget Verisign.

Historien upprepar sig

Det är inte första gången som ett projekt skapat med de mest ädla avsikter misslyckas eller nästan misslyckas med att belasta en offentlig resurs med onödig trafik – det påminner oss om den långa och sorgliga historien om D-Link och NTP-servern (Network Time Protocol) Paul-Henning Camps under mitten av 2000-talet.

År 2005 fick FreeBSD-utvecklaren Poul-Henning, som också hade den enda NTP-servern Stratum 1 i Danmark, en överraskande och stor räkning för överförd trafik. I korthet berodde orsaken på att D-Link:s utvecklare hade hårdkodat adresser till NTP-servrar av Stratum 1, inklusive Camps server, i firmware för företagets switchar, routrar och åtkomstpunkter. Detta ökade omedelbart trafikmängden till Camps server med nio gånger, vilket ledde till att Danish Internet Exchange (Danmarks Internettrafikbyte) ändrade hans tarif från "Gratis" till "9 000 dollar per år".

Problemet var inte att det fanns för många D-Link-routrar, utan att de "bröt hierarkin". Precis som med DNS, måste NTP fungera i en hierarkisk struktur – servrar av Stratum 0 överför information till servrar av Stratum 1, som i sin tur överför information till servrar av Stratum 2, och så vidare ner i hierarkin. En vanlig hemrouter, switch eller åtkomstpunkt liknande de som D-Link hårdkodade adresser till NTP-servrar i, borde ha skickat förfrågningar till en server av Stratum 2 eller Stratum 3.

Projektet Chromium, med de mest ädla avsikter, upprepade NTP-problemet med DNS, genom att överbelasta Internets rotservrar med förfrågningar som de aldrig skulle ha hanterat.

Det finns hopp om en snabb lösning

I projektet Chromium finns det en öppen bugg, som kräver att Intranet Redirect Detector stängs av som standard för att lösa detta problem. Man måste ge projektet Chromium erkännande: buggen upptäcktes innan, som Matt Thomas från Verisign drog stort fokus på med sin ett inlägg på APNIC:s blogg. Buggen rapporterades i juni, men förblev bortglömd fram till Thomas inlägg; efter inlägget började den få noggrant uppsyn.

Det finns hopp om att problemet snart kommer att lösas, så att de primära DNS-servrarna inte längre behöver svara på cirka 60 miljarder falska förfrågningar varje dag.

I reklamens namn

Episk server — detta är VPS med Windows eller Linux med kraftfulla processorer från AMD EPYC och mycket snabba NVMe-diskar från Intel. Skynda dig att beställa!

Källa: habr.com