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á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).
