🥇Een van de functies van Chromium belast de root DNS-servers enorm

De Chromium-browser, een actief ontwikkelende open-source-variant van Google Chrome en de nieuwe Microsoft Edge, heeft ernstige negatieve aandacht getrokken vanwege een functie die met goede bedoelingen is ontworpen: deze controleert of de provider van de gebruiker geen 'nepp' resultaten steelt van niet-bestaande domeinen.

Intranet Redirect Detector, die valse verzoeken genereert voor willekeurige 'domeinen' waarvan de statistische kans op bestaan zeer laag is, is verantwoordelijk voor ongeveer de helft van het totale verkeer dat wereldwijd wordt ontvangen door root DNS-servers. Engineer bij Verisign Matt Thomas schreef een uitgebreide bericht blogpost op APNIC over het probleem en evalueerde de omvang ervan.

Hoe DNS-omzetting normaal gesproken wordt uitgevoerd

Deze servers vormen de hoogste instantie waarmee men moet communiceren voor het resolveren van .com, .net enzovoort, om aan te geven dat frglxrtmpuf geen top-level domein (TLD) is.

DNS, of Domain Name System ('domeinnaamsysteem') — is het systeem dat computers in staat stelt om gemakkelijk te onthouden domeinnamen zoals arstechnica.com om te zetten in veel minder gebruiksvriendelijke IP-adressen, zoals 3.128.236.93. Zonder DNS zou het internet niet bestaan in een bruikbare vorm, wat betekent dat onnodige belasting van de bovenliggende infrastructuur een reëel probleem is.

Voor het laden van slechts één moderne webpagina kan er een ondenkbaar aantal DNS-opzoekingen nodig zijn. Bijvoorbeeld, toen we de homepage van ESPN analyseerden, tellen we 93 afzonderlijke domeinnamen, van a.espncdn.com tot z.motads.com. Al deze zijn nodig om de pagina volledig te laden!

Om deze belasting te kunnen dragen, is het systeem van opzoekingen, dat de hele wereld moet bedienen, ontworpen als een gelaagde hiërarchie. Aan de top van deze piramide staan de root-servers — elk top-level domein, zoals .com, heeft zijn eigen gezin van servers die de hoogste instantie zijn voor elk domein daaronder. Een niveau hoger van deze servers bevindt zich de root-servers zelf, van a.root-servers.net tot m.root-servers.net.

Hoe vaak gebeurt dit?

Dankzij de gelaagde cache-hiërarchie van de DNS-infrastructuur bereiken slechts een zeer klein percentage van de wereldwijde DNS-verzoeken de rootservers. De meeste mensen ontvangen informatie van de DNS-resolver rechtstreeks van hun provider. Wanneer een gebruikersapparaat moet ontdekken hoe het een specifieke website kan bereiken, wordt het verzoek eerst verzonden naar de DNS-server die door deze lokale provider wordt beheerd. Als de lokale DNS-server het antwoord niet weet, stuurt hij het verzoek door naar zijn eigen 'doorverwijsservers' (indien opgegeven).

Als noch de DNS-server van de lokale provider, noch de 'doorverwijsservers' die in zijn configuratie zijn ingesteld, een gecacheerd antwoord hebben, wordt het verzoek direct naar de autoritatieve server van het domein gestuurd boven dat u probeert om te zetten. In het geval van domein.com betekent dit dat het verzoek naar de autoritatieve servers van het domein zelf wordt gestuurd com, die zich bevinden op gtld-servers.net.

Systeem gtld-servers, waarop het verzoek is gericht, reageert met een lijst van autoritatieve naamservers voor het domein domein.com, evenals ten minste één glue-record met het IP-adres van zo'n naamserver. Vervolgens worden de antwoorden naar beneden verwezen — elke doorverwijsserver verzendt deze antwoorden naar de server die het opvroeg, totdat het antwoord uiteindelijk de server van de lokale provider en de computer van de gebruiker bereikt. Al deze servers cachen dit antwoord, zodat ze de hogere systemen niet hoeven te belasten.

In de meeste gevallen zijn de records van de naamservers voor domein.com al gecached op een van deze doorverwijsservers, zodat de rootservers niet worden belast. Maar vooralsnog hebben we het over de gebruikelijke vorm van een URL — die welke wordt omgezet in een reguliere website. De verzoeken van Chrome verwijzen naar het niveau boven van dit, op de niveau van de clusters zelf root-servers.net.

Chromium en NXDomain-kaping controle

De controles van Chromium 'bedriegt deze DNS-server me niet?' maken bijna de helft uit van al het verkeer dat de cluster van root DNS-servers van Verisign bereikt.

De Chromium-browser, het moederproject van Google Chrome, de nieuwe Microsoft Edge en talloze minder bekende browsers, wil gebruikers eenvoud bieden bij het zoeken in één veld, soms de "Omnibox" genoemd. Met andere woorden, de gebruiker voert zowel echte URL's als zoekopdrachten in hetzelfde tekstveld bovenaan het browservenster in. Om het nog eenvoudiger te maken, verplicht het de gebruiker ook niet om een deel van de URL in te voeren met http:// of https://.

