Atlasingeniería

Fundamentos de cloudSemi-SeniorTema 7Semi-Senior

DNS gestionado y CDN

El DNS decide a qué dirección va cada usuario y la CDN, desde dónde le llega el contenido. Las dos son la capa más barata de una arquitectura y la que más rápido mejora la experiencia, siempre que se entienda el caché: el de los resolvedores y el de los bordes.

Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.

Son las dos piezas que están delante de todo lo demás y las que menos atención reciben hasta que algo falla. El DNS traduce un nombre en una dirección; la CDN acerca el contenido al usuario.

Y las dos comparten el mecanismo que explica la mayoría de sus problemas: guardan copias, y esas copias sobreviven a los cambios. Entender los dos cachés es entender las dos piezas.

Los registros que se usan de verdad

RegistroQué haceCuándo se usa
A / AAAAApunta a una dirección IPv4 / IPv6Un servidor con dirección fija
CNAMEApunta a otro nombreUn balanceador o una CDN, cuya dirección cambia
Alias del proveedorComo un CNAME, pero funciona en la raíz del dominioPoner el sitio en ejemplo.com sin www
MXA dónde va el correo del dominioCorreo
TXTTexto arbitrarioVerificación de dominio, SPF, DKIM
NSQué servidores mandan sobre la zonaDelegar el dominio al proveedor

Antes de seguir, predecí

Se cambia un registro A con TTL de 24 horas y hay que migrar el servidor mañana. ¿Qué conviene hacer hoy?

Un DNS gestionado decide, no sólo traduce

La diferencia entre un DNS cualquiera y uno gestionado por el proveedor de nube es que el segundo puede responder distinto según quién pregunta y según el estado de los destinos.

PolíticaQué hacePara qué sirve
SimpleSiempre la misma respuestaLo normal
Por pesoReparte en proporciones configuradasDespliegue gradual entre dos versiones
Por latencia o proximidadManda a la región más cercana en tiempoSistemas multi-región
Por geografíaSegún el país de origenRequisitos legales o contenido local
Con chequeo de saludSaca de la respuesta a los destinos caídosConmutación entre regiones
Route 53, Cloud DNS y Azure DNS con Traffic Manager ofrecen variantes de estas políticas.

Qué hace realmente una CDN

Una CDN es un conjunto de puntos de presencia repartidos por el mundo que guardan copias del contenido y responden desde el más cercano al usuario. Lo obvio es que baja la latencia; lo que se subestima es cuánto trabajo le saca al origen.

El recorrido de un pedido

  1. El usuario resuelve el nombre y llega al borde más cercano.
  2. Si el borde tiene la copia y sigue fresca, responde ahí mismo: el origen no se entera.
  3. Si no la tiene, pide al origen, guarda la respuesta según las reglas de caché y la devuelve.
  4. Varios pedidos simultáneos del mismo recurso se agrupan en una sola consulta al origen.

Antes de seguir, predecí

Un sitio estático detrás de una CDN recibe un pico de 100.000 visitas. ¿Cuántas llegan al origen?
Qué se cacheaCómo se controlaCuidado
Archivos con hash en el nombreCaché muy largo, un añoNinguno: el nombre cambia al cambiar el contenido
HTMLCaché corto, o revalidaciónEs lo que hay que invalidar al desplegar
Respuestas de APICaché corto y por clave de caché explícitaCachear una respuesta personalizada se la sirve a otro usuario
Contenido privadoNo cachear, o URLs firmadasEs el error más caro de todos

Desplegar detrás de una CDN

La receta que evita la mayoría de los problemas

  1. Los archivos estáticos llevan hash en el nombre y caché largo. Un despliegue publica nombres nuevos, así que no hay nada que invalidar.
  2. El HTML tiene caché corto o pide revalidación en cada pedido: es el archivo que apunta a los demás.
  3. Invalidar es la excepción, no el mecanismo. Tarda, a veces se cobra, y si es parte del despliegue normal significa que las reglas de caché están mal.
  4. Publicar primero los archivos nuevos y después el HTML: al revés, hay una ventana en la que el HTML nuevo pide archivos que todavía no existen.
Más a fondo · nivel seniorCuando la CDN deja de ser sólo caché

Los bordes hoy ejecutan código, y eso mueve decisiones que antes vivían en el origen:

  • Terminar TLS y cortar ataques en el borde, donde hay capacidad de sobra, con el firewall de aplicaciones y los límites por IP configurados ahí y no en la aplicación.
  • Reescribir y rutear: pruebas A/B, redirecciones por país o por idioma y encabezados de seguridad que se agregan en el borde, sin tocar la aplicación.
  • Personalizar sin romper el caché: la clave de caché se ajusta en el borde para que lo común se comparta y sólo lo realmente personal vaya al origen.
  • Costo de salida: el tráfico servido desde el borde suele ser más barato que el que sale directo del almacenamiento o del cómputo, y los proveedores no cobran, o cobran menos, el tramo entre su origen y su propia CDN. En sitios con mucho tráfico esa diferencia es la que paga el servicio.

Cierre

Autoevaluación

¿Lo entendiste?

¿Por qué no se puede usar un CNAME en la raíz de un dominio?
Hay que migrar un servidor mañana y el TTL es de 24 horas. ¿Qué se hace hoy?
Una respuesta personalizada por cookie se cachea sin incluir la cookie en la clave de caché. ¿Qué pasa?
¿Cómo se evita tener que invalidar la CDN en cada despliegue?