Chromium-functie tegen dns-hijacking zorgt voor hoge belasting van root-servers

Een functie in de Chromium-browser zorgt voor problemen met de root-dns-servers door een grote hoeveelheid queries te doen. Ruim de helft van alle dns-queries is inmiddels afkomstig van browsers op basis van Chromium, en dat levert volgens experts problemen op.

Het probleem zit in de Intranet Redirect Detector. Die functie wordt onder andere gebruikt in de 'omnibox' in Chromium, de zoekbalk waar zowel https-websites als zoektermen kunnen worden ingevoerd. De browser weet daarbij niet of er een url of een zoekterm of een intranet-link moet worden geladen. Als veiligheidsmaatregel heeft Chromium de IRD-functie om dns-hijacking door bijvoorbeeld providers te voorkomen. Isp's zouden bijvoorbeeld een ongeldige zoekterm naar een niet-bestaande intranetpagina kunnen doorverwijzen naar een eigen webpagina. De Intranet Redirect Detector doet daarom als test een dns-verzoek voor drie willekeurig gegenereerde domeinnamen. Als van twee van die domeinen hetzelfde ip-adres terugkomt ziet Chromium dat als een dns-hijacking en wordt de ingegeven term als een zoekterm behandeld.

Daar zit een probleem, redeneert Matthew Thomas van Verisign in een veelgedeelde blogpost. De IRD-test wordt iedere keer uitgevoerd als Chromium wordt opgestart of als een apparaat van ip- of dns-instellingen wijzigt. De willekeurige domeinnamen die Chromium genereert voor die test bestaan in de meeste gevallen niet echt, en worden daarom niet door de meeste resolvers gedetecteerd. In plaats daarvan worden ze helemaal omgeleid naar de root-dns-servers, zegt Thomas, en dat gebeurt vaak.

Thomas stelt dat de helft van al het bezoek aan de dns-root-servers inmiddels 'hoogstwaarschijnlijk door Chromium-verzoeken' wordt gedaan. "Dat betekent dat er gemiddeld zo'n zestig miljard queries per dag naar de rootservers worden gestuurd." Thomas zegt niet of de rootservers dat wel of niet aankunnen en schetst ook geen probleemscenario's. De checks die Chromium-browsers doen zouden 'de uitzondering in plaats van de norm moeten zijn', zegt hij. "In ieder ander scenario zou dergelijk verkeer als ddos-aanval worden aangemerkt", schrijft hij.

Er is al langere tijd een issue in het Chromium-project dat voorstelt de IRD stop te zetten. Dat issue werd al geopend voordat Thomas zijn blogpost schreef, maar sindsdien zijn er wel steeds meer reacties op gekomen. In het issue lijken veel ontwikkelaars ervoor te zijn IRD niet standaard meer in te schakelen. De functie zelf bestaat al sinds 2010.

Reacties (25)

[RoestVrijStaal]

Het zoekveld en adresveld combineren was altijd al een slecht idee geweest.

Maar ja, de gros van de internetgebruikers weten niet eens wat een URL is en beschouwen als hun browser als "Het internet"

Sowieso snap ik niet waarom Chromium niet de middelvinger geeft op requests met URLs met een HTTP(S)-URI die geen tld in hun host-gedeelte hebben. Code-wise een URL valideren zou niet moeilijk moeten zijn voor de developers daar.

Daarom snap ik ook de keuze van Google niet om met URLs zoals http://rociwefoie/, http://uawfkfrefre/ and http://awoimveroi/ (van het artikel van Matthew Thomas) te proben ipv http://<random-getal>.doesntexist.google.com.

[LEDfan]

Daarom snap ik ook de keuze van Google niet om met URLs zoals http://rociwefoie/, http://uawfkfrefre/ and http://awoimveroi/ (van het artikel van Matthew Thomas) te proben ipv http://<random-getal>.doesntexist.google.com.

Ik vermoed dat Google schrik heeft dat dit te voorspelbaar is en daarom makkelijk omzeilt kan worden. Dus een ISP die perse DNS-hijacking wilt doen, kan dan een special rule in zijn servers maken om <random-getal>.doesntexist.google.com niet te laten resolven (in tegenstelling tot elk ander random domein). Waarom een ISP dit zou doen...

Sowieso snap ik niet waarom Chromium niet de middelvinger geeft op requests met URLs met een HTTP(S)-URI die geen tld in hun host-gedeelte hebben. Code-wise een URL valideren zou niet moeilijk moeten zijn voor de developers daar.

