Webbläsaren Chromium, den blomstrande föräldern med öppen källkod till Google Chrome och nya Microsoft Edge, har fått betydande negativ uppmärksamhet för en funktion som var avsedd med goda avsikter: den kontrollerar om användarens internetleverantör "stjäl" obefintliga domänfrågeresultat .
, som skapar falska frågor för slumpmässiga "domäner" som är statistiskt osannolikt att existera, är ansvarig för ungefär hälften av den totala trafiken som tas emot av rot-DNS-servrar över hela världen. Verisigns ingenjör Matt Thomas skrev en lång på APNIC-bloggen som beskriver problemet och bedömer dess omfattning.
Hur DNS-upplösning vanligtvis utförs
Dessa servrar är den högsta myndigheten du bör kontakta för att lösa .com, .net, etc. så att de kommer att berätta att frglxrtmpuf inte är en toppdomän (TLD).
DNS, eller Domain Name System, är ett system genom vilket datorer kan lösa minnesvärda domännamn som arstechnica.com till mycket mindre användarvänliga IP-adresser som 3.128.236.93. Utan DNS skulle Internet inte existera på ett sätt som människor skulle kunna använda, vilket innebär att onödig belastning på infrastrukturen på översta nivån är ett verkligt problem.
Att ladda en enda modern webbsida kan kräva otroligt många DNS-uppslagningar. Till exempel, när vi analyserade ESPN:s hemsida, räknade vi 93 separata domännamn, allt från a.espncdn.com till z.motads.com. Alla är nödvändiga för att sidan ska laddas helt!
För att tillgodose denna typ av arbetsbelastning för en sökmotor som behöver tjäna hela världen, är DNS utformad som en hierarki på flera nivåer. Överst i denna pyramid finns rotservrarna - varje toppdomän, som .com, har sin egen familj av servrar som är den högsta auktoriteten för varje domän under dem. Ett steg upp dessa servrar är själva rotservrarna, från a.root-servers.net до m.root-servers.net.
Hur ofta händer detta?
Tack vare Caching-hierarkin på flera nivåer i DNS-infrastrukturen når en mycket liten andel av världens DNS-frågor rotservrarna. De flesta får sin DNS-resolverinformation direkt från sin internetleverantör. När en användares enhet behöver veta hur man kommer till en specifik webbplats skickas en förfrågan först till en DNS-server som hanteras av den lokala leverantören. Om den lokala DNS-servern inte vet svaret, vidarebefordrar den begäran till sina egna "vidarebefordrare" (om specificerat).
Om varken den lokala leverantörens DNS-server eller de "vidarebefordrande servrarna" som anges i dess konfiguration har ett cachat svar, skickas begäran direkt till den auktoritativa domänservern ovan den du försöker konvertera. När домен.com detta kommer att innebära att begäran skickas till domänens auktoritativa servrar com, som finns på gtld-servers.net.
System gtld-servers, som begäran gjordes på, svarar med en lista över auktoritativa namnservrar för domänen domain.com, samt minst en länkpost som innehåller IP-adressen för en sådan namnserver. Därefter rör sig svaren nedåt i kedjan - varje speditör skickar dessa svar ner till servern som begärde dem, tills svaret slutligen når den lokala leverantörens server och användarens dator. Alla av dem cachelagrar detta svar för att inte störa system på högre nivå i onödan.
I de flesta fall registrerar namnservern för domain.com kommer redan att cachelagras på en av dessa vidarebefordrare, så rotservrarna kommer inte att störas. Men för närvarande talar vi om den typ av webbadress vi känner till - den som konverteras till en vanlig webbplats. Chrome-förfrågningar är på nivå ovan detta, på steget av själva klustren root-servers.net.
Chromium och NXDomain stöldkontroll
Chromium kontrollerar "lurar den här DNS-servern mig?" står för nästan hälften av all trafik som når Verisigns kluster av rot-DNS-servrar.
Chromium-webbläsaren, moderprojektet till Google Chrome, nya Microsoft Edge och otaliga mindre kända webbläsare, vill ge användarna lättheten att söka i en enda ruta, ibland kallad "Omnibox". Med andra ord anger användaren både riktiga webbadresser och sökmotorfrågor i samma textfält högst upp i webbläsarfönstret. Ta ytterligare ett steg mot förenkling, det tvingar inte heller användaren att ange en del av webbadressen med http:// eller https://.
Hur bekvämt det än är, kräver detta tillvägagångssätt att webbläsaren förstår vad som ska betraktas som en URL och vad som ska betraktas som en sökfråga. I de flesta fall är detta ganska uppenbart - till exempel kan en sträng med mellanslag inte vara en URL. Men saker och ting kan bli svårare när du tänker på intranät – privata nätverk som också kan använda privata toppdomäner för att lösa riktiga webbplatser.
Om en användare på företagets intranät skriver "marknadsföring" och företagets intranät har en intern webbplats med samma namn, visar Chromium en informationsruta som frågar användaren om de vill söka efter "marknadsföring" eller gå till https://marketing. Detta kanske inte är fallet, men många internetleverantörer och offentliga Wi-Fi-leverantörer "kapar" alla felstavade webbadresser och omdirigerar användaren till någon sida med banner.
Slumpmässig generation
Chromium-utvecklarna ville inte att användare på vanliga nätverk skulle se en informationsruta som frågade vad de menade varje gång de sökte efter ett enda ord, så de implementerade ett test: När de startar en webbläsare eller byter nätverk, utför Chromium DNS-sökningar på tre slumpmässigt genererade "domäner" toppnivå, sju till femton tecken långa. Om två av dessa förfrågningar återkommer med samma IP-adress, antar Chromium att det lokala nätverket "kapar" felen NXDOMAIN, som den borde ta emot, så webbläsaren anser att alla enordsfrågor som anges är sökförsök tills vidare.
Tyvärr, i nätverk som ingen stjäl resultaten av DNS-frågor, dessa tre operationer stiger vanligtvis till toppen, hela vägen till själva rotnamnservrarna: den lokala servern vet inte hur den ska lösa qwajuixk, så vidarebefordrar denna begäran till sin speditör, som gör detsamma, tills slutligen a.root-servers.net eller så kommer en av hans "bröder" inte att tvingas säga "Förlåt, men det här är inte en domän."
Eftersom det finns ungefär 1,67*10^21 möjliga falska domännamn som sträcker sig från sju till femton tecken långa, är det vanligaste каждый från dessa tester som utförs på det "ärliga" nätverket kommer den till rotservern. Detta uppgår till lika mycket halv från den totala belastningen på rot-DNS, enligt statistik från den delen av klustren root-servers.net, som ägs av Verisign.
Historien upprepar sig
Det är inte första gången som ett projekt skapas med de bästa avsikterna eller nästan översvämmade en offentlig resurs med onödig trafik – detta påminde oss omedelbart om den långa och sorgliga historien om D-Link och Poul-Henning Kamps NTP-server (Network Time Protocol) i mitten av 2000-talet.
2005 fick FreeBSD-utvecklaren Poul-Henning, som också ägde Danmarks enda Stratum 1 Network Time Protocol-server, en oväntad och stor räkning för överförd trafik. Kort sagt var anledningen att D-Link-utvecklare skrev adresserna till Stratum 1 NTP-servrar, inklusive Kampa-servern, i firmwaren i företagets linje av switchar, routrar och accesspunkter. Detta ökade omedelbart Kampas servertrafik nio gånger, vilket fick den danska Internet Exchange (Danmarks Internet Exchange Point) att ändra sin tariff från "gratis" till "9 000 USD per år."
Problemet var inte att det fanns för många D-Link-routrar, utan att de var "utanför". Ungefär som DNS måste NTP fungera i hierarkisk form - Stratum 0-servrar skickar information till Stratum 1-servrar, som skickar information till Stratum 2-servrar, och så vidare ner i hierarkin. En typisk hemrouter, switch eller åtkomstpunkt som den D-Link hade programmerat med NTP-serveradresser skulle skicka förfrågningar till Stratum 2- eller Stratum 3-servern.
Chromium-projektet, förmodligen med de bästa avsikterna, replikerade NTP-problemet i DNS-problemet, laddade Internets rotservrar med förfrågningar som de aldrig var menade att hantera.
Det finns hopp om en snabb lösning
Chromium-projektet har en öppen källkod , vilket kräver att Intranet Redirect Detector inaktiveras som standard för att lösa det här problemet. Vi måste ge kredit till Chromium-projektet: buggen hittades före dethur Verisigns Matt Thomas gav honom mycket uppmärksamhet med sin på APNIC-bloggen. Felet upptäcktes i juni, men förblev bortglömt fram till Thomas inlägg; Efter fastan började han stå under noggrann övervakning.
Förhoppningen är att problemet snart ska lösas och rot-DNS-servrar kommer inte längre att behöva svara på de uppskattningsvis 60 miljarder falska frågorna varje dag.
Om reklamens rättigheter
Episka servrar - Är eller Linux med kraftfulla AMD EPYC-familjeprocessorer och mycket snabba Intel NVMe-enheter. Skynda dig att beställa!
Källa: will.com