Il browser Chromium, un progetto open source in continua evoluzione e il genitore di Google Chrome e del nuovo Microsoft Edge, ha attirato una seria attenzione negativa a causa di una funzione concepita con buone intenzioni: verifica se il provider dell'utente sta 'rubando' risultati di query di domini inesistenti.
, creando richieste fasulle di 'domini' casuali, la cui esistenza è statisticamente molto improbabile, è responsabile di circa la metà del traffico totale ricevuto dai server DNS radice in tutto il mondo. L'ingegnere di Verisign Matt Thomas ha scritto un dettagliato nel blog di APNIC descrivendo il problema e valutando la sua portata.
Come avviene di solito la risoluzione DNS
Questi server sono l'ultima istanza a cui rivolgersi per risolvere .com, .net e così via, per informarti che frglxrtmpuf non è un dominio di primo livello (TLD).
DNS, o Domain Name System («sistema dei nomi di dominio») è il sistema che consente ai computer di trasformare nomi di dominio facilmente memorizzabili come arstechnica.com in indirizzi IP molto meno intuitivi, come 3.128.236.93. Senza DNS, Internet non potrebbe esistere in una forma utilizzabile per gli esseri umani, quindi il carico inutile sull'infrastruttura di alto livello rappresenta un problema reale.
Per caricare una singola pagina web moderna può essere necessaria una quantità inimmaginabile di operazioni di ricerca DNS. Ad esempio, quando abbiamo analizzato la homepage di ESPN, abbiamo contato 93 nomi di dominio separati, da a.espncdn.com a z.motads.com. Tutti sono essenziali per il caricamento completo della pagina!
Per sostenere un carico del genere, il sistema di ricerca deve essere in grado di servire il mondo intero; per questo motivo, il DNS è progettato come un'architettura gerarchica a più livelli. Alla sommità di questa piramide ci sono i server radice: ogni dominio di primo livello, come .com, ha la propria famiglia di server, che è l'istanza suprema per ogni dominio sottostante. Un gradino sopra questi server ci sono i server radice stessi, da a.root-servers.net fino a m.root-servers.net.
Con che frequenza accade questo?
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 fornitore. Quando un dispositivo utente deve scoprire come accedere a un certo sito, la richiesta viene prima inviata al server DNS gestito da quel fornitore locale. Se il server DNS locale non conosce la risposta, reindirizza la richiesta ai propri "server di inoltro" (nel caso in cui siano specificati).
Se né il server DNS del fornitore locale né i "server di inoltro" configurati hanno una risposta memorizzata nella cache, la richiesta viene quindi elevata direttamente al server di dominio autoritativo in precedenza di quello che stai cercando di risolvere. In questo caso dominio.com significherebbe 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 effettuata la richiesta, risponde con un elenco di server DNS autorizzati per il dominio dominio.com, insieme ad almeno un record di collegamento contenente l'indirizzo IP di uno di questi server DNS. Le risposte vengono quindi trasmesse a catena: ogni server di inoltro trasferisce queste risposte al server che le ha richieste, fino a quando la risposta non raggiunge finalmente il server del provider locale e il computer dell'utente. Tutti questi server memorizzano la risposta nella cache per non dover disturbare i sistemi di livello superiore.
Nella maggior parte dei casi, i record dei server DNS 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 del consueto formato URL - quello che si traduce in un normale sito web. Le richieste di Chrome si riferiscono al livello in precedenza di questo, al livello dei cluster stessi root-servers.net.
Chromium e verifica della presa NXDomain
Le verifiche 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, progetto genitore di Google Chrome, del nuovo Microsoft Edge e di innumerevoli altri browser meno noti, mira a garantire agli utenti la semplicità di ricerca in un unico campo, a volte chiamato "Omnibox". In altre parole, l'utente inserisce sia URL reali che query di ricerca nello stesso campo di testo nella parte superiore della finestra del browser. Facendo un ulteriore passo verso la semplificazione, non richiede nemmeno all'utente di digitare parte dell'URL con http:// o https://.
Per quanto comodo possa essere, questo approccio richiede che il browser comprenda cosa considerare un URL e cosa una query di ricerca. Nella maggior parte dei casi, questo è piuttosto ovvio: ad esempio, una stringa con spazi non può essere un URL. Ma tutto può diventare più complicato, considerando 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 digita "marketing" e all'interno dell'intranet c'è un sito web interno con lo stesso nome, Chromium mostra una finestra di avviso chiedendo all'utente se desidera cercare "marketing" o accedere a https://marketing. Questo può ancora andare bene, ma molti provider Internet e fornitori di reti Wi-Fi pubbliche "rubano" ogni URL inserito con un errore di battitura, reindirizzando l'utente a una pagina piena di banner pubblicitari.
Generazione casuale
Gli sviluppatori di Chromium non volevano che gli utenti vedessero una finestra informativa ad ogni ricerca di una sola parola nelle reti comuni, quindi hanno implementato un test: all'avvio del browser o al cambio di rete, Chromium esegue ricerche DNS di tre "domini" di primo livello generati casualmente, lunghi da sette a quindici caratteri. Se due di queste richieste restituiscono lo stesso indirizzo IP, Chromium presume che la rete locale "rubi" gli errori. NXDOMAIN, che dovrebbe ricevere, quindi il browser considera, fino a ulteriore avviso, tutte le richieste inserite di una sola parola come tentativi di ricerca.
Sfortunatamente, nelle reti che non rubano i risultati delle richieste DNS, queste tre operazioni vengono solitamente elevate al massimo, fino ai server di nomi radice: 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» non è costretto a dire «Mi dispiace, ma questo non è un dominio».
Poiché ci sono circa 1,67*10^21 possibili nomi di dominio falsi da sette a quindici caratteri, più frequentemente ognuno di questi test, eseguiti in una rete «onesta», raggiunge il server radice. Questo rappresenta addirittura metà del carico totale sui DNS di root, se si crede alle statistiche da 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 stia per fallire un risorsa pubblica con traffico non necessario — 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à anni 2000.
Nel 2005, il sviluppatore di FreeBSD Poul-Henning, che possedeva anche l'unico server NTP di livello Stratum 1 in Danimarca, ricevette una bolletta inaspettata e molto elevata per il traffico trasmesso. In breve, la ragione era che gli sviluppatori di D-Link avevano inserito gli indirizzi dei server NTP Stratum 1, incluso il server Kampa, nel firmware della loro linea di switch, router e punti di accesso. Questo aumentò immediatamente il traffico del server Kampa di nove volte, il che portò il Danish Internet Exchange (punto di scambio del traffico internet in Danimarca) a cambiare il suo piano da "Gratuito" a "9.000 dollari all'anno."
Il problema non era che ci fossero troppi router D-Link, ma che questi "violavano la gerarchia". Proprio come per il DNS, l'NTP deve funzionare in modo gerarchico: i server di livello Stratum 0 trasmettono informazioni ai server Stratum 1, che a loro volta le inviano ai server Stratum 2 e così via, giù per la gerarchia. Un comune router domestico, switch o punto di accesso come quelli in cui D-Link ha inserito gli indirizzi dei server NTP, avrebbe dovuto inviare richieste ai server Stratum 2 o Stratum 3.
Il progetto Chromium, pur avendo buone intenzioni, ha replicato il problema NTP con quello DNS, sovraccaricando i server di root di Internet con richieste che non avrebbero mai dovuto elaborare.
C'è speranza per una soluzione rapida
C'è un bug aperto nel progetto Chromium , che richiede di disattivare di default l'Intranet Redirect Detector per risolvere il problema. Va dato atto al progetto Chromium: il bug è stato scoperto prima cheMatt Thomas di Verisign attirasse un'enorme attenzione su di esso con il suo post sul blog APNIC. Il bug è stato segnalato a giugno, ma è rimasto nell'oblio fino al post di Thomas; dopo quel post, ha iniziato a essere attentamente monitorato.
C'è speranza che il problema venga risolto presto, e i server DNS di root non dovranno più rispondere quotidianamente a circa 60 miliardi di richieste false.
In pubblicità
Server epici — rappresenta o Linux con potenti processori della famiglia AMD EPYC e dischi NVMe Intel molto veloci. Affrettati a ordinare!
Fonte: habr.com
