Zonas y DNS: dónde encaja el Worker

Todas las lecciones anteriores dependían de una condición silenciosa: que el tráfico del hostname entre a Cloudflare. Esa condición vive en el DNS. Una zona, un registro y un interruptor —la nube naranja— deciden si tu hostname circula por el edge programable o va directo a un servidor ajeno. Esta lección te da el modelo mínimo pero correcto de zonas y DNS para que el enrutado de Workers deje de tener puntos ciegos.

Qué es una zona

Una zona es un dominio cuyo DNS gestiona Cloudflare. Es la unidad administrativa sobre la que se apoyan casi todas las features: routing, caché, WAF y, por supuesto, los Workers.

Para crearla, al “añadir un sitio” apuntas los nameservers de tu registrador a Cloudflare —el setup completo—, o delegas solo un hostname vía CNAME —el setup parcial—. A partir de ahí, Cloudflare es autoritativo para ese nombre y puede, además de responder DNS, interponerse como proxy inverso.

Proxied o DNS-only: la nube naranja

Cada registro A, AAAA o CNAME tiene un interruptor de estado de proxy. Es la decisión más importante del DNS en Cloudflare, y la que más fallos de enrutado silencia.

El estado de proxy no es un ajuste de rendimiento menor: es lo que decide si tu hostname vive dentro o fuera de la plataforma. Un registro gris convierte a Cloudflare en un simple directorio telefónico; uno naranja lo convierte en el intermediario de cada petición.

Puedes verificar el estado desde la terminal, sin abrir el panel:

# Que IP publica el hostname
dig +short app.ejemplo.com
# 104.16.x.x  -> rango de Cloudflare: esta proxied (nube naranja)
# 203.0.113.5 -> IP de tu servidor: esta en DNS-only (nube gris)

El registro sin origen

Y si tu Worker ES la aplicación y no hay servidor detrás, no tienes una IP real que poner en el registro. La solución idiomática es el registro sin origen (originless): un registro proxied que apunta a una dirección reservada de documentación, AAAA a 100:: o A a 192.0.2.0.

Como está proxied, Cloudflare intercepta la petición en el edge y tu Worker la atiende; la dirección reservada nunca recibe tráfico. Solo existe para que el registro sea válido y viaje por la nube naranja.

# Registro sin origen: proxied, no apunta a nada real
# Tipo  Nombre           Contenido   Proxy
# AAAA  app.ejemplo.com  100::       Proxied
# A     app.ejemplo.com  192.0.2.0   Proxied

El Worker en el flujo

Con esto se cierra el círculo del nivel. El estado de proxy del registro es lo primero que decide el destino de una petición, mucho antes que cualquier route o línea de código:

flowchart TD
A[Navegador resuelve el hostname] --> B{Registro proxied}
B -->|Si nube naranja| C[IP anycast de Cloudflare]
C --> D[En el edge actuan cache WAF y Workers]
D --> E[Tu Worker atiende la peticion]
B -->|No nube gris| F[IP real del origen]
F --> G[Trafico directo y Cloudflare no ve el HTTP]

Fíjate en la asimetría: la rama naranja llega a tu Worker; la gris ni siquiera roza el edge. Cambiar una nube de gris a naranja no toca tu código, pero es la diferencia entre que ese código exista o no para el mundo.