Cloudflare DNS a fondo: registros, nube naranja, TTL, DNSSEC y DNS over HTTPS

El DNS es la puerta de entrada a casi todo lo que ofrece Cloudflare. La caché, el WAF, la protección DDoS, Email Routing o los dominios propios de Workers dependen de que tu dominio use los servidores DNS de Cloudflare, o al menos de que un registro apunte a su red. Por eso conviene entender bien qué pasa al dar de alta un dominio y qué significa el famoso icono de la nube naranja.

En este artículo vemos cómo funciona el DNS autoritativo de Cloudflare, los tipos de configuración, el modo proxy, los TTL, el CNAME flattening, DNSSEC y cómo migrar sin cortes. Y terminamos con un script que consulta el DNS por HTTPS y te dice si un dominio está detrás de Cloudflare.

Cómo funciona

Cloudflare DNS es un servicio autoritativo: es quien responde, en nombre de tu dominio, a la pregunta «¿cuál es la IP de blog.ejemplo.com?». Está disponible en todos los planes, también en el gratuito. Hay tres formas de usarlo:

• Configuración completa (full o primaria): cambias los servidores de nombres (NS) de tu dominio en el registrador por los dos que te asigna Cloudflare (del tipo nombre.ns.cloudflare.com). Cloudflare pasa a ser tu DNS principal. Es la más habitual y la única disponible en Free y Pro.
• Configuración parcial (CNAME setup): mantienes tu proveedor DNS y solo apuntas con CNAME a Cloudflare los nombres que quieras proxificar. Solo en Business y Enterprise, y no funciona con dominios de Cloudflare Registrar.
• Secundaria: Cloudflare recibe copias de la zona de tu DNS principal por transferencia de zona.

La nube naranja: proxied o solo DNS

Cada registro A, AAAA o CNAME tiene un estado de proxy:

• Proxied (nube naranja): Cloudflare responde con sus propias IP anycast en lugar de la de tu servidor. El tráfico HTTP/HTTPS pasa por su red, y ahí se aplican caché, WAF, protección DDoS, reglas de redirección y Workers. Tu IP real queda oculta.
• DNS only (nube gris): Cloudflare responde con tu IP real y el tráfico va directo a tu servidor. Cloudflare solo ve las consultas DNS, no las peticiones.

Solo pueden proxificarse los registros de resolución de direcciones (A, AAAA y CNAME). El resto (MX, TXT, SRV…) son siempre solo DNS. Cloudflare recomienda proxificar todo lo que sirva tráfico web, y no proxificar, por ejemplo, los CNAME que sirven para verificar la propiedad del dominio ante un tercero. Al dar de alta un dominio desde el panel, el proxy viene activado por defecto.

Y un detalle que muchos descubren tarde: el proxy de Cloudflare es para HTTP y HTTPS. Si apuntas ssh.ejemplo.com con la nube naranja a tu servidor, SSH no funcionará. Para eso, o lo dejas en solo DNS, o usas Cloudflare Tunnel.

TTL

El TTL indica cuánto tiempo pueden guardar los resolvedores una respuesta.

En los registros con proxy no importa mucho: la IP que ve el mundo es la de Cloudflare, y si cambias tu origen el cambio es inmediato, porque los resolvedores siguen apuntando a Cloudflare. En los registros solo DNS, baja el TTL unas horas antes de una migración para que el cambio se propague rápido.

CNAME flattening

El estándar DNS no permite un CNAME en la raíz del dominio (ejemplo.com), porque ahí ya hay registros SOA y NS. Cloudflare lo resuelve con el CNAME flattening: puedes crear el CNAME en la raíz y Cloudflare responde con las IP finales a las que apunta, como si fuera un registro A. Es lo que permite, por ejemplo, apuntar el dominio raíz a un servicio que solo te da un nombre. En los planes de pago puedes aplanar todos los CNAME de la zona, no solo el de la raíz.

DNSSEC

DNSSEC firma tus registros para que nadie pueda falsificar las respuestas. En Cloudflare se activa con un clic, pero tiene dos pasos:

1. Activarlo en el panel de DNS, que genera los datos de un registro DS.
2. Añadir ese DS en tu registrador. Cloudflare usa el algoritmo 13 (ECDSA P-256 con SHA-256). Si el dominio está en Cloudflare Registrar, o es .ch o .cz, el DS se añade solo.

