Una función de Chrome está creando una gran carga en los servidores DNS raíz globales

El navegador Chromium, un padre ascendente de código abierto tanto de Google Chrome como del nuevo Microsoft Edge, está recibiendo mucha atención negativa por una función bien intencionada que verifica si el ISP de un usuario está «secuestrando» resultados de dominio inexistentes.

El Detector de redireccionamiento de intranet, que hace estadísticamente improbable que existan consultas falsas para «dominios» aleatorios, representa casi la mitad del tráfico total que reciben los servidores DNS raíz del mundo. El ingeniero de Verisign Matt Thomas escribió una publicación extensa en el blog de APNIC describiendo el problema y definiendo su alcance.

Cómo suele funcionar la resolución DNS

Estos servidores son la autoridad final a la que se debe consultar para resolver .com, .net, etc., y para decirle que 'frglxrtmpuf' no es un verdadero TLD.
Estos servidores son la autoridad final a la que se debe consultar para resolver .com, .net, etc., y para decirle que ‘frglxrtmpuf’ no es un verdadero TLD.

DNS, o Domain Name System, es la forma en que las computadoras traducen nombres de dominio relativamente fáciles de recordar, como arstechnica.com, en direcciones IP mucho menos memorables, como 3.128.236.93. Sin DNS, Internet no podría existir en una forma utilizable por humanos, lo que significa que la carga innecesaria en su infraestructura de nivel superior es un problema real.

La carga de una sola página web moderna puede requerir una asombrosa cantidad de búsquedas de DNS. Cuando miramos la página de inicio de ESPN, contamos 93 nombres de dominio separados, desde a.espncdn.com hasta z.motads.com, ¡que debían ejecutarse para cargar completamente la página!

Para mantener la carga manejable para un sistema de búsqueda que debe servir a todo el mundo, el DNS fue diseñado como una jerarquía de múltiples etapas. 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 final para cada dominio debajo de él. Un paso arriba Ese son los verdaderos servidores raíz, a.root-servers.net mediante m.root-servers.net.

¿Con qué frecuencia ocurre esto?

Un porcentaje muy pequeño de las consultas de DNS del mundo llegan realmente a los servidores raíz, debido a la jerarquía de caché multinivel de la infraestructura de DNS. La mayoría de las personas obtendrán la información de resolución de DNS directamente de su ISP. Cuando el dispositivo necesita saber cómo acceder a arstechnica.com, la consulta se dirige primero al servidor DNS local administrado por el ISP. Si el servidor DNS local no conoce la respuesta, reenviará la consulta a sus propios «reenviadores», si hay alguno definido.

Si ni el servidor DNS local del ISP ni ningún «reenviador» definido en su configuración tiene la respuesta en caché, la consulta eventualmente irá directamente a los servidores autorizados del dominio. arriba ¿Qué estás tratando de resolver? arstechnica.com, eso significaría consultar servidores autorizados para com sí mismo, en gtld-servers.net.

los gtld-servers El sistema consultado responde con una lista de servidores de nombres autorizados para el dominio arstechnica.com, junto con al menos un registro «adhesivo» que contiene la dirección IP de uno de estos servidores de nombres. Las respuestas ahora se filtran hacia abajo en la cadena: cada reenviador pasa esas respuestas al servidor que las consultó hasta que la respuesta finalmente llega al servidor ISP local y a la computadora del usuario, y todas a lo largo de la caché de línea que responde para evitar perturbar innecesariamente cualquier sistema aguas arriba.

Para la gran mayoría de estas consultas, los registros NS para arstechnica.com ya estará almacenado en caché en uno de estos servidores de reenvío, por lo que no es necesario alterar los servidores raíz. Sin embargo, hasta ahora estamos hablando de un tipo de URL más familiar, uno que se refiere a un sitio web normal. Las consultas de Chrome han alcanzado un nivel superior a esoen lo real root-servers.net los propios grupos.

Chromium y la prueba de secuestro de NXDomain

Cromo "¿Este servidor DNS está conmigo?" las sondas representan aproximadamente la mitad de todo el tráfico que llega al clúster de servidores raíz DNS de Verisign.
Ampliar / Chromium’s «¿este servidor DNS está mal conmigo?» las sondas representan aproximadamente la mitad de todo el tráfico que llega al clúster de servidores raíz DNS de Verisign.

El navegador Chromium, el proyecto principal de Google Chrome, el nuevo Microsoft Edge y muchos otros navegadores menos conocidos, quiere ofrecer a los usuarios la simplicidad de una búsqueda de un solo cuadro, a veces conocida como «Omnibox». En otras palabras, ingresa las URL reales y las consultas del motor de búsqueda en el mismo cuadro de texto en la parte superior del navegador. Llevando la facilidad de uso un paso más allá, no te obliga a escribir el http:// o https:// también parte de la URL.