Ik ook niet echt. Als je in firefox naar de site "marketing" wilt gaan, moet je expliciet "http://marketing" intypen. Voor intranets lijkt mij dit totaal geen probleem eigenlijk. Ik denk dat veel intranets sowieso onder een subdomein vallen (die dan eventueel enkel lokaal wordt geresolved) en meestal hebben bedrijven toch een "go.bedrijf.tld" site met allerlei links. Eens je op zo'n site bent geweest, vult firefox die gewoon aan.

[Jochem]

Ik ken geen bedrijf dat een https://go.bedrijf.tld pagina heeft met links. Overigens wel een aardig idee om dit op een intranet (confluence of dat ene ms product) te laten landen.

[EraYaN]

En ik ben persoonlijk dan nog van mening dat het intranet gewoon volledige URLs zou moeten gebruiken. Die moeten hooguit op kantoor een ander IP adres teruggeven.

[djwice]

veel bedrijven gebruiken zulke domeinen als interne domeinnamen voor intranet en applicaties (jep, waarom niet gewoon een sub-domein van een tld die je zelf bezig? - geen idee) - dus voor op interne netwerken zijn ze helaas genoodzaakt zulke dingen te accepteren als geldig.

[Reactie gewijzigd door djwice op 23 juli 2024 10:35]

[mocean]

Het is niet 'te accepteren als geldig', maar volgens de standaard gewoon geldig.

[nightgold]

Als ze zouden checken op het bestaan van een .tld dan is er veel die niet meer zal werken.
Niet alles gebruikt nameservers, er zijn nog steeds genoeg ip:host adressen in omloop.
Het eerste die in me opkomt is http://fiddler:8888 en dit is publiek. Maar ook tussen ontwikkelaars die iets hosten via ip:host

[latka]

Ik draai een eigen DNS met een eigen TLD thuis. Best lastig voor Google om dat uit te vinden. En http://bla.bla.google.com zal altijd naar de DNS van Google gaan. Dat zal een ISP niet voorzien van een reclame pagina.

[Kenhas]

Dat betekent dat er gemiddeld zo'n zestig miljard queries naar de rootservers worden gestuurd.

Per dag, per uur, per minuut, ... ??

Dus het probleem is dat Chrome domeinnamen genereert die niet bestaan, om te kijken of ze worden omgeleid naar een andere, wel bestaande web pagina. Vraag me beetje af waarom dat moet bekeken worden iedere keer als Chromium opstart.
Is het dan zo moeilijk om uit te maken wat er in de adresbalk wordt ingegeven? Als alle checks mislukken, in de laatste stap vragen bij de dns-root-servers.
Is dan toch ook al een probleem dat al jaren bestaat. Is toch al enkele jaren dat je een zoekterm kan invullen in de adresbalk?

[wica]

There were some false positive Chromium-like queries observed in the DITL data before the introduction of the feature, comprising about 1% of the total traffic, but in the 10+ years since the feature was added, we now find that half of the DNS root server traffic is very likely due to Chromium’s probes. That equates to about 60 billion queries to the root server system on a typical day.

Ik vind het ook wel een issue, dat zoektermen naar DNS servers gestuurd worden.

[Sorcix]

Er worden geen zoektermen naar DNS servers verstuurd.

Men test een aantal willekeurig (en waarschijnlijk niet bestaande) domeinnamen. Als Chrome daarvoor een IP krijgt wil dat zeggen dat de provider z'n eigen webpagina wil serveren voor onbestaande domeinen. Als je nadien een domein intikt, kan Chrome toch checken of het bestaat door te vergelijken met het IP dat het kreeg voor niet bestaande domeinnamen.

[LEDfan]

Als je "marketing" intypt in Chrome, zal hij een DNS lookup doen voor het woord "marketing". Als dit een resultaat geeft en de IRD-check is ok, dan zal Chrome een popup tonen met "Did you mean to go to http://marketing."
Je moet voor de grap maar eens marketing toevoegen aan je hosts file en een lokale HTTP server op poort 80 draaien.

EDIT: net even in chrome "zoetkerm" ingevuld terwijl wirehsark liep en er wordt dus een query gemaakt naar mijn geconfigureerde DNS server (Quad9) https://tweakers.net/i/SQ...2bFsKvQO.png?f=user_large

[Reactie gewijzigd door LEDfan op 23 juli 2024 10:35]

[wica]