Migrar un dominio sin cortes

1. Da de alta el dominio en Cloudflare. El escaneo inicial importa los registros que encuentra, pero revísalos a mano: los subdominios poco conocidos, los MX y los TXT de SPF, DKIM y DMARC se escapan con facilidad. También puedes importar un fichero de zona.
2. Desactiva DNSSEC en el registrador si estaba activo.
3. Cambia los NS en el registrador por los que te indica Cloudflare.
4. Espera a que la zona pase a Active. Cloudflare tiene que verificar el cambio, y puede tardar hasta 24 horas.
5. Vuelve a activar DNSSEC desde Cloudflare.

Gestionar registros por API

Todo lo del panel tiene su equivalente en la API. Crear un registro A con proxy sería algo así (necesitas un token con permiso de edición de DNS en la zona; no lo he probado):

curl https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type":"A","name":"app","content":"192.0.2.10","proxied":true,"ttl":1}'

ttl: 1 significa «Auto». Para muchos dominios o cambios frecuentes compensa gestionarlo con Terraform, pero eso queda fuera de este artículo.

Comprobar un dominio con DNS over HTTPS

El resolvedor público de Cloudflare (1.1.1.1) acepta consultas por HTTPS en https://cloudflare-dns.com/dns-query. Con la cabecera accept: application/dns-json devuelve JSON, lo que permite consultar el DNS con un simple fetch, también desde un navegador o un Worker:

curl -s -H "accept: application/dns-json" \
  "https://cloudflare-dns.com/dns-query?name=cloudflare.com&type=A&do=1"