Hoe handig het ook is, deze benadering vereist dat de browser begrijpt wat als URL moet worden beschouwd en wat als zoekopdracht. In de meeste gevallen is dit vrij duidelijk - bijvoorbeeld, een regel met spaties kan geen URL zijn. Maar het kan ingewikkelder worden als we intranetten in overweging nemen - privé-netwerken die ook privé-topleveldomeinen kunnen gebruiken voor het resolven van echte websites.

Als een gebruiker in het intranet van zijn of haar bedrijf "marketing" invoert en er is een interne website met dezelfde naam, toont Chromium een pop-upvenster waarin de gebruiker wordt gevraagd of hij of zij "marketing" wil zoeken of naar https://marketing. Dit is nog te doen, maar veel internetproviders en openbare Wi-Fi-netwerkproviders "stelen" elke ingevoerde URL met een typfout door de gebruiker om te leiden naar een of andere met advertenties volgestopte pagina.

Willekeurige generatie

De ontwikkelaars van Chromium wilden niet dat gebruikers in reguliere netwerken bij elke zoekopdracht naar één woord een pop-upvenster zagen waarin hen werd gevraagd wat ze bedoelden, daarom implementeerden ze een test: bij het opstarten van de browser of het wisselen van netwerk voert Chromium DNS-zoekopdrachten uit voor drie willekeurig gegenereerde "domeinen" van bovenste niveau met een lengte van zeven tot vijftien tekens. Als twee van deze verzoeken met hetzelfde IP-adres terugkomen, gaat Chromium ervan uit dat het lokale netwerk 'fouten steelt' NXDOMAIN, die het zou moeten ontvangen, waardoor de browser tot nader order alle ingevoerde zoekopdrachten van één woord beschouwt als zoekpogingen.

Helaas, in netwerken die niet de DNS-zoekresultaten stelen, komen deze drie operaties meestal bovenaan, tot aan de root-naamservers: de lokale server weet niet hoe qwajuixk, waardoor het verzoek naar zijn doorstuurserver wordt gestuurd, die hetzelfde doet totdat uiteindelijk, a.root-servers.net of een van zijn 'broertjes' gedwongen is te zeggen: 'Sorry, maar dit is geen domein.'

Aangezien er ongeveer 1,67*10^21 mogelijke valse domeinnamen zijn met een lengte van zeven tot vijftien karakters, komt het vaak voor dat elke van deze tests, uitgevoerd in een 'eerlijke' netwerk, de rootserver bereikt. Dit vertegenwoordigt maar liefst de helft van de totale belasting op de root DNS, als we de statistieken van dat deel van de clusters geloven root-servers.net, die eigendom zijn van het bedrijf Verisign.

Het verhaal herhaalt zich

Dit is niet de eerste keer dat een project, dat met de beste bedoelingen is opgericht, is mislukt of bijna een publieke resource heeft overspoeld met onnodig verkeer - het herinnerde ons onmiddellijk aan het lange en treurige verhaal van D-Link en de NTP-server (Network Time Protocol) van Poul-Henning Kamp midden jaren 2000.

In 2005 ontving de FreeBSD-ontwikkelaar Poul-Henning, die ook de enige Stratum 1 Network Time Protocol-server in Denemarken bezat, een onverwacht hoge rekening voor het verzonden verkeer. Kort samengevat, de reden was dat de ontwikkelaars van D-Link de adressen van Stratum 1 NTP-servers, inclusief de server van Kamp, in de firmware van hun schakelaars, routers en toegangspunten hadden opgenomen. Dit verhoogde onmiddellijk het verkeer van Kamp's server met negen keer, waardoor de Danish Internet Exchange (de internetverkeerswissel in Denemarken) zijn tarief wijzigde van 'Gratis' naar '9.000 dollar per jaar'.

Het probleem was niet dat er te veel D-Link routers waren, maar dat ze 'de hiërarchie verstoorden'. Bijna net als DNS moeten NTP-servers in een hiërarchische structuur werken - servers van niveau Stratum 0 geven informatie door aan Stratum 1-servers, die informatie doorgeven aan Stratum 2-servers, en zo verder, naar beneden in de hiërarchie. Gewone thuisrouters, switches of toegangspunten zoals de apparaten waarvan D-Link de adressen van NTP-servers heeft ingebakken, moeten verzoeken naar Stratum 2 of Stratum 3 servers sturen.

Het Chromium-project heeft, waarschijnlijk met de beste bedoelingen, het NTP-probleem herhaald in het DNS-probleem door rootservers van het internet te belasten met verzoeken die ze nooit hadden moeten verwerken.

Er is hoop op een snelle oplossing

In het Chromium-project is er een open bug, waarvoor het uitschakelen van de Intranet Redirect Detector standaard nodig is. We moeten het Chromium-project in het zonnetje zetten: de bug werd ontdekt voordat, Matt Thomas van Verisign veel aandacht op zich vestigde met zijn post op de APNIC-blog. De bug werd in juni gerapporteerd, maar bleef vergeten totdat Thomas zijn post deelde; na die post kreeg het weer de nodige aandacht.

Er is hoop dat het probleem snel zal worden opgelost, zodat de root DNS-servers niet langer dagelijks ongeveer 60 miljard valse verzoeken hoeven te verwerken.