El DNS se trata como una infraestructura básica: usted señala los servidores de nombres, configura un registro A y un registro MX y se olvida. Lo que Cloudflare hace con un registro de proxy rompe esa premisa: el protocolo todavía existe, pero lo que sucede cuando activa el modo proxy cambia lo que significa DNS en su arquitectura.
¿Qué cambia cuando representas un registro?
Cuando crea un registro A en Cloudflare y habilita el proxy (el ícono de la nube naranja), la dirección IP que reciben sus clientes en la respuesta DNS no es su IP de origen. Cloudflare devuelve una de sus propias IP: direcciones que pertenecen a la red anycast de la empresa, distribuida en más de 300 puntos de presencia en todo el mundo.
Cada solicitud HTTP y HTTPS que llega a ese dominio ingresa a la red de Cloudflare antes de llegar a su servidor. TLS termina en el PoP más cercano al cliente. La WAF inspecciona la solicitud. Se aplican reglas de limitación de tarifas. Se consulta el caché. La mitigación de DDoS funciona en el borde. Sólo entonces, si la solicitud ha pasado por todas estas capas, se reenvía a su origen, en una conexión separada, a través de la red interna de Cloudflare. La dirección IP real de su servidor permanece oculta a cualquier cliente externo.
DNS, en este modelo, es el punto de entrada para toda la cadena de seguridad y rendimiento, no el servicio que lo precede.
Anycast: Por qué 300 PoP son importantes para la latencia
La mayoría de las redes operan con enrutamiento de unidifusión: cada IP se anuncia desde una única ubicación y el paquete recorre toda la distancia hasta ese centro de datos, independientemente de dónde se encuentre el cliente.
La red Cloudflare funciona con anycast: el mismo bloque de direcciones IP se anuncia simultáneamente desde cada uno de los más de 300 puntos de presencia, vía BGP. Cuando un cliente recibe una IP de Cloudflare en la respuesta DNS, la infraestructura BGP de Internet enruta el paquete al PoP geográficamente más cercano. TLS finaliza allí, a solo unos milisegundos del cliente. La ruta hasta su origen -que puede estar en otra región del mundo- se realiza a través de la red privada de Cloudflare, con rutas optimizadas entre PoPs, invisibles para el usuario final.
Propagación, TTL y la separación entre autoritativo y recursivo
En la oferta de DNS de Cloudflare coexisten dos funciones distintas, y confundirlas genera expectativas incorrectas durante los incidentes. El servicio autorizado (cuando delegas tu dominio a los servidores de nombres de Cloudflare) es el que responde con autoridad sobre tus registros. 1.1.1.1 es un solucionador recursivo público, un servicio independiente que consulta servidores autorizados en nombre de los clientes. Puedes usar servidores de nombres de Cloudflare para tu dominio sin tener que usar 1.1.1.1 y viceversa.
Cuando cambia un registro en el panel de Cloudflare, el cambio se propaga a través de la red autorizada en aproximadamente 30 segundos, una cifra impresionante para quienes provienen de proveedores que tardan horas en actualizar las zonas. El problema es que la "propagación" en el sentido de que afecta a usuarios reales depende de otra capa: los resolutores recursivos.
Los solucionadores como Google 8.8.8.8 y los solucionadores de ISP almacenan en caché las respuestas mediante el TTL del registro. Si el TTL estaba en 3600 segundos cuando un solucionador realizó la consulta, continuará respondiendo con el valor anterior por hasta una hora, incluso si Cloudflare ya entregó el nuevo registro durante 30 segundos. La "propagación completa" a todos los clientes toma exactamente el TTL máximo que estaba vigente en el momento del cambio.
El TTL predeterminado para registros sin proxy en Cloudflare es 300 segundos. Los registros proxy siempre exponen un TTL de 300 segundos externamente, independientemente del valor interno; Cloudflare necesita esta flexibilidad para administrar sus propias IP anycast. Antes de cualquier cambio planificado (migración de origen, conmutación por error, rotación de IP), el procedimiento correcto es reducir el TTL a 60 o 300 segundos de anticipación, esperar a que los resolutores actualicen el caché, ejecuten el cambio y aumenten el TTL más tarde. Hacerlo en orden inverso significa vivir con una propagación lenta exactamente cuando el costo es mayor.
CNAME Aplanamiento y el problema del ápice
La especificación DNS original prohíbe CNAME en el vértice del dominio (el propio exemplo.com sin un subdominio) porque entra en conflicto con los registros SOA y NS requeridos. Durante años, esto obligó a los equipos a arreglar las IP en el registro A del dominio raíz, creando fricciones con los servicios que no garantizan IP estáticas: los balanceadores de carga en AWS solo exponen nombres DNS, no IP.
Cloudflare resuelve esto con CNAME Flattening. Cuando configura un CNAME para el vértice, Cloudflare resuelve el objetivo en tiempo real (consultando A y AAAA del objetivo en el momento de la solicitud) y devuelve estas IP directamente al cliente. Desde el punto de vista del solucionador externo, es un registro A normal.
¿Qué requiere esto de quienes gestionan la producción?
Los equipos que tratan DNS como una configuración estática tienen problemas específicos cuando operan en Cloudflare. El modo de proxy de cada registro (activado o desactivado) determina si los sistemas de rendimiento y seguridad perimetrales interfieren o no. Un registro A con el proxy deshabilitado expone la IP real de la fuente, invalida la protección DDoS y elimina el WAF de la transmisión. Auditar qué registros son proxy y cuáles no no es una tarea de implementación inicial; debe ser parte del proceso de revisión de cambios.
TTL merece atención operativa continua. Un TTL alto reduce la carga autorizada y mejora el caché en los resolutores, pero aumenta el tiempo de recuperación para los cambios de ruta. La tolerancia del tiempo de propagación suele ser diferente entre registros críticos como MX y subdominios de servicios internos, y esta diferencia debe ser explícita en la configuración de la zona.
Monitorear activamente la propagación durante los cambios en el registro evita sorpresas. Herramientas como whatsmydns.net muestran qué diferentes resolutores de todo el mundo están regresando en ese momento. Cuando se realizó el cambio pero los usuarios aún informan una falla de acceso, la causa probable es un solucionador almacenado en caché durante mucho tiempo; la respuesta es esperar a que caduque el TTL, no apilar otro cambio de registro encima.
Lea también
- Balanceo de carga y dirección geográfica de Cloudflare: cuando DNS se convierte en una capa de tráfico inteligente
- DNSSEC con Cloudflare: qué protege, qué no protege y cómo activar sin problemas
- Enrutamiento de correo electrónico de Cloudflare: reciba correo electrónico en su dominio y lo que no está incluido
- Migración de DNS a Cloudflare: la lista de verificación que evita tres horas de apagones
- DNS proxy vs DNS solamente: qué cambia y cuándo tiene sentido cada modo
- Objetos duraderos de Cloudflare: estado consistente en el borde: lo que realmente cambia