El navegador Chromium, el padre de código abierto en rápida expansión de Google Chrome y el nuevo Microsoft Edge, ha recibido una seria atención negativa por una función bien intencionada que verifica si el ISP de un usuario está robando resultados de consultas de dominio inexistentes.
Intranet Redirect Detector , que crea consultas falsas para "dominios" aleatorios que estadísticamente es poco probable que existan, es responsable de aproximadamente la mitad del tráfico total recibido por los servidores DNS raíz en todo el mundo. Matt Thomas, ingeniero de Verisign, escribió una publicación extensa en el blog de APNIC en la que describía el problema y evaluaba su escala.
Cómo se suelen realizar las búsquedas de DNS
Estos servidores son la máxima autoridad con la que se puede contactar para resolver .com, .net, etc., de modo que le digan que frglxrtmpuf no es un dominio de nivel superior (TLD).
DNS, o Domain Name System, es un sistema mediante el cual las computadoras pueden traducir nombres de dominio memorables como arstechnica.com en direcciones IP mucho menos convenientes, como 3.128.236.93. Sin DNS, Internet no podría existir en una forma amigable para los humanos, lo que significa que la carga innecesaria en la infraestructura de nivel superior es un problema real.
Puede ser necesaria una cantidad inimaginable de búsquedas de DNS para cargar una única página web moderna. Por ejemplo, cuando analizamos la página de inicio de ESPN, contamos 93 nombres de dominio separados, que van desde a.espncdn.com hasta z.motads.com. ¡Todos son necesarios para cargar una página completa!
El DNS está diseñado como una jerarquía multinivel para manejar este tipo de carga de trabajo que necesita servir al mundo entero. En la parte superior de esta pirámide se encuentran los servidores raíz: cada dominio de nivel superior, como .com, tiene su propia familia de servidores, que son la autoridad máxima para cada dominio debajo de ellos. Un nivel por encima de estos servidores son los servidores raíz mismos, desde
a.root-servers.nethasta m.root-servers.net.
¿Con qué frecuencia ocurre esto?
Debido a la jerarquía de almacenamiento en caché por niveles de la infraestructura de DNS, un porcentaje muy pequeño de las consultas de DNS del mundo llegan a los servidores raíz. La mayoría de las personas obtienen su 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 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 ISP local ni sus "reenviadores" configurados tienen una respuesta en caché, la solicitud se enruta directamente al servidor autorizado en el dominio por encima del que está tratando de resolver . Cuando
.comesto significará que la solicitud se envía a los servidores autorizados del propio dominio com, que se encuentran en gtld-servers.net.
El sistema
gtld-serversal que se realizó la solicitud responde con una lista de servidores de nombres autorizados para el dominio domain.com, así como con al menos un registro adhesivo que contiene la dirección IP de uno de esos servidores de nombres. Luego, las respuestas descienden por la cadena: cada reenviador envía estas respuestas al servidor que las solicitó, hasta que la respuesta finalmente llega al servidor del proveedor local y a la computadora del usuario. Al mismo tiempo, todos 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 domain.comya 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 de la forma habitual de una URL, una que se convierte en un sitio web normal. Las consultas de Chrome están en un nivel superior , en el peldaño de los propios clústeres
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 clúster de servidor raíz DNS de Verisign.
El navegador Chromium, el proyecto principal de Google Chrome, el nuevo Microsoft Edge y un sinnúmero de navegadores menos conocidos, quiere brindar a los usuarios la facilidad de buscar en un solo campo, a veces denominado "Omnibox". En otras palabras, el usuario ingresa tanto las URL reales como las consultas del motor de búsqueda en el mismo cuadro 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 más conveniente que sea, este enfoque requiere que el navegador comprenda qué contar como URL y qué como 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 complicarse más si se consideran las intranets: redes privadas que también pueden utilizar dominios privados de nivel superior para resolver sitios web reales.
Si un usuario ingresa "marketing" en la intranet de su empresa, y la intranet de su empresa tiene un sitio web interno con el mismo nombre, Chromium muestra un cuadro de información preguntando al usuario si desea buscar "marketing" o ir a
https://marketing... Está bien, pero muchos ISP y proveedores de Wi-Fi públicos "secuestran" cada URL mal escrita, redirigiendo al usuario a una página llena de anuncios publicitarios.
Generación aleatoria
Los desarrolladores de Chromium no querían que los usuarios de las redes normales vieran una ventana de información cada vez que buscaban una palabra y preguntaban qué querían decir, por lo que implementaron una prueba: al iniciar el navegador o cambiar la red, Chromium realiza búsquedas de DNS de tres "dominios" generados aleatoriamente. nivel superior, de siete a quince caracteres. Si dos de estas solicitudes regresan con la misma dirección IP, entonces Chromium asume que la red local está "robando" los errores
NXDOMAINque debería recibir, por lo que el navegador considera todas las consultas ingresadas de la misma palabra como intentos de búsqueda hasta nuevo aviso.
Desafortunadamente, en redes que no sonrobar los resultados de las consultas de DNS, estas tres operaciones suelen ir a la cima, a los propios servidores de nombres raíz: el servidor local no sabe cómo
qwajuixkresolver, por lo que reenvía esta solicitud a su reenviador, que hace lo mismo, hasta que finalmente, a.root-servers.neto uno de sus "hermanos" no se verán obligados a decir "Lo siento, pero esto no es un dominio".
Dado que hay aproximadamente 1,67 * 10 ^ 21 posibles nombres de dominio falsos que tienen entre siete y quince caracteres de longitud, es común que cada una de estas pruebas, realizada en una red "justa", llegue al servidor raíz. Esto es hasta la mitad de la carga total en el DNS raíz, según las estadísticas de la parte de los clústeres
root-servers.netque pertenecen a Verisign.
La historia se repite
Esta no es la primera vez que un proyecto bien intencionado inundó o casi inundó un recurso público con tráfico innecesario; inmediatamente nos recordó la larga y triste historia de D-Link y el servidor NTP Pole-Henning Camp a mediados de la década de 2000. X.
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, el motivo fue que los desarrolladores de D-Link registraron las direcciones de los servidores NTP Stratum 1, incluido el servidor Campa, en el firmware de la línea de conmutadores, enrutadores y puntos de acceso de la empresa. Esto incrementó instantáneamente el tráfico del servidor Kampa en nueve veces, lo que provocó que Danish Internet Exchange (el punto de intercambio de Internet de Dinamarca) cambiara su tarifa de "Gratis" a "9.000 dólares por año".
El problema no era que hubiera demasiados enrutadores D-Link, sino que "violaban la cadena de mando". Al igual que el DNS, NTP debería funcionar de manera jerárquica: los servidores de Estrato 0 transmiten información a los servidores de Estrato 1, que transmiten información a los servidores de Estrato 2, y así sucesivamente en la jerarquía. Un enrutador, conmutador o punto de acceso doméstico común, como el que D-Link solicitó para direcciones de servidor NTP, tenía que enviar solicitudes al servidor Stratum 2 o Stratum 3.
El proyecto Chromium, probablemente con las mejores intenciones, repitió el problema NTP en el DNS cargando los servidores raíz de Internet con consultas que nunca deberían tener que manejar.
Hay esperanza de una solución rápida
Hay un error abierto en el proyecto Chromium que requiere que el Detector de redireccionamiento de intranet predeterminado esté desactivado para solucionar este problema. Hay que rendir homenaje al proyecto Chromium: se ha encontrado un error antes , Matt Thomas de Verisign atrajo su gran atención a su publicación en el blog de APNIC. El error fue descubierto en junio, pero permaneció en el olvido hasta la publicación de Thomas; después del ayuno, comenzó a ser observado de cerca.
Se espera que el problema se resuelva pronto y que los servidores DNS raíz ya no tengan que responder a aproximadamente 60 mil millones de consultas falsas todos los días.
Publicidad
Los servidores Epic son VPS de Windows o Linux con potentes procesadores AMD EPYC y unidades Intel NVMe muy rápidas. ¡Date prisa para hacer tu pedido!
