Aunque a veces no seamos conscientes de ellos, muchas de las webs que visitamos cada día almacenan su contenido en CDN (Content Delivery Network) que hacen que contenido, normalmente estático, se entregue de una manera más veloz en función de la localización del usuario además de otras funcionalidades como protección a DDoS, WAF, despliegues HA, etc. Para entender cómo funciona el CDN de Akamai, podemos usar una web pública que haga uso de sus servicios. Una de ellas a nivel nacional en España es el Banco Santander. Manos a la obra.

Nota: Si quieres saltar los detalles técnicos o prefieres tener una visión más a alto nivel antes de los detalles de bajo nivel, recomiendo dirigirse a la sección Resumen y conclusiones al final del artículo.

Comenzamos resolviendo con la herramienta Dig su dominio público en Internet, primero lanzando una petición de resolución contra uno de los servidores DNS de Telefónica España (80.58.61.250):

dig_santander_telefonica

Aquí observamos como la respuesta al registro tipo A (Resolución hostname a dirección IP) nos devuelve un alias (tipo CNAME) apuntando a bancosantander.es.edgekey.net.y a su vez este alias resuelve a otro alias e2033.b.akamaiedge.net. Finalmente nos devuelve la dirección IP 95.100.114.171.

Si repetimos la misma operación contra el mismo dominio pero esta vez usando el DNS de Google (8.8.8.8) vemos lo siguiente:

dig_santander_8888

Vemos como los pasos de la resolución mediante alias son los mismos, sin embargo, la IP que nos devuelve es 104.83.31.141 la cual no coincide con la consulta anterior contra el mismo dominio. Probemos otro servidor más lejano, uno en Australia perteneciente a la operadora Telstra (121.212.249.173):

dig_santander_telstra

De nuevo, otra dirección IP diferente: 23.53.156.246.

Con esto comprobamos como para el mismo dominio dependiendo del servidor DNS al que preguntamos resuelve diferentes direcciones IP. En este punto varias cosas deberían llamarnos la atención, por un lado, vemos como todas las peticiones son resueltas al alias e2033.b.akamaiedge.net. sin importar donde esté el servidor DNS y por otra lo ya comentado de las diferentes IP. ¿Por qué este salto de registro CNAME? Bien, Akamai usa este salto intermedio para introducirnos en sus propia zona DNS. Esto lo podemos comprobar solicitando la lista de servidores de dominio de la zona b.akamaiedge.net. de la siguiente manera:

DNS de Telefonica España:

dig2_santander_telefonica

DNS Google:

dig2_santander_8888

DNS Telstra:

dig2_santander_telstra

Como vemos nos devuelve la misma lista de servidores en cualquier DNS resolver. Investiguemos uno de ellos.

DNS Telefónica España:

dig3_santander_telefonica

DNS Google:

dig3_santander_8888

DNS Telstra:

dig3_santander_telstra

Las IPs varían de nuevo. También podemos ver como la respuesta ha tardado más ms. cuanto más se aleja geográficamente el servidor DNS al que preguntamos, como es de esperar. Vayamos a analizar ahora la zona de autoridad de la que depende b.akamaiedge.net, es decir, akamaiedge.net:

Preguntemos al DNS de Google (cualquiera de los otros servidores DNS devuelve la misma lista):

dig4_santander_8888

Como vemos, nos devuelve los servidores DNS de la zona akamaiedge.net.

Para aclarar algo el enredo, se puede comprobar con dig fácilmente a que zona pertenece cada server viendo el flag aa (Authoritative Answer) cuando enviamos una petición para resolver la IP de uno de los servidores de la zona b.akamaiedge.net a un servidor (En este caso n6b.akamaiedge.net.) que es servidor autoritativo de akamaiedge.net.:

dig5_santander