Por más conveniente que sea, este enfoque requiere que el navegador comprenda qué debe tratarse como una URL y qué debe tratarse como una consulta de búsqueda. En su mayor parte, esto es bastante obvio: cualquier cosa con espacios no será una URL, por ejemplo. Pero se complica cuando considera las intranets: redes privadas, que pueden usar TLD igualmente privados que se resuelven en sitios web reales.

Si un usuario en la intranet de una empresa escribe «marketing» y la intranet de esa empresa tiene un sitio web interno con el mismo nombre, Chromium muestra una barra de información que pregunta al usuario si pretendía buscar «marketing» o navegar a https://marketing. Hasta ahora, todo bien, pero muchos ISP y proveedores de Wi-Fi compartido secuestran todas las URL mal escritas, redirigiendo al usuario a una página de destino cargada con anuncios de algún tipo.

Generar aleatoriamente

Los autores de Chromium no querían ver barras de información de «usted quiso decir» en cada búsqueda de palabras en estos entornos comunes, así que implementaron una prueba: al inicio o cambio de red, Chromium emite búsquedas de DNS para tres siete generados aleatoriamente. «dominios» de nivel superior de hasta 15 caracteres. Si dos de estas solicitudes regresan con la misma dirección IP, Chromium asume que la red local está secuestrando la NXDOMAIN errores que debería recibir, por lo que trata todas las entradas de una sola palabra como intentos de búsqueda hasta nuevo aviso.

Desafortunadamente, en redes que no son secuestrando los resultados de las consultas de DNS, estas tres búsquedas tienden a propagarse a los servidores de nombres raíz: el servidor local no sabe cómo resolver qwajuixk, luego devuelve esta consulta a su reenviador, quien le devuelve el favor, hasta que finalmente a.root-servers.net o uno de tus hermanos tiene que decir «Lo siento, este no es un dominio».

Dado que hay alrededor de 1,67 * 10 ^ 21 posibles nombres de dominio falsos de siete a 15 caracteres, en su mayoría cada una de estas sondas emitidas en una red honesta eventualmente trastorna un servidor raíz. Esto resulta en una enorme medio la carga total en los servidores DNS raíz, si nos atenemos a las estadísticas de la parte de Verisign de root-servers.net racimos.

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: D-Link y Poul-Henning Kamp, el desde mediados de la década de 2000.

En 2005, Poul-Henning Kamp, un desarrollador de FreeBSD, que también dirigía el único servidor de protocolo de tiempo de red Stratum 1 de Dinamarca, recibió una cuenta de ancho de banda enorme e inesperada. Para abreviar la historia, los desarrolladores de D-Link codificaron las direcciones del servidor NTP Stratum 1, incluido Kamp, en firmware para la línea de conmutadores, enrutadores y puntos de acceso de la compañía. Esto aumentó de inmediato el uso de ancho de banda del servidor Kamp en nueve veces, lo que provocó que el intercambio danés de Internet cambiara su cuenta de «Gratis» a «Esto costará $ 9,000 al año, por favor».

El problema no era que hubiera demasiados enrutadores D-Link, era que estaban «saltando la cadena de mando». Al igual que el DNS, NTP fue diseñado para operar jerárquicamente: los servidores de Estrato 0 alimentan a los servidores de Estrato 1, que alimentan a los servidores de Estrato 2, etc. Un enrutador, conmutador o punto de acceso doméstico simple como aquellos en los que D-Link encripta estos servidores NTP debe referirse a un servidor Stratum 2 o Stratum 3.

El proyecto Chromium, presumiblemente con las mejores intenciones en mente, convirtió el problema de NTP en un problema de DNS al cargar los servidores raíz de Internet con consultas que nunca deberían tener que procesar.

Resolución con suerte a la vista

Hay un error abierto en el proyecto Chromium que solicita que el Detector de redireccionamiento de intranet se desactive de forma predeterminada para resolver este problema. Para ser justos con el proyecto Chromium, el error se abrió antes de Matt Thomas de Verisign dibujó un círculo rojo gigante alrededor del problema en su publicación de blog de APNIC. El error se abrió en junio, pero languideció hasta la publicación de Thomas; desde la publicación de Thomas, ha recibido atención diaria.

Con suerte, el problema se resolverá pronto y los servidores DNS raíz del mundo ya no tendrán que responder alrededor de 60 mil millones de consultas falsas todos los días.

Imagen de lista de Matthew Thomas