El navegador Chromium, el pròsper progenitor de codi obert de Google Chrome i el nou Microsoft Edge, ha rebut una atenció negativa significativa per una funció que estava pensada amb bones intencions: comprova si l'ISP de l'usuari està "robant" resultats de consultes de domini inexistents. .
, que crea consultes falses per a "dominis" aleatoris que estadísticament és poc probable que existeixin, és responsable d'aproximadament la meitat del trànsit total rebut pels servidors DNS arrel a tot el món. L'enginyer de Verisign Matt Thomas va escriure un llarg al blog de l'APNIC descrivint el problema i valorant-ne la magnitud.
Com es realitza normalment la resolució de DNS
Aquests servidors són la màxima autoritat amb què us heu de posar en contacte per resoldre .com, .net, etc. perquè us diguin que frglxrtmpuf no és un domini de primer nivell (TLD).
DNS, o sistema de noms de domini, és un sistema mitjançant el qual els ordinadors poden resoldre noms de domini memorables com arstechnica.com en adreces IP molt menys fàcils d'utilitzar com 3.128.236.93. Sense DNS, Internet no existiria d'una manera que els humans podrien utilitzar, el que significa que la càrrega innecessària a la infraestructura de nivell superior és un problema real.
Carregar una única pàgina web moderna pot requerir un nombre increïble de cerques de DNS. Per exemple, quan vam analitzar la pàgina d'inici d'ESPN, vam comptar 93 noms de domini diferents, que van des de a.espncdn.com fins a z.motads.com. Tots ells són necessaris perquè la pàgina es carregui completament!
Per adaptar-se a aquest tipus de càrrega de treball per a un motor de cerca que ha de donar servei a tot el món, el DNS està dissenyat com una jerarquia de diversos nivells. A la part superior d'aquesta piràmide hi ha els servidors arrel: cada domini de primer nivell, com ara .com, té la seva pròpia família de servidors que són la màxima autoritat per a cada domini per sota d'ells. Un pas amunt aquests els servidors són els propis servidors arrel, de a.root-servers.net до m.root-servers.net.
Amb quina freqüència passa això?
Gràcies a la jerarquia de memòria cau multinivell de la infraestructura DNS, un percentatge molt reduït de les consultes DNS del món arriba als servidors arrel. La majoria de la gent obté la informació de resolució de DNS directament del seu ISP. Quan el dispositiu d'un usuari necessita saber com arribar a un lloc web específic, primer s'envia una sol·licitud a un servidor DNS gestionat per aquest proveïdor local. Si el servidor DNS local no sap la resposta, reenvia la sol·licitud als seus propis "reenviadors" (si s'especifica).
Si ni el servidor DNS del proveïdor local ni els "servidors de reenviament" especificats a la seva configuració tenen una resposta a la memòria cau, la sol·licitud s'envia directament al servidor de domini autoritzat. dalt el que estàs intentant convertir. Quan домен.com això significarà que la sol·licitud s'envia als servidors autoritzats del propi domini com, que es troben a gtld-servers.net.
Sistema gtld-servers, al qual s'ha fet la sol·licitud, respon amb una llista de servidors de noms autoritzats per al domini domini.com, així com almenys un registre d'enllaç que conté l'adreça IP d'un d'aquests servidors de noms. A continuació, les respostes es mouen per la cadena: cada reenviador passa aquestes respostes al servidor que les ha sol·licitat, fins que finalment la resposta arriba al servidor del proveïdor local i a l'ordinador de l'usuari. Tots ells guardan aquesta resposta a la memòria cau per no molestar innecessàriament els sistemes de nivell superior.
En la majoria dels casos, registres del servidor de noms per domini.com ja s'emmagatzemarà a la memòria cau en un d'aquests reenviadors, de manera que els servidors arrel no es veuran molestats. Tanmateix, de moment estem parlant del tipus d'URL que coneixem: el que es converteix en un lloc web normal. Les sol·licituds de Chrome estan al nivell dalt això, al pas dels propis clústers root-servers.net.
Comprovació de robatori de Chromium i NXDomain
Chromium comprova "M'està enganyant aquest servidor DNS?" representen gairebé la meitat de tot el trànsit que arriba al clúster de servidors DNS arrel de Verisign.
El navegador Chromium, el projecte principal de Google Chrome, el nou Microsoft Edge i innombrables navegadors menys coneguts, vol oferir als usuaris la facilitat de cercar en un sol quadre, de vegades anomenat "Omnibox". En altres paraules, l'usuari introdueix tant URL reals com consultes del motor de cerca al mateix camp de text a la part superior de la finestra del navegador. Donant un pas més cap a la simplificació, tampoc no obliga l'usuari a introduir part de l'URL amb http:// o https://.
Per molt còmode que sigui, aquest enfocament requereix que el navegador entengui què s'ha de considerar un URL i què s'ha de considerar una consulta de cerca. En la majoria dels casos, això és força obvi; per exemple, una cadena amb espais no pot ser un URL. Però les coses poden tornar-se més complicades si considerem intranets: xarxes privades que també poden utilitzar dominis privats de primer nivell per resoldre llocs web reals.
Si un usuari de la intranet de la seva empresa escriu "màrqueting" i la intranet de l'empresa té un lloc web intern amb el mateix nom, aleshores Chromium mostra un quadre d'informació que demana a l'usuari si vol cercar "màrqueting" o anar a https://marketing. Pot ser que no sigui el cas, però molts ISP i proveïdors públics de Wi-Fi "segresten" tots els URL escrits malament, redirigint l'usuari a una pàgina plena de bàners.
Generació aleatòria
Els desenvolupadors de Chromium no volien que els usuaris de les xarxes habituals veiessin un quadre d'informació on es preguntava què volien dir cada vegada que cercaven una sola paraula, de manera que van implementar una prova: quan inicien un navegador o canvien de xarxa, Chromium realitza cerques DNS en tres "dominis" de nivell superior generats aleatòriament, de set a quinze caràcters. Si dues d'aquestes sol·licituds tornen amb la mateixa adreça IP, Chromium assumeix que la xarxa local està "segrestant" els errors. NXDOMAIN, que hauria de rebre, de manera que el navegador considera que totes les consultes d'una sola paraula introduïdes són intents de cerca fins a nou avís.
Malauradament, a les xarxes això no robar els resultats de les consultes DNS, aquestes tres operacions solen pujar al cim, fins als propis servidors de noms arrel: el servidor local no sap com resoldre'ls. qwajuixk, remet aquesta sol·licitud al seu reenviador, que fa el mateix, fins que finalment a.root-servers.net o un dels seus "germans" no es veurà obligat a dir "Ho sento, però això no és un domini".
Com que hi ha aproximadament 1,67*10^21 possibles noms de domini falsos que van des de set a quinze caràcters de longitud, el més comú cada d'aquestes proves realitzades a la xarxa "honesta", arriba al servidor arrel. Això equival a tant la meitat de la càrrega total al DNS arrel, segons les estadístiques d'aquesta part dels clústers root-servers.net, que són propietat de Verisign.
La història es repeteix
No és la primera vegada que es crea un projecte amb les millors intencions o gairebé va inundar un recurs públic amb trànsit innecessari; això ens va recordar immediatament la llarga i trista història del servidor NTP (Network Time Protocol) de D-Link i Poul-Henning Kamp a mitjans dels anys 2000.
El 2005, el desenvolupador de FreeBSD Poul-Henning, que també era propietari de l'únic servidor de protocol de temps de xarxa Stratum 1 de Dinamarca, va rebre una factura inesperada i gran pel trànsit transmès. En resum, el motiu va ser que els desenvolupadors de D-Link van escriure les adreces dels servidors Stratum 1 NTP, inclòs el servidor Kampa, al microprogramari de la línia d'interruptors, encaminadors i punts d'accés de l'empresa. Això va augmentar a l'instant el trànsit del servidor de Kampa per nou, fet que va fer que l'Intercanvi d'Internet danès (el punt d'intercanvi d'Internet de Dinamarca) canviés la seva tarifa de "Gratis" a "9 dòlars anuals".
El problema no era que hi hagués massa encaminadors D-Link, sinó que estaven "fora de línia". Igual que DNS, NTP ha de funcionar de forma jeràrquica: els servidors Stratum 0 passen informació als servidors Stratum 1, que passen informació als servidors Stratum 2, i així successivament a la jerarquia. Un encaminador, commutador o punt d'accés domèstic típic com el que D-Link havia programat amb adreces de servidor NTP enviaria sol·licituds al servidor Stratum 2 o Stratum 3.
El projecte Chromium, probablement amb la millor de les intencions, va replicar el problema NTP en el problema DNS, carregant els servidors arrel d'Internet amb peticions que mai havien de gestionar.
Hi ha esperança d'una solució ràpida
El projecte Chromium té un codi obert , que requereix desactivar el detector de redireccions d'intranet de manera predeterminada per resoldre aquest problema. Hem de donar crèdit al projecte Chromium: s'ha trobat l'error abans quecom Matt Thomas de Verisign li va cridar molta atenció amb la seva al blog de l'APNIC. L'error es va descobrir al juny, però va romandre oblidat fins a la publicació de Thomas; Després del dejuni, va començar a estar sota una estreta supervisió.
S'espera que el problema es resolgui aviat i els servidors DNS arrel ja no hauran de respondre a les 60 milions de consultes falses estimades cada dia.
Sobre els drets de publicitat
Servidors èpics - És o Linux amb potents processadors de la família AMD EPYC i unitats Intel NVMe molt ràpides. Afanya't a fer la comanda!
Font: www.habr.com