De la misma forma podemos usar un pequeño “truco” (Esto es parte del protocolo en sí) para obtener las IPs de todos los servidores DNS de la zona akamaiedge.net preguntando a uno de sus servidores de los cuales es autoridad, y por tanto tiene conocimiento de los RR de tipo A que enviará en la additional section que se supone ayuda a evitar consultas posteriores si se presupone que se conoce la respuesta, como es el caso al estar en la misma zona de autoridad:

dig6_santander

Viendo la última respuesta y la Additional Section ya vemos las direcciones IP de los servidores. Si usamos por ejemplo la IP del servidor que estamos usando para los ejemplos anteriores a6-192.akamaiedge.net., (23.211.133.192) y dado que este es uno de los servidores de dominio superior a en la jerarquía dentro de la zona de Akamai, podemos empezar a hacer algo de análisis sobre ella para ver que está pasando.

Resolvamos primero la IP de este servidor para ver si varía dependiendo del DNS resolver usado:

DNS Telefónica España:

dig7_santander_telefonica

 

DNS Google:

dig7_santander_8888

 

DNS Telstra:

dig7_santander_telstra

En esta ocasión vemos que siempre resuelve la misma dirección IP. Indaguemos un poco más sobre esta IP. Primero hacemos un traceroute desde una Kali con nuestra IP en Madrid sin y con resolución DNS para verlo más detallado y claro:

traceroute1

Como tras varios saltos pasando por Madrid como en el salto 7 pertenece al AS5511 perteneciente a Orange (ISP donde se están haciendo las pruebas) llega al servidor DNS de Akamai. Hasta aquí todo correcto. ¿Qué pasa ahora si repetimos el resultado desde una IP en Australia?

Para ello podemos hacer uso de VPN, sin embargo no tenemos acceso a una, pero existen herramientas online que hacen esto por nosotros. Como por ejemplo https://pulse.turbobytes.com o http://www.traceroute.org/

Elegimos uno de la antes mencionada operadora Telstra: https://www.telstra.net/cgi-bin/trace. El resultado es el siguiente contra la misma IP de antes (23.211.133.192):

traceroute1_2

Vaya, parece que ha llegado a su destino pero pasando por unos saltos muy diferentes, con nada en común a los vistos anteriormente para la misma IP. Para asegurarnos podemos consultar a que ASN pertenecen las IPs de los tres últimos saltos:

he1

he2

he3

Vemos que no ha salido de la red de Telstra hasta llegar al ASN de Akamai donde reside la IP 23.211.133.192. Curioso, parece que la misma IP se está usando en varios destinos simultáneamente.

Lo mismo podemos observar desde varios servidores alrededor del planeta:

 

Berlin, Alemania:

 world_trace1

Vancouver, Canadá:

world_trace2

¿Qué está pasando aquí? La respuesta es Anycast. Básicamente los servidores DNS de Akamai se están publicando bajo la misma IP en diferentes lugares mediante BGP. Esto nos lo dice la propia Akamai si miramos el IRR del ASN al que pertenece esta IP (23.211.133.192), el ASN 21342:

he4_asn_anycast

En cualquier caso, ¿Cómo es esto posible? ¿No habría overlapping de IPs al estar todas en el dominio público de Internet? Simplificando muchísimo digamos que los routers que soportan BGP entre ASNs ven estas IPs como diferentes caminos para el mismo host aunque en realidad estos host son varios distribuidos hosts geográficamente. La razón por la que un cliente (es decir, nosotros cuando resolvemos la IP del Banco Santander) obtiene una dirección u otra radica en los protocolos de enrutamiento de capa 3 y sus métricas.

Por lo general, contra menor es la métrica obtenida en una de las rutas, nuestros paquetes irán por ese camino, con lo cual obtendremos respuesta del servidor más cercano a nosotros, lo cual obviamente influye en el tiempo de retardo y en última instancia en una mejor experiencia en el servicio que estén por encima de todo esto, en el caso de Akamai DNS.

