Il browser Chromium, in continua evoluzione come progetto open source, genitore di Google Chrome e del nuovo Microsoft Edge, ha attirato l'attenzione negativa a causa di una funzione pensata con buone intenzioni: controlla se il provider dell'utente sta 'rubando' risultati di query per domini inesistenti.
, creando richieste fasulle per 'domini' casuali, la cui esistenza è statisticamente improbabile, è responsabile di circa metà del traffico totale ricevuto dai server DNS di root in tutto il mondo. L'ingegnere di Verisign Matt Thomas ha scritto un lungo nel blog di APNIC descrivendo il problema e valutando la sua portata.
Come avviene normalmente la risoluzione DNS
Questi server rappresentano l'istanza suprema a cui ci si deve rivolgere per la risoluzione di .com, .net e così via, per comunicarvi che frglxrtmpuf non è un dominio di livello superiore (TLD).
Il DNS, o Domain Name System ('sistema dei nomi di dominio'), è il sistema che consente ai computer di convertire nomi di dominio memorabili come arstechnica.com in indirizzi IP molto meno pratici, come 3.128.236.93. Senza il DNS, Internet non potrebbe esistere in un formato fruibile per gli esseri umani, quindi il carico non necessario sull'infrastruttura di alto livello è un problema reale.
Per caricare una sola pagina web moderna può essere necessario un numero incredibile di operazioni di ricerca DNS. Ad esempio, quando abbiamo analizzato la homepage di ESPN, abbiamo contato 93 nomi di dominio distinti, da a.espncdn.com a z.motads.com. Tutti questi sono necessari per il caricamento completo della pagina!
Affinché un sistema di ricerca possa gestire tale carico, necessario per servire il mondo intero, il DNS è progettato come una gerarchia multilivello. Alla sommità di questa piramide ci sono i server di root: ogni dominio di primo livello, ad esempio .com, ha il suo specifico insieme di server, che sono l'istanza superiore per ogni dominio sottostante. Un livello sopra questi server ci sono i server di root stessi, da a.root-servers.net fino a m.root-servers.net.
Con che frequenza accade?
Grazie alla gerarchia di caching multi-livello dell'infrastruttura DNS, solo una piccola percentuale delle richieste DNS mondiali raggiunge i server radice. La maggior parte delle persone ottiene le informazioni dal resolver DNS direttamente dal proprio provider. Quando un dispositivo utente deve scoprire come accedere a un determinato sito web, la richiesta viene prima inviata a un server DNS gestito da quel provider locale. Se il server DNS locale non conosce la risposta, reindirizza la richiesta ai propri "server di inoltro" (se definiti).
Se né il server DNS del provider locale né i "server di inoltro" specificati nella sua configurazione hanno una risposta memorizzata nella cache, la richiesta viene inviata direttamente al server autoritativo del dominio sopra che stai cercando di risolvere. Nel caso di dominio.com questo significherà che la richiesta viene inviata ai server autoritativi del dominio stesso com, che si trovano all'indirizzo gtld-servers.net.
Sistema gtld-servers, a cui è stata inviata la richiesta, risponde con un elenco di server autoritativi per il dominio dominio.com, oltre a contenere almeno un record di collegamento con l'indirizzo IP di uno di questi server dei nomi. Le risposte vengono quindi trasmesse lungo la catena: ogni server di inoltro trasmette queste risposte al server che le ha richieste, fino a quando la risposta non raggiunge infine il server del provider locale e il computer dell'utente. Tutti memorizzano questa risposta per non dover disturbare i sistemi di livello superiore.
Nella maggior parte dei casi, i record dei server dei nomi per dominio.com saranno già memorizzati nella cache su uno di questi server di inoltro, quindi i server radice non vengono disturbati. Tuttavia, mentre parliamo dell'URL che conosciamo — quello che viene risolto in un normale sito web. Le richieste di Chrome si riferiscono al livello sopra di questo, al livello dei cluster stessi root-servers.net.
Chromium e il controllo della cattura NXDomain
I controlli di Chromium "questo server DNS non mi inganna?" costituiscono quasi la metà di tutto il traffico che raggiunge il cluster dei server DNS radice di Verisign.
Il browser Chromium, il progetto padre di Google Chrome, del nuovo Microsoft Edge e di un numero incalcolabile di browser meno noti, vuole offrire agli utenti la semplicità di ricerca in un unico campo, talvolta chiamato «Omnibox». In altre parole, l'utente inserisce sia gli URL reali che le query nel motore di ricerca nello stesso campo di testo nella parte superiore della finestra del browser. Facendo un ulteriore passo verso la semplificazione, non costringe neanche l'utente a digitare parte dell'URL con http:// o https://.
Per quanto possa essere comodo, questo approccio richiede che il browser capisca cosa considerare un URL e cosa una query di ricerca. Nella maggior parte dei casi è abbastanza ovvio - ad esempio, una stringa con spazi non può essere un URL. Ma la situazione può complicarsi quando si considerano le intranet, reti private che possono anche utilizzare domini di primo livello privati per risolvere veri siti web.
Se un utente nella intranet della propria azienda inserisce «marketing» e nella intranet dell'azienda c'è un sito web interno con lo stesso nome, allora Chromium mostra una finestra informativa che chiede all'utente se desidera cercare «marketing» o andare a https://marketing. Questo è accettabile, ma molti provider di internet e provider di reti Wi-Fi pubbliche "rubano" ogni URL digitato con errori, reindirizzando l'utente a una pagina piena di annunci pubblicitari.
Generazione casuale
Gli sviluppatori di Chromium non voleva che gli utenti di reti pubbliche vedessero ogni volta una finestra informativa che chiedeva cosa volessero dire, quindi hanno implementato un test: all'avvio del browser o al cambio di rete, Chromium esegue operazioni di ricerca DNS su tre «domini» di primo livello generati casualmente, con una lunghezza compresa tra sette e quindici caratteri. Se due di queste richieste restituiscono lo stesso indirizzo IP, allora Chromium presume che la rete locale "rubi" gli errori NXDOMAIN, che dovrebbe ricevere, quindi il browser considera, fino a nuova comunicazione, tutte le richieste di una sola parola come tentativi di ricerca.
Sfortunatamente, nelle reti che non rubano i risultati delle richieste DNS, queste tre operazioni vengono normalmente elevate al massimo, fino ai server radice dei nomi: il server locale non sa come tradurre qwajuixk, quindi inoltra questa richiesta al suo server di inoltro, che fa lo stesso, fino a quando, infine, a.root-servers.net o uno dei suoi «fratelli» è costretto a dire «Scusa, ma questo non è un dominio».
Poiché ci sono circa 1,67*10^21 nomi di dominio falsi possibili con una lunghezza compresa tra sette e quindici caratteri, la maggior parte delle volte ognuno di questi test, eseguiti in una rete «onesta», raggiunge il server radice. Questo rappresenta addirittura metà del carico totale sui DNS radice, se si crede alle statistiche di quella parte dei cluster root-servers.net, che appartengono all'azienda Verisign.
La storia si ripete
Non è il primo caso in cui un progetto creato con le migliori intenzioni o ha rischiato di farlo, sommando un traffico non necessario a una risorsa pubblica — ci ha subito ricordato la lunga e triste storia di D-Link e del server NTP (Network Time Protocol) di Poul-Henning Kamp a metà degli anni 2000.
Nel 2005, lo sviluppatore di FreeBSD Poul-Henning, che possedeva anche l'unico server NTP di strato 1 in Danimarca, ricevette una fattura imprevista e ingente per il traffico generato. In breve, la causa era che gli sviluppatori di D-Link avevano inserito gli indirizzi dei server NTP di strato 1, incluso il server di Kamp, nel firmware di una linea di switch, router e punti di accesso dell'azienda. Questo ha immediatamente aumentato il traffico del server di Kamp di nove volte, causando il cambio della sua tariffa da «Gratuito» a «9000 dollari all'anno» da parte del Danish Internet Exchange.
Il problema non era che ci fossero troppi router D-Link, ma che essi «violavano la subordinazione». Proprio come i DNS, anche i NTP devono funzionare in modo gerarchico — i server di livello Stratum 0 trasmettono informazioni ai server Stratum 1, che a loro volta le trasmettono ai server Stratum 2, e così via, giù per la gerarchia. Un normale router domestico, switch o punto di accesso, come quelli in cui D-Link ha inserito gli indirizzi dei server NTP, avrebbero dovuto inviare richieste al server Stratum 2 o Stratum 3.
Il progetto Chromium, probabilmente con le migliori intenzioni, ha ripetuto il problema con gli NTP nel problema con i DNS, sovraccaricando i server radice di Internet con richieste che non avrebbero mai dovuto elaborare.
C'è speranza per una rapida soluzione
Nel progetto Chromium c'è un bug aperto , che richiede per risolvere questo problema di disabilitare per impostazione predefinita Intranet Redirect Detector. Vale la pena menzionare il progetto Chromium: il bug è stato trovato prima che, Matt Thomas di Verisign attirasse su di esso una enorme attenzione con il suo nel blog di APNIC. Il bug è stato aperto a giugno, ma è rimasto dimenticato fino al post di Thomas; dopo il post ha iniziato a essere monitorato attentamente.
C'è speranza che il problema venga risolto a breve, e i server DNS radice non dovranno più rispondere quotidianamente a circa 60 miliardi di richieste false.
In base alla pubblicità
Server epici è o Linux con potenti processori della famiglia AMD EPYC e velocissimi dischi NVMe Intel. Affrettati a ordinare!
Fonte: habr.com
