Cómo usan las CDN el DNS para enrutar el tráfico global

La promesa central de una CDN es servir el contenido desde un servidor físicamente cercano a cada visitante, en lugar de que un único servidor de origen fijo atienda al mundo entero. El mecanismo que lo hace posible, en la mayoría de las implementaciones, es el DNS: en concreto, dar a distintos visitantes respuestas diferentes a exactamente la misma consulta.

El mismo dominio, otra respuesta, a propósito

Cuando un dominio está detrás de una CDN, sus registros DNS suelen apuntar (a menudo mediante un CNAME) a la infraestructura propia del proveedor de la CDN y no a una única IP de origen. Los servidores de nombres de la CDN responden entonces a cada consulta entrante según el lugar desde el que parece originarse, devolviendo la dirección IP de la ubicación de borde más cercana, o la menos cargada, para ese visitante concreto. Dos personas en lados opuestos del mundo que consultan el mismo dominio pueden, correctamente, recibir dos direcciones IP completamente distintas.

• Por eso, si una misma consulta de dominio a IP se hace dos veces desde dos ubicaciones distintas, que los resultados difieran no es un error: es el sistema funcionando como debe.
• También es la razón de que los dominios detrás de una CDN tiendan a resolverse a varias direcciones en consultas repetidas: no hay una respuesta «correcta», solo respuestas adecuadas en cada momento.
• Es habitual que estos registros tengan un TTL corto precisamente para que la CDN pueda desviar el tráfico con rapidez lejos de una ubicación de borde con problemas, sin esperar a que venza una ventana de caché larga.

Qué significa esto cuando estás depurando

Si un sitio detrás de una CDN se comporta de forma extraña para unos visitantes y no para otros, comprobar a qué resuelven el dominio distintos puntos de observación suele ser la forma más rápida de confirmar si el problema es una ubicación de borde concreta y no el origen ni la propia aplicación. Una herramienta que resuelve directamente y muestra la respuesta en bruto, sin la caché DNS de un navegador por delante, da una lectura más limpia de lo que se está sirviendo ahora mismo a una región determinada.

La dirección real del servidor de origen está oculta a propósito

Un efecto secundario que conviene conocer: resolver un dominio detrás de una CDN te da la dirección de la red de borde, no la del servidor de origen que hay detrás, y eso suele ser intencionado, no accidental. Mantener la IP real del origen fuera del DNS público es una de las defensas más sencillas y eficaces que tiene un sitio contra un ataque de denegación de servicio directo dirigido a la infraestructura real y no a la capacidad, mucho mayor, de la CDN que hay delante. También significa que una consulta de dominio por sí sola no puede decirte dónde está «realmente» alojado un sitio, sino solo por dónde entra su tráfico actualmente en la red de la CDN, que es una pregunta bastante distinta.

Consultar el WHOIS o el ASN de una dirección resuelta

Una forma rápida y práctica de confirmar si un dominio está detrás de una CDN es comprobar quién es el titular de la dirección IP resuelta, por separado de la consulta del dominio en sí. Una dirección resuelta registrada bajo el número de sistema autónomo (ASN) de una CDN o de un proveedor de nube conocido es una señal fuerte de que estás ante una red de borde y no ante un servidor de origen, y explica de inmediato por qué el mismo dominio puede mostrar una dirección distinta desde otra región sin que nada esté mal. Es un segundo paso útil después de una consulta, no un sustituto: la respuesta DNS te dice la dirección actual, y la consulta de titularidad te dice a qué tipo de infraestructura pertenece realmente esa dirección.