El navegador Chromium, el próspero padre de código abierto de Google Chrome y el nuevo Microsoft Edge, ha recibido una importante atención negativa por una característica que fue pensada con buenas intenciones: comprueba si el ISP del usuario está "robando" resultados de consultas de dominios inexistentes. .
, que crea consultas falsas para "dominios" aleatorios cuya existencia es estadísticamente improbable, es responsable de aproximadamente la mitad del tráfico total recibido por los servidores DNS raíz en todo el mundo. El ingeniero de Verisign Matt Thomas escribió un extenso en el blog de APNIC describiendo el problema y evaluando su magnitud.
Cómo se realiza habitualmente la resolución DNS
Estos servidores son la máxima autoridad con la que debes contactar para resolver .com, .net, etc. para que te digan que frglxrtmpuf no es un dominio de nivel superior (TLD).
DNS, o Sistema de nombres de dominio, es un sistema mediante el cual las computadoras pueden resolver nombres de dominio memorables como arstechnica.com en direcciones IP mucho menos fáciles de usar como 3.128.236.93. Sin DNS, Internet no existiría de una manera que los humanos pudieran usar, lo que significa que la carga innecesaria en la infraestructura de nivel superior es un problema real.
Cargar una única página web moderna puede requerir una cantidad increíble de búsquedas de DNS. Por ejemplo, cuando analizamos la página de inicio de ESPN, contamos 93 nombres de dominio separados, desde a.espncdn.com hasta z.motads.com. ¡Todos ellos son necesarios para que la página se cargue por completo!
Para adaptarse a este tipo de carga de trabajo para un motor de búsqueda que necesita servir a todo el mundo, el DNS está diseñado como una jerarquía de varios niveles. En la cima de esta pirámide están los servidores raíz: cada dominio de nivel superior, como .com, tiene su propia familia de servidores que son la máxima autoridad para cada dominio debajo de ellos. un paso arriba estos Los servidores son los propios servidores raíz, desde a.root-servers.net a m.root-servers.net.
¿Con qué frecuencia ocurre esto?
Gracias a la jerarquía de almacenamiento en caché de varios niveles de la infraestructura DNS, un porcentaje muy pequeño de las consultas DNS del mundo llegan a los servidores raíz. La mayoría de las personas obtienen la información de resolución de DNS directamente de su ISP. Cuando el dispositivo de un usuario necesita saber cómo llegar a un sitio web específico, primero se envía una solicitud a un servidor DNS administrado por ese proveedor local. Si el servidor DNS local no conoce la respuesta, reenvía la solicitud a sus propios "reenviadores" (si se especifica).
Si ni el servidor DNS del proveedor local ni los "servidores de reenvío" especificados en su configuración tienen una respuesta en caché, la solicitud se genera directamente al servidor de dominio autorizado. arriba el que estás intentando convertir. Cuando домен.com esto significará que la solicitud se envía a los servidores autorizados del propio dominio com, que se encuentran en gtld-servers.net.
Sistema gtld-servers, al que se realizó la solicitud, responde con una lista de servidores de nombres autorizados para el dominio domain.com, así como al menos un registro de enlace que contiene la dirección IP de uno de dichos servidores de nombres. A continuación, las respuestas avanzan en la cadena: cada reenviador pasa estas respuestas al servidor que las solicitó, hasta que la respuesta finalmente llega al servidor del proveedor local y a la computadora del usuario. Todos ellos almacenan en caché esta respuesta para no perturbar innecesariamente los sistemas de nivel superior.
En la mayoría de los casos, los registros del servidor de nombres para dominio.com ya estará almacenado en caché en uno de estos reenviadores, por lo que los servidores raíz no se verán afectados. Sin embargo, por ahora estamos hablando del tipo de URL que conocemos: la que se convierte en un sitio web normal. Las solicitudes de Chrome están al nivel arriba esto, en el paso de los propios clusters root-servers.net.
Comprobación de robo de Chromium y NXDomain
Chromium comprueba "¿me está engañando este servidor DNS?" representan casi la mitad de todo el tráfico que llega al grupo de servidores DNS raíz de Verisign.
El navegador Chromium, el proyecto principal de Google Chrome, el nuevo Microsoft Edge e innumerables navegadores menos conocidos, quiere brindar a los usuarios la facilidad de buscar en un solo cuadro, a veces llamado "Omnibox". En otras palabras, el usuario ingresa tanto las URL reales como las consultas del motor de búsqueda en el mismo campo de texto en la parte superior de la ventana del navegador. Dando un paso más hacia la simplificación, tampoco obliga al usuario a ingresar parte de la URL con http:// o https://.
Por muy conveniente que sea, este enfoque requiere que el navegador comprenda qué debe considerarse una URL y qué debe considerarse una consulta de búsqueda. En la mayoría de los casos, esto es bastante obvio; por ejemplo, una cadena con espacios no puede ser una URL. Pero las cosas pueden volverse más complicadas cuando se consideran las intranets: redes privadas que también pueden utilizar dominios privados de alto nivel para resolver sitios web reales.
Si un usuario en la intranet de su empresa escribe "marketing" y la intranet de la empresa tiene un sitio web interno con el mismo nombre, Chromium muestra un cuadro de información que le pregunta al usuario si desea buscar "marketing" o ir a https://marketing. Puede que este no sea el caso, pero muchos ISP y proveedores públicos de Wi-Fi “secuestran” cada URL mal escrita, redirigiendo al usuario a alguna página llena de banners.
Generación aleatoria
Los desarrolladores de Chromium no querían que los usuarios de redes normales vieran un cuadro de información que les preguntaba qué querían decir cada vez que buscaban una sola palabra, por lo que implementaron una prueba: cuando inician un navegador o cambian de red, Chromium realiza búsquedas de DNS en tres "Dominios" de nivel superior generados aleatoriamente, de siete a quince caracteres de longitud. Si dos de estas solicitudes regresan con la misma dirección IP, Chromium asume que la red local está "secuestrando" los errores. NXDOMAIN, que debería recibir, por lo que el navegador considera todas las consultas de una sola palabra ingresadas como intentos de búsqueda hasta nuevo aviso.
Desafortunadamente, en las redes que no robar los resultados de las consultas DNS, estas tres operaciones generalmente suben a la cima, hasta llegar a los servidores de nombres raíz: el servidor local no sabe cómo resolver qwajuixk, entonces reenvía esta solicitud a su reenviador, que hace lo mismo, hasta que finalmente a.root-servers.net o uno de sus “hermanos” no se verá obligado a decir “Lo siento, pero esto no es un dominio”.
Dado que hay aproximadamente 1,67*10^21 posibles nombres de dominio falsos con una longitud de entre siete y quince caracteres, los más comunes cada a partir de estas pruebas realizadas en la red "honesta", llega al servidor raíz. Esto equivale a tanto la mitad de la carga total en el DNS raíz, según las estadísticas de esa parte de los clústeres root-servers.net, que son propiedad de Verisign.
La historia se repite
Esta no es la primera vez que un proyecto creado con las mejores intenciones o casi inundó un recurso público con tráfico innecesario; esto nos recordó inmediatamente la larga y triste historia del servidor NTP (Protocolo de tiempo de red) de D-Link y Poul-Henning Kamp a mediados de la década de 2000.
En 2005, el desarrollador de FreeBSD, Poul-Henning, que también era propietario del único servidor de protocolo de tiempo de red Stratum 1 de Dinamarca, recibió una factura inesperada y elevada por el tráfico transmitido. En resumen, la razón fue que los desarrolladores de D-Link escribieron las direcciones de los servidores NTP Stratum 1, incluido el servidor Kampa, en el firmware de la línea de conmutadores, enrutadores y puntos de acceso de la empresa. Esto instantáneamente multiplicó por nueve el tráfico del servidor de Kampa, lo que provocó que el Danish Internet Exchange (el punto de intercambio de Internet de Dinamarca) cambiara su tarifa de "Gratis" a "$9 por año".
El problema no era que hubiera demasiados enrutadores D-Link, sino que estaban "fuera de línea". Al igual que DNS, NTP debe operar en forma jerárquica: los servidores del estrato 0 pasan información a los servidores del estrato 1, los cuales pasan información a los servidores del estrato 2, y así sucesivamente en la jerarquía. Un enrutador, conmutador o punto de acceso doméstico típico como el que D-Link había programado con direcciones de servidor NTP enviaría solicitudes al servidor Stratum 2 o Stratum 3.
El proyecto Chromium, probablemente con las mejores intenciones, replicó el problema NTP en el problema DNS, cargando los servidores raíz de Internet con solicitudes que nunca debieron manejar.
Hay esperanza de una solución rápida
El proyecto Chromium tiene un código abierto , lo que requiere desactivar el Detector de redireccionamiento de intranet de forma predeterminada para resolver este problema. Hay que darle crédito al proyecto Chromium: se encontró el error antes de esocómo Matt Thomas de Verisign le llamó mucho la atención con su en el blog de APNIC. El error fue descubierto en junio, pero permaneció olvidado hasta la publicación de Thomas; Después del ayuno, empezó a estar bajo estrecha supervisión.
Se espera que el problema se resuelva pronto y que los servidores DNS raíz ya no tengan que responder a las aproximadamente 60 mil millones de consultas falsas cada día.
Sobre los derechos de publicidad
Servidores épicos - es o Linux con potentes procesadores de la familia AMD EPYC y rapidísimas unidades Intel NVMe. ¡Date prisa para hacer el pedido!
Fuente: habr.com