Categoría: Técnico

Justamente hace un año, contábamos cómo desinstalar la extensión que Microsoft agregaba de forma encubierta a Firefox mediante una de las actualizaciones de Windows. Ahora nos la vuelve a jugar, esta vez con su buscador: Bing.

A menudo —supongo que muchos de vosotros haréis lo mismo—, utilizo la barra de direcciones de Firefox directamente para realizar búsquedas gracias a la funcionalidad por la cual, cuando introducirmos una URL inválida, el navegador automáticamente busca esas palabras en el proveedor de búsquedas predeterminado. En mi caso es Google. Mas mayúscula ha sido mi sorpresa cuando, al introducir «renfe» en la barra de direcciones para que Google me redirigiera automáticamente a la página de la compañía, me ha aparecido una búsqueda en Bing (!?).

Lo primero que hago es lo obvio: me dirijo a las opciones de configuración de Firefox introduciendo en la barra de direcciones about:config y busco la siguiente clave:

¿Cómo es posible que el navegador busque en Bing si el buscador configurado es Google? Lo siguiente que hago es poner a false la preferencia keyword.enabled, y aun así ¡sigue funcionando la búsqueda en la barra de direcciones! Al recordar lo del año pasado, he comprobado que no hubiera ningún complemento instalado de manera furtiva, y no lo había. ¿Qué podía ser entonces?

Tras varias vueltas por los foros de Mozilla, he visto que había más gente con el mismo problema, pero nadie apuntaba una solución. Finalmente, este usuario me ha dado la clave: Actualización de seguridad acumulativa de Internet Explorer 8 para Windows 7 en sistemas basados en x64 (KB982381), así se llama el culpable. Tras desinstalar esta actualización y tras el correspondiente reinicio del sistema, mi Firefox ha vuelto a la normalidad y las búsquedas ya no se realizan en Bing sin mi consentimiento. Por último, la he ocultado en Windows Update, por supuesto.

¿Por qué una actualización que se supone que es para Internet Explorer tiene que modificar nada en Firefox sin preguntarnos? Por este tipo de detalles tan feos es tan odiado Microsoft. Parece mentira que no se den cuenta.

Actualización: leo en Meneame que otra actualización, la KB982217, instala una extensión llamada Search Helper Extension. El problema explicado en esta entrada es otro, puesto que en mi PC no aparece esa actualización ni tampoco esa extensión, sino que el único síntoma es que las búsquedas se realizan en Bing.

Este tema empieza a ser redundante. Sobre todo después de que, hace más de dos años, lo explicaran en Microsiervos (y por ello, sería referenciado en miles de sitios), ya debería estar bastante clarito. Sin embargo, he comprobado que no, que hace falta volver a explicarlo.

Sigo Bandaancha.eu desde hace tiempo, casi tanto como a los propios Microsiervos. Engloba a una gran comunidad de usuarios, y los artículos y análisis que allí aparecen relacionados con el mundo de Internet suelen ser de calidad. Eso sí, nunca había dejado comentarios, hasta ayer, debido a que detecté una pequeña incorrección en un artículo que explica por qué los DNS del operador son mejores. En él se dice que la resolución de nombres es más rápida en el DNS del operador que en el de Google, por ejemplo, aunque en el de Google esté cacheado y en el del operador no; afirmación que me hubiera creído de no ser porque hace unas semanas realicé un pequeño estudio al respecto. Así que, sin más, me pasé por los comentarios de la noticia para dejar constancia de que Google y OpenDNS son más rápidos cuando hay que responder ante dominios «raros». Mi comentario ha pasado desapercibido, al parecer. Pero bueno, no iba por eso este artículo.

El caso es que voy realizando el correspondiente seguimiento de mi comentario para ver si alguien contesta y durante el proceso leo otros. Como en toda discusión sobre DNS que se precie, enseguida sale alguien diciendo que existen sólo 13 Root Servers (habría que enunciar algún tipo de ley, como la de Godwin, al respecto). Yo esperaba que algún otro usuario lo desmintiera, pero como no ocurría, lo hice yo —sin mayor explicación, pensando que no sería necesaria—. Pues bien, enseguida se me tachó de «atrevido ignorante», de listillo, de desconocer totalmente el tema y de no saber leer.

Confieso que me sorprendió la actitud y las respuestas, pero claro, una vez que lo piensas… Qué puedes esperar de una comunidad con más de cien mil seguidores vía feed, otros casi cien mil usuarios registrados, y no sé cuántas visitas y comentaristas anónimos cada día. Pues lógicamente, donde se reúne tanta gente, hay mucha gente inteligente, y también mucho imbécil y mucho meapilas.