Bien, pero con esto solo tenemos la resolución de DNS, ¿Y el contenido? El contenido nos vendrá dado en una IP Unicast que eso si, vendrá dada por el DNS que se supone tenemos más cercano. En nuestro caso nos podemos remitir a las tres primeras capturas de pantalla del artículo donde vemos las direcciones IP que se nos entregan. Para ver si eso puede tener impacto en la latencia de los contenidos servidos hagamos la siguiente prueba. Primero hacemos un traceroute a la IP que nos da el servidor de Telefónica España: 95.100.114.171:

traceroute2

Ahora hagamos lo mismo a la dirección que nos proporciona el DNS de Telstra 121.212.249.173:

traceroute3

Y por otro lado el retardo a la hora de hacer un ping a uno y otro servidor:

traceroute4

Los resultados hablan por sí solos tanto en retardo como en número de saltos.

 

Resumen y conclusiones:

La idea para poder analizar el funcionamiento de Akamai consiste en seguir la cadena de DNS que empieza en los DNS Akamai Edge Servers. Gracias al enrutamiento Anycast al hacer la petición del dominio www.bancosantander.es nos contesta un servidor DNS geográficamente cercano a nosotros (generalmente dentro del mismo IXP) el cual mediante consecutivas peticiones nos proporciona la IP unicast del servidor que también se encuentra cercano al cliente. Este servidor se encargará de entregarnos el contenido en caché con una latencia menor. El contenido que se encuentra en los Content Edge Servers es contenido en caché que Akamai se encarga de distribuir (usando un protocolo llamado Inter-Cache Control, ICP) en cada uno de sus Edge Servers a lo largo del mundo (o las regiones que sea necesario).

Esto quedaría representado a alto nivel en la siguiente figura

anycastmap

Nota: Esta imagen no coincide con la realidad tanto en localización de servidores como la sincronización interna de contenidos, es tan solo un ejemplo de cómo podría ser una arquitectura simplificada de Akamai.

Uno puede pensar que Anycast usado en DNS esto no ofrezca unas ventajas tan notables aunque, probablemente la razón por la que Akamai use este despliegue será la facilidad con la que podría redirigir el tráfico de un punto a otro de su CDN con tan solo modificar una entrada en sus DNS. Esto en el evento de un ataque DDoS, congestión por exceso de tráfico o problemas de red podría ser crítico para mantener un servicio disponible en cuestión de segundos y de manera seguramente automática. Hacer esto con BGP sería ciertamente más lento dado el tiempo de propagación de rutas.

También mencionar el hecho de usar tráfico UDP como DNS con anycast es mucho mas recomendable que usar conexiones TCP. Esto se debe a que protocolos stateful como TCP suelen tener sesiones muy largas en el tiempo (Como pueda ser consultar la web de un banco) con lo que cualquier error en la red podría hacer que nuestro tráfico se re-enrutase a otra localización con la consecuente perdida de la sesión TCP.

Otra conclusión al margen de esto, es que cambiar nuestro DNS a uno que se encuentre muy lejano geográficamente a nosotros puede repercutir en la velocidad de los servicios que estén bajo un CDN como Akamai dado que recibiremos los datos del servidor cercano asignado al DNS que hayamos puesto. Otra conclusión que he sacado durante esta investigación es que usar el famoso DNS de Google (8.8.8.8) no suele ser mala idea dado que la propia IP 8.8.8.8 funciona sobre Anycast. Esto mismo ocurre también con los propios servidores root que pese a ser 13 (de la A a la M), tienen +500 servidores físicos distribuidos por todo el mundo cuyas IPs están publicadas bajo Anycast.

Por supuesto hay muchos detalles que seguramente se estén pasando por alto en este análisis dado que el funcionamiento de un CDN como Akamai no es trivial, pero con esto podemos entender algo sobre el funcionamiento global de un CDN y el uso de DNS con Anycast para servir contenidos.

¡Saludos!