DNS proxy versus solo DNS: qué cambia y cuándo tiene sentido cada modo

La mayoría de los equipos que migran a Cloudflare consideran la elección entre nube naranja y nube gris como un detalle de configuración. Activan el proxy para todo, asumen que más protección siempre es mejor y descubren el error semanas después, cuando una base de datos comienza a devolver el tiempo de espera sin ningún mensaje de error, o cuando se dan cuenta de que la IP de origen siempre estuvo expuesta en los registros que realmente importaban.

¿Qué hace realmente el modo proxy?

Cuando un registro A o CNAME está en modo proxy, el DNS autorizado de Cloudflare no devuelve la IP de su servidor de origen. Devuelve una IP anycast del propio Cloudflare. El cliente se conecta a uno de los nodos perimetrales de la red, que completa TLS, inspecciona la solicitud y solo entonces reenvía el tráfico a su servidor (opcionalmente con el almacenamiento en caché habilitado, con reglas WAF aplicadas y los trabajadores interceptando la solicitud a mitad de camino).

La IP real del servidor está oculta al DNS público. Cualquier consulta externa al registro devuelve IP de Cloudflare, no la suya. Esto tiene implicaciones concretas: un atacante que quiera eludir WAF necesitaría descubrir la IP de origen a través de otros medios: registros filtrados, certificados TLS históricos en crt.sh, encabezados de correo electrónico o conexiones directas a servicios auxiliares que quedaron expuestos sin un proxy.

El TTL visible externamente es siempre de 300 segundos, independientemente de lo que esté configurado internamente en la zona. Cloudflare controla lo que los solucionadores externos reciben y almacenan en caché; la configuración interna es solo para la sincronización entre los propios servidores de nombres de Cloudflare.

Qué ofrece el modo solo DNS

Con el ícono gris, Cloudflare funciona exclusivamente como un DNS autorizado. La consulta de nombre devuelve la IP real del servidor. No hay terminación TLS en el borde, no hay WAF, no hay caché, no hay trabajadores en la ruta. El cliente se conecta directamente al servidor de origen y Cloudflare nunca ve el tráfico.

Para los registros MX, esta ausencia de proxy es obligatoria. El flujo de entrega de correo electrónico requiere que los servidores de envío se conecten directamente al servidor de correo electrónico indicado en el registro MX. Si el registro MX intentara pasar a través del proxy de Cloudflare, el SMTP llegaría a un nodo perimetral que no sabe qué hacer con el tráfico en el puerto 25, y el correo electrónico simplemente no llegaría. Cloudflare ni siquiera te permite habilitar el proxy en registros MX; El valor predeterminado es solo DNS y no se puede cambiar.

Lo mismo se aplica a cualquier servicio TCP que no sea HTTP o HTTPS en los puertos admitidos. El proxy de Cloudflare comprende HTTP/HTTPS en los puertos 80 y 443 y un conjunto restringido de puertos alternativos documentados: 8080, 8443 y algunos otros. Todo lo que esté fuera de este conjunto es invisible para el proxy.

La trampa de la base de datos detrás de un registro proxy

Este es el escenario que aparece más silenciosamente en los incidentes. Un registro A apunta a un servidor que ejecuta MySQL en el puerto 3306. El equipo activa el modo proxy porque "queremos más protección". El cliente intenta conectarse al puerto 3306, pero ahora se está conectando al nodo perimetral de Cloudflare, que no enruta tráfico TCP arbitrario. La conexión se abre, espera y se cierra debido a un tiempo de espera. No hay ningún mensaje de error claro. MySQL ni siquiera ve el intento de conexión.

Lo mismo ocurre con PostgreSQL en el puerto 5432, con Redis en el puerto 6379, con cualquier protocolo binario que no sea HTTP. El proxy simplemente descarta el tráfico que no puede interpretar. Para exponer estos servicios, el registro debe estar en modo solo DNS, y la consecuencia directa es que la IP del servidor es públicamente visible.

Los registros de subdominios para SSH directo también pertenecen a esta categoría. Si el equipo mantiene un registro ssh.exemplo.com que apunta a un servidor bastión, debe ser solo DNS. El proxy romperá la conexión de la misma manera.

Auditar lo expuesto en tu zona

La pregunta que vale la pena hacerse periódicamente es simple: ¿qué registros de zona están en modo solo DNS y el tráfico que pasa a través de ellos está protegido de alguna otra manera?

Los registros solo DNS exponen IP que se pueden usar para atacar el origen directamente, omitiendo cualquier regla WAF configurada en los registros proxy. Si un servidor aparece tanto en un registro proxy como en un registro exclusivo de DNS diferente, o si la IP estuvo expuesta en algún momento en el pasado y está indexada en servicios como Shodan, el efecto protector del proxy es parcial.

Para eliminar por completo la exposición de la IP de origen en los servicios HTTP, Cloudflare Tunnel resuelve el problema definitivamente. El servidor de origen establece una conexión saliente a la red Cloudflare utilizando el demonio cloudflared. El tráfico de usuario llega al borde, hace un túnel hacia el servidor y el servidor nunca necesita aceptar conexiones entrantes: no hay ningún puerto abierto ni IP expuesta. Para tráfico TCP arbitrario fuera de HTTP, Cloudflare Spectrum cubre este escenario pero es exclusivo del plan Enterprise.

Qué revisar antes de dar por cerrada la configuración

Las zonas que crecen con el tiempo acumulan registros creados en diferentes contextos, por diferentes personas, con intenciones que a veces no están documentadas. Un comodín *.exemplo.com en modo proxy es legítimo y útil para subdominios creados dinámicamente, pero puede enmascarar el hecho de que registros específicos dentro de ese comodín se crearon manualmente como DNS solo por razones que ya nadie recuerda.

Los registros TXT y CAA nunca se transfieren mediante proxy: son datos que los clientes deben leer directamente y Cloudflare no interfiere. SRV y NS también están fuera del proxy. En estos casos la interfaz ni siquiera presenta la opción.