Así que, ante el desconocimiento que veo que todavía hay, valga este artículo como enésima explicación. Primero la manera corta, con enlace a la ICANN: There are NOT 13 root servers.

Y ahora la manera larga. Tradicionalmente se dice que existen 13 Root Servers, que se corresponden con las letras de la A a la M para llamarlos de la forma letter.root-servers.net. ¿Por qué 13? Es una cuestión de limitaciones del protocolo DNS. Ahora bien, ¿os imagináis el pifostio que se montaría si sólo 13 servidores físicos se encargasen de las peticiones de todo el mundo? ¿Os imagináis qué pasaría si Google tuviera sólo un servidor para atender a todo el mundo? No es lógico.

Para eso surgió el direccionamiento anycast que, de una manera resumida, funciona de la siguiente forma: yo tengo 2, 10 ó 2000 servidores exactamente iguales (NO hay uno original y réplicas, porque son todos iguales) y con la misma IP, y los distribuyo por todo el mundo; cada vez que se realice una petición desde una máquina, ésta (la petición) se encaminará hacia el servidor más cercano geográficamente —por una cuestión de funcionamiento de los protocolos de encaminamiento que ahora no viene al caso—.

De esta manera, existen más de un centenar de Root Servers repartidos por todo el mundo, de hecho, podéis ver hasta dónde se encuentran.

En la anotación anterior, llegamos a la conclusión de que no es cierto que Google tenga sus servidores DNS en Mountain View, sino que ya los ha distribuido por todo el mundo —sería estúpido por su parte no hacerlo así—, así que la disponibilidad geográfica está más que garantizada. Otra opción para comprobar que, efectivamente, existen multitud de DNS utilizando direccionamiento anycast, es seguir esta URL donde se hace un ping desde varios puntos del mundo y se nos muestra el RTT.

En los comentarios, un lector nos apuntaba que otro análisis interesante sería realizar peticiones de dominios que no estuvieran cacheados —por lo que tendrían que realizar una petición a un DNS superior en la jerarquía—, para ver con qué velocidad se desenvuelven en ese escenario. Así pues, he modificado el script y ha quedado de esta manera:

[code lang=»bash»]#!/bin/bash

