O navegador Chromium, o próspero pai de código aberto de Google Chrome e o novo Microsoft Edge, recibiu unha importante atención negativa por unha función que foi pensada con boas intencións: comproba se o ISP do usuario está "roubando" os resultados de consulta de dominio inexistentes. .
, que crea consultas falsas para "dominios" aleatorios que estatisticamente é improbable que existan, é responsable de aproximadamente a metade do tráfico total recibido polos servidores DNS raíz en todo o mundo. O enxeñeiro de Verisign Matt Thomas escribiu un extenso no blog da APNIC describindo o problema e valorando a súa magnitude.
Como se realiza normalmente a resolución DNS
Estes servidores son a máxima autoridade coa que debes contactar para resolver .com, .net, etc. para que che digan que frglxrtmpuf non é un dominio de nivel superior (TLD).
DNS, ou Domain Name System, é un sistema polo cal os ordenadores poden resolver nomes de dominio memorables como arstechnica.com en enderezos IP moito menos amigables como 3.128.236.93. Sen DNS, Internet non existiría dun xeito que os humanos poderían usar, o que significa que a carga innecesaria na infraestrutura de nivel superior é un problema real.
Cargar unha única páxina web moderna pode requirir un número incrible de buscas de DNS. Por exemplo, cando analizamos a páxina de inicio de ESPN, contamos 93 nomes de dominio separados, que van desde a.espncdn.com ata z.motads.com. Todos eles son necesarios para que a páxina se cargue completamente!
Para acomodar este tipo de carga de traballo para un motor de busca que necesita servir a todo o mundo, o DNS está deseñado como unha xerarquía de varios niveis. Na parte superior desta pirámide están os servidores raíz: cada dominio de nivel superior, como .com, ten a súa propia familia de servidores que son a máxima autoridade para cada dominio inferior. Un paso arriba destes os servidores son os propios servidores raíz, de a.root-servers.net para m.root-servers.net.
Cantas veces ocorre isto?
Grazas á xerarquía de caché de varios niveis da infraestrutura DNS, unha porcentaxe moi pequena das consultas de DNS do mundo chega aos servidores raíz. A maioría da xente obtén a información da súa resolución de DNS directamente do seu ISP. Cando o dispositivo dun usuario necesita saber como acceder a un sitio web específico, primeiro envíase unha solicitude a un servidor DNS xestionado por ese provedor local. Se o servidor DNS local non coñece a resposta, envía a solicitude aos seus propios "reenviadores" (se se especifica).
Se nin o servidor DNS do provedor local nin os "servidores de reenvío" especificados na súa configuración teñen unha resposta en caché, a solicitude envíase directamente ao servidor de dominio autorizado. anterior o que estás tentando converter. Cando домен.com isto significará que a solicitude se envía aos servidores autorizados do propio dominio com, que se atopan en gtld-servers.net.
Sistema gtld-servers, ao que se realizou a solicitude, responde cunha lista de servidores de nomes autorizados para o dominio domain.com, así como polo menos un rexistro de ligazóns que contén o enderezo IP dun servidor de nomes deste tipo. A continuación, as respostas avanzan na cadea: cada reenviador pasa estas respostas ao servidor que as solicitou, ata que finalmente a resposta chega ao servidor do provedor local e ao ordenador do usuario. Todos eles almacenan en caché esta resposta para non perturbar innecesariamente os sistemas de nivel superior.
Na maioría dos casos, os rexistros do servidor de nomes para dominio.com xa se almacenará na caché nun destes reenviadores, polo que os servidores raíz non se verán perturbados. Non obstante, polo de agora estamos a falar do tipo de URL co que estamos familiarizados: o que se converte nun sitio web normal. As solicitudes de Chrome están ao nivel anterior isto, no chanzo dos propios clusters root-servers.net.
Comprobación de roubo de Chromium e NXDomain
Chromium verifica "Este servidor DNS me está enganando?" representan case a metade de todo o tráfico que chega ao clúster de servidores DNS raíz de Verisign.
O navegador Chromium, o proxecto principal de Google Chrome, o novo Microsoft Edge e infinidade de navegadores menos coñecidos, quere proporcionar aos usuarios a facilidade de buscar nunha única caixa, ás veces chamada "Omnibox". Noutras palabras, o usuario introduce tanto URL reais como consultas do motor de busca no mesmo campo de texto na parte superior da xanela do navegador. Dando un paso máis cara á simplificación, tampouco obriga ao usuario a introducir parte do URL con http:// ou https://.
Por máis conveniente que sexa, este enfoque require que o navegador comprenda o que se debe considerar un URL e o que se debe considerar unha consulta de busca. Na maioría dos casos isto é bastante obvio; por exemplo, unha cadea con espazos non pode ser un URL. Pero as cousas poden complicarse cando se consideran intranets: redes privadas que tamén poden usar dominios privados de primeiro nivel para resolver sitios web reais.
Se un usuario da intranet da súa empresa escribe "marketing" e a intranet da empresa ten un sitio web interno co mesmo nome, Chromium mostra unha caixa de información no que lle pregunta se quere buscar "marketing" ou ir a https://marketing. Este pode non ser o caso, pero moitos ISP e provedores públicos de Wi-Fi "secuestran" cada URL mal escrito, redirixindo o usuario a algunha páxina chea de banners.
Xeración aleatoria
Os desenvolvedores de Chromium non querían que os usuarios das redes habituais viran unha caixa de información preguntando o que querían dicir cada vez que buscaban unha soa palabra, polo que implementaron unha proba: cando inician un navegador ou cambian de rede, Chromium realiza buscas de DNS en tres "dominios" xerados aleatoriamente de nivel superior, de sete a quince caracteres. Se calquera destas solicitudes regresan co mesmo enderezo IP, Chromium asume que a rede local está "secuestrando" os erros. NXDOMAIN, que debería recibir, polo que o navegador considera que todas as consultas dunha soa palabra introducidas son intentos de busca ata novo aviso.
Por desgraza, nas redes que non roubar os resultados das consultas de DNS, estas tres operacións adoitan ascender á cima, ata chegar aos propios servidores de nomes raíz: o servidor local non sabe como resolver qwajuixk, polo que remite esta solicitude ao seu reenviador, que fai o mesmo, ata que finalmente a.root-servers.net ou un dos seus "irmáns" non se verá obrigado a dicir "Sentímolo, pero isto non é un dominio".
Dado que hai aproximadamente 1,67*10^21 posibles nomes de dominio falsos que van de sete a quince caracteres de lonxitude, o máis común cada a partir destas probas realizadas na rede "honesta", chega ao servidor raíz. Isto equivale a tanto a metade da carga total do DNS raíz, segundo as estatísticas desa parte dos clústeres root-servers.net, que son propiedade de Verisign.
A historia repítese
Non é a primeira vez que un proxecto crea coas mellores intencións ou case inundou un recurso público cun tráfico innecesario; isto recordounos inmediatamente a longa e triste historia do servidor NTP (Network Time Protocol) de D-Link e Poul-Henning Kamp a mediados dos anos 2000.
En 2005, o desenvolvedor de FreeBSD Poul-Henning, que tamén era propietario do único servidor de protocolo de tempo de rede Stratum 1 de Dinamarca, recibiu unha factura inesperada e grande polo tráfico transmitido. En resumo, a razón foi que os desenvolvedores de D-Link escribiron os enderezos dos servidores Stratum 1 NTP, incluído o servidor Kampa, no firmware da liña de conmutadores, enrutadores e puntos de acceso da compañía. Isto multiplicou instantáneamente o tráfico do servidor de Kampa nove veces, o que provocou que o Danish Internet Exchange (o punto de intercambio de Internet de Dinamarca) cambiase a súa tarifa de "Gratis" a "9 dólares ao ano".
O problema non era que houbese demasiados enrutadores D-Link, senón que estaban "desconectados". Do mesmo xeito que DNS, NTP debe funcionar de forma xerárquica: os servidores Stratum 0 pasan información aos servidores Stratum 1, que pasan información aos servidores Stratum 2, e así sucesivamente na xerarquía. Un enrutador, interruptor ou punto de acceso doméstico típico como o que D-Link programara con enderezos de servidor NTP enviaría solicitudes ao servidor Stratum 2 ou Stratum 3.
O proxecto Chromium, probablemente coa mellor das intencións, replicou o problema NTP no problema DNS, cargando os servidores raíz de Internet con solicitudes que nunca estaban destinadas a xestionar.
Hai esperanza para unha solución rápida
O proxecto Chromium ten un código aberto , o que require desactivar o Detector de redireccións de intranet por defecto para resolver este problema. Debemos dar crédito ao proxecto Chromium: atopouse o erro antes disocomo Matt Thomas de Verisign chamoulle moita atención coa súa no blog da APNIC. O erro descubriuse en xuño, pero permaneceu esquecido ata a publicación de Thomas; Despois do xaxún, comezou a estar baixo unha estreita supervisión.
Espérase que o problema se resolva pronto e os servidores DNS root xa non teñan que responder aos 60 millóns de consultas falsas estimadas cada día.
Sobre os dereitos da publicidade
Servidores épicos - É ou Linux con potentes procesadores da familia AMD EPYC e unidades Intel NVMe moi rápidas. ¡Apresúrate a ordenar!
Fonte: www.habr.com