comentarios del lector
230
con la participación de 104 carteles, incluido el autor de la historia
Comparte esta historia
Compartir en Facebook
Compartir en Twitter
Compartir en Reddit
El navegador Chromium —de código abierto, padre ascendente 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 dominios inexistentes.
los
Detector de redireccionamiento de intranet
, que hace que las consultas falsas para "dominios" aleatorios sean estadísticamente improbables de existir, es responsable de aproximadamente la mitad del tráfico total que reciben los servidores DNS raíz del mundo. El ingeniero de Verisign Matt Thomas escribió un extenso blog de APNIC
correo
delineando el problema y definiendo su alcance.
Cómo funciona normalmente la resolución DNS
Agrandar
/
Estos servidores son la autoridad final que se debe consultar para resolver .com, .net, etc., y para decirle que 'frglxrtmpuf' no es un TLD real.
Jim Salter
DNS, o el sistema de nombres de dominio, es la forma en que las computadoras traducen nombres de dominio relativamente memorables 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 cantidad vertiginosa de búsquedas de DNS. Cuando analizamos la página principal de ESPN, contamos 93 nombres de dominio separados, desde a.espncdn.com hasta z.motads.com, ¡que debían realizarse para cargar completamente la página!
Para mantener la carga manejable para un sistema de búsqueda que debe dar servicio a todo el mundo, el DNS está diseñado como una jerarquía de muchas 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 máxima para todos los dominios que se encuentran debajo. Un paso arriba
aquellos
son los servidores raíz reales,
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 llega realmente a los servidores raíz, debido a la jerarquía de almacenamiento en caché multinivel de la infraestructura de DNS. La mayoría de las personas obtendrán su información de resolución de DNS directamente de su ISP. Cuando su dispositivo necesita saber cómo llegar
arstechnica.com
, la consulta se dirige primero a ese servidor DNS administrado por el ISP local. 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 tienen la respuesta almacenada en caché, la consulta eventualmente se envía directamente a los servidores autorizados para el dominio.
encima
el que estás tratando de resolver, por
arstechnica.com
, eso significaría consultar a los servidores autorizados para
com
sí mismo, en
gtld-servers.net
.
Anuncio publicitario
los
servidores gtld
El sistema consultado responde con una lista de servidores de nombres autorizados para el
arstechnica.com
dominio, junto con al menos un registro de "pegamento" que contiene la dirección IP para uno de esos servidores de nombres. Ahora, las respuestas se filtran de nuevo a lo largo de la cadena: cada reenviador pasa esas respuestas al servidor que lo consultó hasta que la respuesta finalmente llega tanto al servidor ISP local como a la computadora del usuario, y todos a lo largo de la línea almacenan en caché esa respuesta para evitar molestar. cualquier sistema "aguas arriba" innecesariamente.
Para la gran mayoría de estas consultas, el NS registra para
arstechnica.com
ya se almacenará en caché en uno de esos servidores de reenvío, por lo que no es necesario molestar a los servidores raíz. Sin embargo, hasta ahora estamos hablando de un tipo de URL más familiar, una que se resuelve en un sitio web normal. Las consultas de Chrome alcanzan un nivel superior
ese
, en el actual
root-servers.net
grupos en sí mismos.
Chromium y la prueba de secuestro de NXDomain
Agrandar
/
Chromium's "¿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.
Matthew Thomas
El navegador Chromium, 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, escribe tanto las URL reales como las consultas del motor de búsqueda en el mismo cuadro de texto en la parte
superior de su navegador. Llevando la facilidad de uso un paso más allá, no te obliga a escribir elhttp: //
o
https: //
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; por ejemplo, cualquier cosa que tenga espacios no será una URL. Pero se vuelve complicado cuando se consideran las intranets: redes privadas, que pueden usar TLD igualmente privados que se resuelven en sitios web reales.
Si un usuario de 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 le pregunta al usuario si pretendía buscar "marketing" o navegar a
https: // marketing
. Hasta ahora, todo va bien, pero muchos ISP y proveedores de Wi-Fi compartido secuestran cada URL mal escrita, redirigiendo al usuario a una página de destino cargada de anuncios de algún tipo.
Generar aleatoriamente
Los autores de Chromium no querían tener que ver barras de información de "quiso decir" en cada búsqueda de una sola palabra en esos entornos comunes, por lo 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 15 caracteres. Si dos de esas 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 solo trata todas las entradas de una sola palabra como intentos de búsqueda hasta nuevo aviso.
Anuncio publicitario
Desafortunadamente, en las redes que
no son
secuestrando los resultados de las consultas de DNS, esas tres búsquedas tienden a propagarse hasta los servidores de nombres raíz: el servidor local no sabe cómo resolver
qwajuixk
, por lo que devuelve esa consulta a su reenviador, que devuelve el favor, hasta que finalmente
a.root-servers.net
o uno de sus hermanos tiene que decir "Lo siento, 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 parte
cada
una de estas sondas emitidas en una red honesta eventualmente molesta al servidor raíz. Esto se suma a una friolera
mitad
la carga total en los servidores DNS raíz, si nos basamos en las estadísticas de la parte de Verisign del
root-servers.net
racimos.
La historia se repite
Esta no es la primera vez que un proyecto bien intencionado
inundado
o casi inundó un recurso público con tráfico innecesario: inmediatamente nos recordaron la larga y triste historia de D-Link y el servidor NTP (Protocolo de tiempo de red) de Poul-Henning Kamp, de 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 factura de ancho de banda enorme e inesperada. Para abreviar la historia, los desarrolladores de D-Link codificaron las direcciones del servidor NTP Stratum 1, incluidas las de Kamp, en el firmware de la línea de conmutadores, enrutadores y puntos de acceso de la empresa. Esto inmediatamente multiplicó por nueve el uso del ancho de banda del servidor de Kamp, lo que provocó que el intercambio de Internet danés cambiara su factura de "Gratis" a "Eso será $ 9,000 por 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 está diseñado para operar de manera jerárquica: los servidores de estrato 0 alimentan a los servidores de estrato 1, que alimentan a los servidores de estrato 2, y en el futuro. Un enrutador, conmutador o punto de acceso doméstico simple como los que D-Link había codificado en estos servidores NTP debería estar consultando un servidor Stratum 2 o Stratum 3.
El proyecto Chromium, presumiblemente con las mejores intenciones en mente, ha traducido 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 abierto
insecto
en el proyecto Chromium solicitando que el Detector de redireccionamiento de intranet se deshabilite de forma predeterminada para resolver este problema. Para ser justos con el proyecto Chromium, el error se abrió
antes de
Matt Thomas de Verisign trazó un círculo rojo gigante alrededor del tema en su blog de APNIC
correo
. 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 necesitarán responder alrededor de 60 mil millones de consultas falsas todos los días.
Listado de imagen por
Matthew Thomas