{"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,"Question":[{"name":"cloudflare.com","type":1}],"Answer":[{"name":"cloudflare.com","type":1,"TTL":300,"data":"104.16.132.229"},{"name":"cloudflare.com","type":1,"TTL":300,"data":"104.16.133.229"},{"name":"cloudflare.com","type":46,"TTL":300,"data":"A 13 2 300 1791071124 1790891124 34505 cloudflare.com. fXhb6kdh…"}]}

AD: true indica que el resolvedor ha validado DNSSEC, y el registro de tipo 46 (RRSIG) es la firma, algoritmo 13. La documentación avisa de que el formato JSON no tiene RFC y sigue el esquema de Google; para usos críticos recomienda el formato binario (wireformat).

Con eso he escrito un script que, para cada dominio, consulta los registros A, comprueba si todas las IP están en los rangos publicados por Cloudflare, busca los NS de la zona y mira si DNSSEC valida:

// ¿Está un dominio detrás de Cloudflare? Consulta por DNS over HTTPS (JSON)
// y compara las IP con los rangos publicados por Cloudflare.
// Uso: node comprobar-dns.mjs blog.ejemplo.com [otro.com ...]

const DOH = "https://cloudflare-dns.com/dns-query";

async function consulta(name, type, extra = "") {
  const r = await fetch(`${DOH}?name=${encodeURIComponent(name)}&type=${type}${extra}`, {
    headers: { accept: "application/dns-json" },
  });
  return r.json();
}

// Rangos IPv4 oficiales de Cloudflare (texto, un CIDR por línea)
const rangos = (await (await fetch("https://www.cloudflare.com/ips-v4")).text())
  .trim().split("\n").map((c) => c.trim());

const aNumero = (ip) => ip.split(".").reduce((n, o) => n * 256 + Number(o), 0);
function enRango(ip, cidr) {
  const [base, bits] = cidr.split("/");
  const tam = 2 ** (32 - Number(bits));
  const ini = aNumero(base);
  return aNumero(ip) >= ini && aNumero(ip) < ini + tam;
}

// Sube por los niveles del nombre hasta encontrar los NS de la zona
async function nameservers(host) {
  const partes = host.split(".");
  for (let i = 0; i < partes.length - 1; i++) {
    const zona = partes.slice(i).join(".");
    const r = await consulta(zona, "NS");
    const ns = (r.Answer ?? []).filter((a) => a.type === 2).map((a) => a.data);
    if (ns.length) return { zona, ns };
  }
  return { zona: host, ns: [] };
}

for (const host of process.argv.slice(2)) {
  const a = await consulta(host, "A", "&do=1");
  const ips = (a.Answer ?? []).filter((x) => x.type === 1);
  const proxied = ips.length > 0 && ips.every((x) => rangos.some((c) => enRango(x.data, c)));
  const { zona, ns } = await nameservers(host);
  console.log(`\n${host}`);
  console.log(`  A:        ${ips.map((x) => `${x.data} (TTL ${x.TTL})`).join(", ") || "—"}`);
  console.log(`  Proxy CF: ${proxied ? "sí (IP anycast de Cloudflare)" : "no"}`);
  console.log(`  NS (${zona}): ${ns.join(", ")}`);
  console.log(`  DNS de Cloudflare: ${ns.some((n) => n.endsWith(".cloudflare.com.")) ? "sí" : "no"}`);
  console.log(`  DNSSEC validado (AD): ${a.AD ? "sí" : "no"}`);
}

$ node comprobar-dns.mjs example.com cloudflare.com github.com

example.com
  A:        104.20.23.154 (TTL 65), 172.66.147.243 (TTL 65)
  Proxy CF: sí (IP anycast de Cloudflare)
  NS (example.com): hera.ns.cloudflare.com., elliott.ns.cloudflare.com.
  DNS de Cloudflare: sí
  DNSSEC validado (AD): sí

cloudflare.com
  A:        104.16.132.229 (TTL 87), 104.16.133.229 (TTL 87)
  Proxy CF: sí (IP anycast de Cloudflare)
  NS (cloudflare.com): ns3.cloudflare.com., ns4.cloudflare.com., ns5.cloudflare.com., ns6.cloudflare.com., ns7.cloudflare.com.
  DNS de Cloudflare: sí
  DNSSEC validado (AD): sí

github.com
  A:        140.82.114.4 (TTL 42)
  Proxy CF: no
  NS (github.com): dns1.p08.nsone.net., dns2.p08.nsone.net., dns3.p08.nsone.net., dns4.p08.nsone.net., ns-1283.awsdns-32.org., ns-1707.awsdns-21.co.uk., ns-421.awsdns-52.com., ns-520.awsdns-01.net.
  DNS de Cloudflare: no
  DNSSEC validado (AD): no

example.com y cloudflare.com están detrás del proxy de Cloudflare y validan DNSSEC; github.com no usa Cloudflare. Fíjate en que los TTL bajan entre consultas: es el tiempo que le queda a la respuesta en la caché del resolvedor, no el TTL configurado.

Errores comunes (y cómo evitarlos)

• Olvidar registros al migrar. Sobre todo MX, SPF, DKIM y subdominios internos. Exporta la zona antigua y compárala.
• Migrar con DNSSEC activo. Desactívalo antes y reactívalo después.
• Proxificar servicios que no son web. SSH, bases de datos o juegos no pasan por el proxy HTTP. Déjalos en solo DNS o usa Tunnel.
• Dejar registros en gris que exponen tu origen. Un direct.ejemplo.com en solo DNS que apunta al mismo servidor revela tu IP y permite saltarse el WAF.
• Proxificar CNAME de verificación. Los de Google, Microsoft o tu proveedor de certificados tienen que responder con su valor real.
• Mezclar proxied y solo DNS en el mismo nombre. Cloudflare los tratará todos como proxied.
• Esperar que el TTL de un registro proxied sea otro. Es siempre 300 s.

Cuándo usar Cloudflare DNS (y cuándo no)

Úsalo si quieres usar cualquier otra cosa de Cloudflare (caché, WAF, Workers con dominio propio, Email Routing, Tunnel): casi todas lo requieren o funcionan mejor así. Es gratuito, rápido y la API es cómoda.

Piénsatelo si tu empresa ya tiene un DNS gestionado con su propio flujo (por ejemplo, Route 53 con todo en Terraform) y en Free o Pro: la configuración parcial, que te dejaría conservarlo, solo está en Business y Enterprise.

Sigue leyendo

• Cloudflare a fondo: la visión general de la plataforma.
• Cloudflare CDN y caché a fondo: lo que pasa con el tráfico proxied.
• Cloudflare WAF y protección DDoS a fondo: seguridad para los registros con nube naranja.
• Cloudflare Tunnel a fondo: publicar servicios sin exponer tu IP.
• Cloudflare Email a fondo: los MX, SPF y DKIM de Email Routing.