Banda Ancha EU

Información independiente
sobre fibra, móvil y ADSL

hosting en interdominios

282

Google y OpenDNS presentan una mejora en el protocolo DNS para acelerar la navegación

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:

diagramadns.png

  • 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ás a 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).

Los comentarios más recientes se muestran primero. Haz click sobre un comentario para desplegar/plegar.
    • BocaDePez BocaDePez
      6

      No se qué pruebas de velocidad se pueden hacer, no es una…

      No se qué pruebas de velocidad se pueden hacer, no es una cosa de "con esto ganas un 20%". Este sistema te permite que, en el caso de servidores replicados alrededor del mundo (por ejemplo megaupload, supongo que sourceforge, y cosas así) que detectan cuál es tu servidor más cercano, no tengan dudas en determinados casos. Si tu servidor más cercano está más saturado en ese momento, tendrías menos velocidad que con el más alejado, con lo que no ganarías nada, pero la idea es que de esta manera se distribuya mejor la carga. También tendrás menor ping, pero no sé cómo afecta eso al rendimiento. Esto ayudará a que las empresas puedan balancear mejor la carga, al estar las peticiones mejor repartidas espacialmente, aunque tampoco se si hay tantos usuarios de openDNS/googleDNS/loqueseaDNS como para alterar las estadísticas. En cualquier caso, parece una buena medida.

      Sobre la privacidad, parece que no se den datos que no se dieran al DNS de tu compañía de teleco, así que supongo que no problema, y si está enmascarado, pues mejor aún.

      • En realidad sí se puede. Para el dominio adobe.com, empleando…

        En realidad sí se puede. Para el dominio adobe.com, empleando los openDNS, desde Sevilla => bajas acrobat a "x" Mbps. Para el mismo dominio, empleando el DNS propio del operador, desde Sevilla => bajas acrobat a "y" Mbps. Para el mismo dominio, empleando el DNS tuneado de Google, desde Sevilla => bajas acrobat a "z" Mbps.

        No puedes comparar las velocidades en sí, pero sí puedes estimar si la fuente CDN que se selecciona en cada caso es la más cercana o no.

        Por tanto, sí se puede medir en Mbps el efecto de esta técnica, ya que son Mbps diferentes los que se sirven desde cada punto de la red CDN.

        • BocaDePez BocaDePez
          6
          Creo que lo que pretenden, es reducir la latencia en las…

          Creo que lo que pretenden, es reducir la latencia en las consultas DNS, pero no va a cambiar la velocidad de internet por usar un DNS u otro, porque tambien puedes navegar sin DNS, y la velocidad es exactamente la misma.

          Para poner un ejemplo, es como mejorar el cambio de marchas en un coche, puede ser más rapido cambiando de marcha, pero no ganarás velocidad, sino aceleración.

          saludos. salva

          • No, ya que ni cambia a que servidor DNS consultas ni a…

            No, ya que ni cambia a que servidor DNS consultas ni a quienes este consulta.

            Lo que se busca es que la IP que te devuelva la consulta DNS sea la del servidor espejo de tal servidor que esté más cerca tuya y no la del que esté más cerca del servidor DNS que usas como ocurre ahora.

            Con ello lo que puede que mejore, que puede darse que no, es la latencia y caudal con el que te conectas al servidor al que quieres acceder por estar este más cerca tuya y haber menos cuellos de botella por el medio por los que pasar. Pero puede que el peor cuello de botella te lo encuentres en la ruta hacía ese servidor espejo más cercano, o que el propio servidor espejo más cercano vaya peor que los otros servidores espejos.

            Si no usas DNS, pues directamente eres tú el que elijes a cual de los servidores espejos de otro accedes. Si pones la IP de uno, pues a ese, y si pones la IP de otro, pues a ese otro.

  • ¿No implicaría esto que los servidores DNS a los que los…

    ¿No implicaría esto que los servidores DNS a los que los clientes se conectan sean capaces de mirar las direcciones originantes a nivel 3 y añadir a nivel 7 ese dato? ¿No hemos aprendido que mezclar la información de los niveles OSI es lo que ha provocado tantos problemas en IPv4 al surgir el NAT, los balanceos, el anycast y las decenas de técnicas avanzadas de redes?

    Es más sencillo fomentar que cada cliente use el DNS propio de su operador. Y si no lo usa, que se joda sufriendo las consecuencias de una recepción de contenidos ineficiente. Modificar un estándar para que CDN funcione mejor en casos anómalos o de que un ISP tenga mal servicio de DNS me parece absurdo. La forma ortodoxa de hacer esto bien, es que cada uno emplee el DNS que le corresponde. Así de sencillo.

    Conceptualmente puede que resuelva algo más que la solución que ya existe, pero si el IETF lo aprueba será porque se alejen del espíritu transparente y equilibrado con el que han construído casi todo. Técnicamente es una nueva puerta a los problemas y a los NAT de aplicación.

    Si me piden adivinar, el IETF debe responder que esa funcionalidad ya está resuelta y se basa en que cada cliente emplee su servidor DNS local (en su router o en su ISP).

  • BocaDePez BocaDePez
    6

    Supongo que no se enviará la ip privada del usuario... con…

    Supongo que no se enviará la ip privada del usuario... con eso no haces nada. En todo caso se va a enviar una ip publica de Internet para poder saber la zona a la pertenece el usuario

1