De Chromium-browser, de bloeiende open-source-ouder van Google Chrome en het nieuwe Microsoft Edge, heeft aanzienlijke negatieve aandacht gekregen voor een functie die met goede bedoelingen was bedoeld: het controleert of de ISP van de gebruiker niet-bestaande domeinqueryresultaten "steelt". .
, dat valse zoekopdrachten creëert voor willekeurige "domeinen" waarvan het statistisch gezien onwaarschijnlijk is dat ze bestaan, is verantwoordelijk voor ongeveer de helft van het totale verkeer dat wereldwijd door root-DNS-servers wordt ontvangen. Verisign-ingenieur Matt Thomas schreef een lang verhaal op de APNIC-blog waarin het probleem wordt beschreven en de omvang ervan wordt beoordeeld.
Hoe DNS-omzetting gewoonlijk wordt uitgevoerd
Deze servers zijn de hoogste autoriteit waarmee u contact moet opnemen om .com, .net, enz. op te lossen, zodat zij u zullen vertellen dat frglxrtmpuf geen topniveaudomein (TLD) is.
DNS, of Domain Name System, is een systeem waarmee computers gedenkwaardige domeinnamen zoals arstechnica.com kunnen omzetten in veel minder gebruiksvriendelijke IP-adressen zoals 3.128.236.93. Zonder DNS zou het internet niet bestaan op een manier die mensen zouden kunnen gebruiken, wat betekent dat onnodige belasting van de infrastructuur op het hoogste niveau een reëel probleem is.
Het laden van een enkele moderne webpagina kan een ongelooflijk aantal DNS-lookups vereisen. Toen we bijvoorbeeld de startpagina van ESPN analyseerden, telden we 93 afzonderlijke domeinnamen, variërend van a.espncdn.com tot z.motads.com. Ze zijn allemaal nodig om de pagina volledig te laden!
Om dit soort werklast op te vangen voor een zoekmachine die de hele wereld moet bedienen, is de DNS ontworpen als een hiërarchie met meerdere niveaus. Bovenaan deze piramide staan de rootservers. Elk topniveaudomein, zoals .com, heeft zijn eigen familie van servers die de hoogste autoriteit hebben voor elk domein eronder. Eén stap omhoog van deze servers zijn de rootservers zelf, van a.root-servers.net naar m.root-servers.net.
Hoe vaak gebeurt dit?
Dankzij de cachinghiërarchie op meerdere niveaus van de DNS-infrastructuur bereikt een zeer klein percentage van de DNS-query's ter wereld de rootservers. De meeste mensen krijgen hun DNS-resolver-informatie rechtstreeks van hun ISP. Wanneer het apparaat van een gebruiker moet weten hoe hij op een specifieke website kan komen, wordt eerst een verzoek verzonden naar een DNS-server die wordt beheerd door die lokale provider. Als de lokale DNS-server het antwoord niet weet, stuurt hij het verzoek door naar zijn eigen “forwarders” (indien gespecificeerd).
Als noch de DNS-server van de lokale provider, noch de ‘doorstuurservers’ die in de configuratie zijn opgegeven, een in de cache opgeslagen antwoord hebben, wordt het verzoek rechtstreeks naar de gezaghebbende domeinserver gestuurd boven degene die u probeert te converteren. Wanneer домен.com dit betekent dat het verzoek naar de gezaghebbende servers van het domein zelf wordt verzonden com, die gevestigd zijn op gtld-servers.net.
Systeem gtld-servers, waarnaar het verzoek is gedaan, reageert met een lijst met gezaghebbende naamservers voor het domein domain.com, evenals ten minste één linkrecord met het IP-adres van een dergelijke naamserver. Vervolgens gaan de antwoorden verder in de keten: elke doorstuurder geeft deze antwoorden door aan de server die ze heeft opgevraagd, totdat het antwoord uiteindelijk de server van de lokale provider en de computer van de gebruiker bereikt. Ze slaan dit antwoord allemaal op in de cache om systemen op een hoger niveau niet onnodig te verstoren.
In de meeste gevallen worden naamserverrecords voor domein.com wordt al in de cache opgeslagen op een van deze forwarders, zodat de rootservers niet worden gestoord. Voor nu hebben we het echter over het type URL dat we kennen: degene die wordt omgezet in een gewone website. Chrome-verzoeken zijn op niveau boven dit op de trede van de clusters zelf root-servers.net.
Chromium- en NXDomain-diefstalcontrole
Chromium controleert of deze DNS-server mij voor de gek houdt? goed voor bijna de helft van al het verkeer dat de cluster van root-DNS-servers van Verisign bereikt.
De Chromium-browser, het moederproject van Google Chrome, het nieuwe Microsoft Edge en talloze minder bekende browsers, wil gebruikers het gemak bieden om in één enkel vak te zoeken, ook wel een 'Omnibox' genoemd. Met andere woorden, de gebruiker voert zowel echte URL's als zoekopdrachten van zoekmachines in hetzelfde tekstveld bovenaan het browservenster in. Het is een nieuwe stap in de richting van vereenvoudiging en dwingt de gebruiker ook niet om een deel van de URL in te voeren http:// of https://.
Hoe handig dit ook is, deze aanpak vereist dat de browser begrijpt wat als een URL moet worden beschouwd en wat als een zoekopdracht moet worden beschouwd. In de meeste gevallen is dit vrij duidelijk: een string met spaties kan bijvoorbeeld geen URL zijn. Maar het kan lastiger worden als je rekening houdt met intranetten: privénetwerken die ook privé-topniveaudomeinen kunnen gebruiken om echte websites op te lossen.
Als een gebruiker op het intranet van zijn bedrijf 'marketing' typt en het intranet van het bedrijf een interne website met dezelfde naam heeft, geeft Chromium een informatievak weer waarin de gebruiker wordt gevraagd of hij naar 'marketing' wil zoeken of naar https://marketing. Dit is misschien niet het geval, maar veel ISP's en openbare Wi-Fi-providers 'kapen' elke verkeerd gespelde URL, waardoor de gebruiker wordt omgeleid naar een met banners gevulde pagina.
Willekeurige generatie
De Chromium-ontwikkelaars wilden niet dat gebruikers op reguliere netwerken een informatievenster zouden zien waarin werd gevraagd wat ze bedoelden elke keer dat ze naar een enkel woord zochten, dus voerden ze een test uit: wanneer ze een browser starten of van netwerk wisselen, voert Chromium DNS-lookups uit op drie willekeurig gegenereerde "domeinen" op het hoogste niveau, zeven tot vijftien tekens lang. Als twee van deze verzoeken terugkomen met hetzelfde IP-adres, gaat Chromium ervan uit dat het lokale netwerk de fouten 'kaapt' NXDOMAIN, die hij zou moeten ontvangen, dus beschouwt de browser alle ingevoerde zoekopdrachten van één woord tot nader order als zoekpogingen.
Helaas is dat in netwerken het geval geen de resultaten van DNS-query's stelen, stijgen deze drie bewerkingen meestal helemaal bovenaan, helemaal tot aan de root-naamservers zelf: de lokale server weet niet hoe deze moet worden opgelost qwajuixk, stuurt dit verzoek dus door naar zijn expediteur, die hetzelfde doet, tot uiteindelijk a.root-servers.net of een van zijn ‘broers’ zal niet gedwongen worden om te zeggen: ‘Sorry, maar dit is geen domein.’
Aangezien er ongeveer 1,67*10^21 mogelijke valse domeinnamen zijn, variërend van zeven tot vijftien tekens, zijn de meest voorkomende elk van deze tests die op het “eerlijke” netwerk zijn uitgevoerd, komt het bij de rootserver. Dit komt neer op evenveel half van de totale belasting van de root-DNS, volgens statistieken van dat deel van de clusters root-servers.net, die eigendom zijn van Verisign.
De geschiedenis herhaalt zich
Dit is niet de eerste keer dat een project met de beste bedoelingen tot stand komt of bijna een openbare bron overspoelde met onnodig verkeer - dit deed ons onmiddellijk denken aan de lange en trieste geschiedenis van de NTP-server (Network Time Protocol) van D-Link en Poul-Henning Kamp halverwege de jaren 2000.
In 2005 ontving FreeBSD-ontwikkelaar Poul-Henning, die ook de enige Stratum 1 Network Time Protocol-server van Denemarken bezat, een onverwachte en hoge rekening voor verzonden verkeer. Kort gezegd was de reden dat D-Link-ontwikkelaars de adressen van Stratum 1 NTP-servers, inclusief de Kampa-server, in de firmware van de reeks switches, routers en toegangspunten van het bedrijf schreven. Hierdoor werd het serververkeer van Kampa onmiddellijk vertienvoudigd, waardoor de Deense Internet Exchange (het Deense Internet Exchange Point) zijn tarief veranderde van "Gratis" naar "$ 9 per jaar".
Het probleem was niet dat er te veel D-Link-routers waren, maar dat ze ‘uit de pas liepen’. Net als DNS moet NTP in een hiërarchische vorm werken: Stratum 0-servers geven informatie door aan Stratum 1-servers, die informatie doorgeven aan Stratum 2-servers, enzovoort in de hiërarchie. Een typische thuisrouter, switch of toegangspunt, zoals degene die D-Link had geprogrammeerd met NTP-serveradressen, zou verzoeken naar de Stratum 2- of Stratum 3-server sturen.
Het Chromium-project repliceerde, waarschijnlijk met de beste bedoelingen, het NTP-probleem in het DNS-probleem, waardoor de rootservers van het internet werden overladen met verzoeken die ze nooit hadden mogen afhandelen.
Er is hoop op een snelle oplossing
Het Chromium-project heeft een open source , waarvoor de Intranet Redirect Detector standaard moet worden uitgeschakeld om dit probleem op te lossen. We moeten het Chromium-project de eer geven: de bug is gevonden daarvoorhoe Matt Thomas van Verisign hem veel aandacht trok met zijn op de APNIC-blog. De bug werd in juni ontdekt, maar bleef in de vergetelheid tot de post van Thomas; Na het vasten begon hij onder streng toezicht te staan.
Er wordt gehoopt dat het probleem snel zal worden opgelost, en dat root-DNS-servers niet langer elke dag hoeven te reageren op de naar schatting 60 miljard nep-query's.
Als advertentie
Epische servers - Is of Linux met krachtige AMD EPYC-familieprocessors en zeer snelle Intel NVMe-schijven. Wees er snel bij om te bestellen!
Bron: www.habr.com