De Intranet Redirect Detector doet daarom als test een dns-verzoek voor drie willekeurig gegenereerde domeinnamen. Als van twee van die domeinen hetzelfde ip-adres terugkomt ziet Chromium dat als een dns-hijacking en wordt de ingegeven term als een zoekterm behandeld.

Ik lees dit als volgende. Als er verschillende IP's terug gegeven worden, bij die 3 gegenereerde domeinnamen. Dan behandelt Chromium, de zoekterm, als domeinnaam en daarna pas als zoekterm.

/toevoeging.
Dit is eigenlijk ook het gewenste gedrag.
Als ik in mijn adres balk "bla" intik, binnen mijn search domein (b.v. example.com), kijken of bla.example.com bestaat.

[Reactie gewijzigd door wica op 23 juli 2024 10:35]

[Kenhas]

Als ik het juist lees, worden zoektermen niet gestuurd maar de drie random gegenereerde domeinnamen bij o.a. het opstarten.

[LEDfan]

EDIT: verkeerd gelezen.

[Reactie gewijzigd door LEDfan op 23 juli 2024 10:35]

[jurroen]

[...]
Per dag, per uur, per minuut, ... ??

In het artikel:

De IRD-test wordt iedere keer uitgevoerd als Chromium wordt opgestart of als een apparaat van ip- of dns-instellingen wijzigt

Dus sowieso niet per minuut. Maar in de blogpost waar het artikel naar linkt:

equates to about 60 billion queries to the root server system on a typical day

Dus daar is je antwoord

EDIT: Oeps, te laat, Tijs en Wica waren mij voor.

[Reactie gewijzigd door jurroen op 23 juli 2024 10:35]

[Kenhas]

Mea Culpa. Kon inderdaad gewoon even geklikt hebben

Daarom toch even gedaan en ook een antwoord op een andere vraag gevonden

Could Chromium achieve its goal while only sending one or two queries instead of three? Are other approaches feasible? For example, Firefox’s captive portal test uses delegated namespace probe queries, directing them away from the root servers towards the browser’s infrastructure

Blijkbaar kan het dus wel degelijk anders aangezien Firefox het doet. Hoewel het mij niet helemaal duidelijk wat er dan eigenlijk exact gebeurt

[TijsZonderH]

Per dag, toegevoegd.

[Mellow Jack]

Iets is pas een probleem als je ertegenaan loopt of aan ziet komen dat je ertegenaan gaat lopen

Tot deze usecase was het een relatief efficiënte oplossing mja iig tot de begindagen van het internet vertrouwen veel mensen de ISP niet meer

[lenwar]

Volgens het gelinkte artikel is het per dag.

That equates to about 60 billion queries to the root server system on a typical day.

[mcDavid]

Is het dan zo moeilijk om uit te maken wat er in de adresbalk wordt ingegeven? Als alle checks mislukken, in de laatste stap vragen bij de dns-root-servers.

Ja, dat is dus zo moeilijk. Bijna alles wat je intypt kan op één of andere manier wel een geldige domeinnaam vormen, dus zou je bij een zoekopdracht (bijna) altijd éérst een DNS-query moeten doen om te kijken of het niet per-ongeluk een bestaande domeinnaam is. Dat klinkt alleszins redelijk, behalve als je dus een DNS-provider hebt die zo bijdehand is alle queries naar onbestaande domeinnamen, door te linken naar de site van de hoogste bieder. Dan is je omnibox praktisch onbruikbaar. En dat is precies waar deze functie voor probeert te waken.

[Reactie gewijzigd door mcDavid op 23 juli 2024 10:35]

[Stephanoid]

Kunnen ze niet gewoon alles als een zoekopdracht beschouwen en, alleen voor mensen die dat echt willen, Een aparte url box maken? Dat zou ik persoonlijk erg fijn vinden, want ik heb er een hekel aan dat mijn browser er eventueel een zoekopdracht van maakt.

[Superstoned]

Je kunt het zoeken uitzetten... ik ben er blijbmee - handig hoor. Ook in Firefox.

[slaay]

That equates to about 60 billion queries to the root server system on a typical day.

Bron: https://blog.apnic.net/20...pact-on-root-dns-traffic/

[rookie no. 1]

En jammer dat zo'n beetje elke browser tegenwoordig op Chromium draait, dus dit alleen maar meer is geworden. Dát krijg je d'r van! Monopoly is een spel, daar moet je IRL niet te maken mee krijgen