Il browser Chromium, il fiorente genitore open source di Google Chrome e del nuovo Microsoft Edge, ha ricevuto un'attenzione negativa significativa per una funzionalità intesa con buone intenzioni: controlla se l'ISP dell'utente sta "rubando" risultati di query di dominio inesistenti .
, che crea query false per "domini" casuali che è statisticamente improbabile che esistano, è responsabile di circa la metà del traffico totale ricevuto dai server DNS root in tutto il mondo. L'ingegnere di Verisign Matt Thomas ha scritto un lungo articolo sul blog APNIC descrivendo il problema e valutandone la portata.
Come viene solitamente eseguita la risoluzione DNS
Questi server sono l'autorità più alta che dovresti contattare per risolvere .com, .net, ecc. in modo che ti dicano che frglxrtmpuf non è un dominio di primo livello (TLD).
DNS, o Domain Name System, è un sistema mediante il quale i computer possono risolvere nomi di dominio facili da ricordare come arstechnica.com in indirizzi IP molto meno intuitivi come 3.128.236.93. Senza DNS, Internet non esisterebbe in modo che gli esseri umani possano usarla, il che significa che il carico inutile sull'infrastruttura di livello superiore è un vero problema.
Il caricamento di una singola pagina Web moderna può richiedere un numero incredibile di ricerche DNS. Ad esempio, quando abbiamo analizzato la home page di ESPN, abbiamo contato 93 nomi di dominio separati, che vanno da a.espncdn.com a z.motads.com. Tutti sono necessari affinché la pagina venga caricata completamente!
Per soddisfare questo tipo di carico di lavoro per un motore di ricerca che deve servire il mondo intero, il DNS è progettato come una gerarchia multilivello. In cima a questa piramide ci sono i root server: ogni dominio di primo livello, come .com, ha la propria famiglia di server che rappresentano la massima autorità per ogni dominio sottostante. Un passo avanti queste i server sono gli stessi server root, da a.root-servers.net a m.root-servers.net.
Quanto spesso accade?
Grazie alla gerarchia del caching multilivello dell'infrastruttura DNS, una percentuale molto piccola delle query DNS mondiali raggiunge i root server. La maggior parte delle persone ottiene le informazioni sul risolutore DNS direttamente dal proprio ISP. Quando il dispositivo di un utente deve sapere come raggiungere un sito Web specifico, viene prima inviata una richiesta a un server DNS gestito da quel provider locale. Se il server DNS locale non conosce la risposta, inoltra la richiesta ai propri “spedizionieri” (se specificati).
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 di dominio autorevole sopra quello che stai cercando di convertire. Quando домен.com questo significherà che la richiesta verrà inviata ai server autorevoli del dominio stesso com, che si trovano in gtld-servers.net.
Sistema gtld-servers, a cui è stata effettuata la richiesta, risponde con un elenco di server dei nomi autorevoli per il dominio dominio.com, nonché almeno un record di collegamento contenente l'indirizzo IP di uno di tali server dei nomi. Successivamente, le risposte si spostano lungo la catena: ciascun forwarder trasmette queste risposte al server che le ha richieste, finché la risposta non raggiunge finalmente il server del provider locale e il computer dell'utente. Tutti memorizzano nella cache questa risposta per non disturbare inutilmente i sistemi di livello superiore.
Nella maggior parte dei casi, i record del server dei nomi per dominio.com sarà già memorizzato nella cache su uno di questi forwarder, quindi i server root non saranno disturbati. Tuttavia, per ora stiamo parlando del tipo di URL che ci è familiare, quello che viene convertito in un normale sito web. Le richieste di Chrome sono a livello sopra questo, sul passo dei grappoli stessi root-servers.net.
Controllo furto di Chromium e NXDomain
Chromium verifica "questo server DNS mi sta prendendo in giro?" rappresentano quasi la metà di tutto il traffico che raggiunge il cluster di server DNS root di Verisign.
Il browser Chromium, il progetto genitore di Google Chrome, del nuovo Microsoft Edge e di innumerevoli browser meno conosciuti, vuole fornire agli utenti la facilità di ricerca in un'unica casella, a volte chiamata "Omnibox". In altre parole, l'utente inserisce sia gli URL reali che le query del motore di ricerca nello stesso campo di testo nella parte superiore della finestra del browser. Facendo un altro passo verso la semplificazione, inoltre, non obbliga l'utente a inserire parte dell'URL http:// o https://.
Per quanto conveniente sia, questo approccio richiede che il browser comprenda cosa dovrebbe essere considerato un URL e cosa dovrebbe essere considerata una query di ricerca. Nella maggior parte dei casi questo è abbastanza ovvio: ad esempio, una stringa con spazi non può essere un URL. Ma le cose possono diventare più complicate se si considerano le intranet, reti private che possono anche utilizzare domini privati di primo livello per risolvere siti Web reali.
Se un utente nell'intranet della propria azienda digita "marketing" e l'intranet dell'azienda ha un sito Web interno con lo stesso nome, Chromium visualizza una casella di informazioni che chiede all'utente se desidera cercare "marketing" o andare a https://marketing. Potrebbe non essere così, ma molti ISP e provider Wi-Fi pubblici “dirottano” ogni URL con errori di ortografia, reindirizzando l'utente a qualche pagina piena di banner.
Generazione casuale
Gli sviluppatori di Chromium non volevano che gli utenti delle reti normali vedessero una casella informativa che chiedeva cosa intendessero ogni volta che cercavano una singola parola, quindi hanno implementato un test: quando avviano un browser o cambiano rete, Chromium esegue ricerche DNS su tre "domini" generati casualmente di livello superiore, lunghi da sette a quindici caratteri. Se due di queste richieste restituiscono lo stesso indirizzo IP, Chromium presuppone che la rete locale stia "dirottando" gli errori NXDOMAIN, che dovrebbe ricevere, quindi il browser considera tutte le query di una sola parola immesse come tentativi di ricerca fino a nuovo avviso.
Sfortunatamente, nelle reti che no rubare i risultati delle query DNS, queste tre operazioni di solito salgono in cima, fino agli stessi server dei nomi root: il server locale non sa come risolvere qwajuixk, quindi inoltra questa richiesta al suo spedizioniere, che fa lo stesso, fino alla fine a.root-servers.net oppure uno dei suoi “fratelli” non sarà costretto a dire “Scusa, ma questo non è un dominio”.
Poiché esistono circa 1,67*10^21 possibili nomi di dominio falsi di lunghezza compresa tra sette e quindici caratteri, i nomi di dominio più comuni ogni da questi test effettuati sulla rete “onesta” si arriva al root server. Questo equivale a tanto mezzo dal carico totale sul DNS root, secondo le statistiche di quella parte dei cluster root-servers.net, di proprietà di Verisign.
La storia si ripete
Questa non è la prima volta che un progetto nasce con le migliori intenzioni o quasi inondato una risorsa pubblica con traffico non necessario: questo ci ha immediatamente ricordato la lunga e triste storia del server NTP (Network Time Protocol) di D-Link e Poul-Henning Kamp a metà degli anni 2000.
Nel 2005, lo sviluppatore di FreeBSD Poul-Henning, che possedeva anche l'unico server Stratum 1 Network Time Protocol della Danimarca, ricevette una fattura inaspettata e salata per il traffico trasmesso. In breve, il motivo è che gli sviluppatori D-Link hanno scritto gli indirizzi dei server NTP Stratum 1, compreso il server Kampa, nel firmware della linea di switch, router e punti di accesso dell'azienda. Ciò ha immediatamente aumentato di nove volte il traffico del server di Kampa, costringendo il Denmark Internet Exchange (l'Internet Exchange Point della Danimarca) a modificare la sua tariffa da "Gratuita" a "9 dollari all'anno".
Il problema non era che ci fossero troppi router D-Link, ma che erano “fuori linea”. Proprio come il DNS, NTP deve operare in forma gerarchica: i server Stratum 0 passano informazioni ai server Stratum 1, che passano informazioni ai server Stratum 2 e così via lungo la gerarchia. Un tipico router domestico, switch o punto di accesso come quello programmato da D-Link con indirizzi di server NTP invierebbe richieste al server Stratum 2 o Stratum 3.
Il progetto Chromium, probabilmente con le migliori intenzioni, ha replicato il problema NTP nel problema DNS, caricando i root server di Internet con richieste che non avrebbero mai dovuto gestire.
C’è speranza per una soluzione rapida
Il progetto Chromium ha un open source , che richiede la disabilitazione del Rilevatore reindirizzamento Intranet per impostazione predefinita per risolvere il problema. Dobbiamo dare merito al progetto Chromium: il bug è stato trovato prima di quellocome Matt Thomas di Verisign gli abbia attirato molta attenzione con il suo sul blog APNIC. Il bug è stato scoperto a giugno, ma è rimasto dimenticato fino al post di Thomas; Dopo il digiuno, iniziò a essere sotto stretto controllo.
Si spera che il problema venga presto risolto e che i server DNS root non debbano più rispondere alle circa 60 miliardi di richieste fasulle che si stimano ogni giorno.
Sui diritti della pubblicità
Server epici - E ' o Linux con potenti processori della famiglia AMD EPYC e unità Intel NVMe molto veloci. Affrettati ad ordinare!
Fonte: habr.com