dic="dictionary.txt"
dominios="dominios_comunes.txt"
servers=(80.58.61.250 192.168.1.1 8.8.8.8 208.67.222.222)
muestras=50
for n in {0..3}
do
server=${servers[@]:n:1}
while read dominio
do
a=$(dig @${server} ${dominio} | grep "Query time")
echo ${a:15:${#a}-20} >> "${server}_conocidos"
done < $dominios

for ((i=1; i<=muestras; i++))
do
rand=$(shuf -n 1 $dic)
rand=${rand:0:${#rand}-1}
dominio="$rand.com"
a=$(dig @${server} ${dominio} | grep "Query time")
echo ${a:15:${#a}-20} >> "${server}_raros"
done
done[/code]

El primer bucle interior lo que hace es leer del archivo «dominios_comunes.txt» unos dominios que a mí me han parecido bastante comunes, y por lo tanto con una alta probabilidad de estar cacheados en todos los servidores DNS a estudiar. La gráfica resultante es muy parecida, por consiguiente, a la obtenida el otro día. Tan sólo hay un cambio: esta vez disponía de un router viejo y podemos apreciar que los tiempos que nos ofrece el DNS del router por defecto (192.168.1.1) son muy malos —más de 50 ms por encima de Google y OpenDNS y 100 ms peor que el DNS del ISP—.

El segundo bucle interior hace uso del archivo «dictionary.txt». Se me ha ocurrido que la mejor manera de dar con dominios raros que no estuviesen cacheados —dado que pones cualquier palabra en inglés en el navegador, añades «.com», y existe—, era utilizar un diccionario de inglés, extraer una palabra aleatoriamente, y añadir el punto com. Eso es precisamente lo que hace ese pedazo de código. Aquí va la gráfica:

Y aquí ya sí que se aprecian diferencias significativas. Veamos los tiempos medios para aclararnos un poco:

• DNS del ISP (80.58.61.250): 624 ms de media.
• DNS del ISP router mediante (192.168.1.1): 802 ms de media.
• OpenDNS (208.67.222.222): 370 ms de media.
• Google Public DNS (8.8.8.8): 415 ms de media.

Vemos que el DNS del ISP consigue tiempos mediocres con dominios no cacheados. Google Public DNS todavía tiene camino por recorrer y mucho que aprender de su competidor OpenDNS, pero obtiene un meritorio segundo puesto teniendo en cuenta que es un servicio recién aparecido.

El pasado 3 de diciembre Google anunciaba el lanzamiento de un nuevo proyecto llamado Google Public DNS, que, como su propio nombre indica, es un nuevo servidor DNS público que sigue la estela marcada por OpenDNS. De esta manera, disponemos de una alternativa más a la hora de configurar nuestros DNS que además es muy fácil de recordar: 8.8.8.8 y 8.8.4.4. La noticia ha sido acogida con entusiasmo por la blogosfera: Google se ha impuesto como meta acelerar la navegación web, y apuesta por los estándares, la neutralidad de la red, la seguridad y la privacidad, compromiso que viene avalado por una trayectoria (hasta el momento) impecable.

Hasta aquí son todo ventajas. Tan sólo hay una gran pega que se le podría poner: su situación geográfica. Y es que, al parecer, recalco, al parecer, los DNS de Google se encuentran en su sede de Mountain View (California). Cruzar el charco y todo el continente americano para hacer una petición de resolución de nombre no parece muy buena idea, desde luego. Pero recuerden: al parecer.

Me he propuesto hacer una pequeña comparativa del retardo introducido por el DNS del ISP (en este caso Telefónica, luego utilizo el típico 80.58.61.250), el de OpenDNS (208.67.222.222) y el nuevo de Google (8.8.8.8). También he introducido en la comparativa la dirección del router ADSL (192.168.1.1), ya que mucha gente tiene configurada la conexión con esa dirección en el DNS. En esos casos, el router tiene configurado el DNS del ISP al fin y al cabo y, por lo tanto, el retardo debería ser equivalente. Sucede así en los datos recogidos, pero he comprobado que depende mucho del router: si es muy lento, puede introducir un retardo adicional muy grande.

Para la recogida de datos, he elaborado un pequeño script en Bash. Los gurús de la programación en Bash verán que no es muy académico que digamos, pero funciona, que es lo importante (si alguien me propone mejoras, estaré encantado de aprender).

[code lang=»bash»]#!/bin/bash

muestras=100
servers=(80.58.61.250 192.168.1.1 8.8.8.8 208.67.222.222)
for n in {0..3}
do
server=${servers[@]:n:1}
for ((i=1; i<=muestras; i++))
do
a=$(dig @${server} enchufa2.es | grep "Query time")
echo ${a:15:${#a}-20} >> $server
done
done[/code]

Lo que hace este script es realizar 100 peticiones por cada DNS que vamos a analizar y guardar los tiempos de respuesta en sendos archivos. Y con dichos archivos y Gnuplot he obtenido la siguiente gráfica:

Como podemos ver, el retardo introducido por los DNS del ISP es de unos 60 ms. De este tiempo, la mayor parte es debido al modo interleaved de la conexión ADSL, pero eso ya es otra historia (es un método para lograr mayor protección contra errores en el que los bits de las tramas se van entrelazando de manera que se recibe el primer bit de varias tramas, luego el segundo bit de todas ellas, etc.; resumiendo, no recibes el bit N de una trama hasta que no has recibido los N-1 bits de su «grupo» de tramas, por lo que aumenta el retardo considerablemente).

También observamos que OpenDNS y Google rondan los 100 ms (OpenDNS parece que gana, de media, por poquito). Por lo tanto, el retardo adicional que introducen tanto OpenDNS como Google Public DNS es de 40 ms.

No he hecho un estudio exhaustivo sobre el número de peticiones DNS que se realizan al cargar páginas web, pero por el puñado de pruebas que he hecho, diría que se realizan normalmente menos de 10 (no cuento aquí la resolución de todos los enlaces incluidos en el documento HTML, puesto que esto se hace después de la carga de la página y no repercute en la experiencia del usuario). ¿Esto qué supone? Pues un retardo adicional de menos de medio segundo en páginas que tardan en cargar 3, 4, 5, 6 segundos… Por lo tanto, la latencia no se verá muy afectada.

Por otra parte, ¿no os chirrían un poco esos 100 ms junto con la localización en la costa oeste de los EEUU? Si hacemos un ping a haha.nu (servidor situado por el centro de EEUU), descubrimos un tiempo de respuesta de 170 ms, y si lo hacemos con enchufa2.es (situado hacia la costa este de EEUU), tenemos 180 ms. Más raro todavía: si hacemos un traceroute a 8.8.8.8 descubrimos que uno de los saltos está en París con un tiempo de respuesta de 95-100 ms y que ¡el siguiente salto está en California con un tiempo de 95-100 ms! Probad también con OpenDNS; sucede algo parecido.

Conclusión: o bien han inventado los enlaces transoceánicos y transcontinentales instantáneos y yo no me he enterado, o tanto OpenDNS como Google Public DNS tienen servidores en Europa.