> ## Content Index
> Fetch the complete content index at: https://blog.devutilites.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Cloudflare DNS a fondo: registros, nube naranja, TTL, DNSSEC y DNS over HTTPS
- URL: https://blog.devutilites.com/cloudflare-dns-a-fondo/
- Published: 2026-10-03T03:14:01.000Z
- Updated: 2026-10-03T03:14:01.000Z
- Description: Cómo funciona el DNS autoritativo de Cloudflare: configuración completa o parcial, qué significa la nube naranja, TTL, CNAME flattening, DNSSEC, cómo migrar un dominio sin cortes y un script que comprueba por DNS over HTTPS si un dominio está detrás de Cloudflare.
- Author: Luis Collantes
- Tags: Cloudflare, DevOps

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.

🧪

**El script de este artículo se ha ejecutado de verdad** el 3 de octubre de 2026 con **Node.js 24.21.0**, consultando el DNS over HTTPS público de Cloudflare (`cloudflare-dns.com`). **La gestión de registros, DNSSEC y la migración de un dominio no los he probado** en una cuenta: los pasos salen de la documentación oficial, revisada ese mismo día. El ejemplo de la API también está sin probar.

## 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.

![Esquema de Cloudflare DNS: el resolvedor del usuario pregunta a los servidores de nombres de Cloudflare; un registro con proxy devuelve IPs anycast de Cloudflare y el tráfico web pasa por su red hasta el origen; un registro solo DNS devuelve la IP real y el tráfico va directo al origen](https://blog.devutilites.com/content/images/2026/10/cf-dns-esquema.png)

Con proxy, el visitante solo ve IPs de Cloudflare y el tráfico pasa por su red. Sin proxy, ve tu IP real. Diagrama: devutilites.

## 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.

⚠️

**Mezclar en un mismo nombre registros con y sin proxy no funciona como esperas.** Si tienes varios A o AAAA para el mismo nombre y al menos uno está proxied, Cloudflare trata **todos** como proxied.

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](https://blog.devutilites.com/cloudflare-tunnel-a-fondo/).

## TTL

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

| Tipo de registro | TTL                                                        |
| ---------------- | ---------------------------------------------------------- |
| Proxied          | **Auto = 300 s**, fijo, no se puede cambiar                |
| Solo DNS         | Auto (300 s) o entre **60 s y 1 día** (30 s en Enterprise) |

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.

🚨

**Antes de migrar un dominio a Cloudflare, desactiva DNSSEC en tu registrador.** Si cambias los NS con un DS antiguo publicado, los resolvedores que validan DNSSEC rechazarán las respuestas de Cloudflare y tu dominio dejará de funcionar para muchos usuarios. Vuelve a activarlo cuando la migración termine.

## 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**):

```bash
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:

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

```json
{"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](https://www.cloudflare.com/ips-v4?ref=blog.devutilites.com), busca los NS de la zona y mira si DNSSEC valida:

```javascript
// ¿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"}`);
}
```

```text
$ 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](https://blog.devutilites.com/cloudflare-a-fondo/): la visión general de la plataforma.
- [Cloudflare CDN y caché a fondo](https://blog.devutilites.com/cloudflare-cdn-cache-a-fondo/): lo que pasa con el tráfico proxied.
- [Cloudflare WAF y protección DDoS a fondo](https://blog.devutilites.com/cloudflare-waf-ddos-a-fondo/): seguridad para los registros con nube naranja.
- [Cloudflare Tunnel a fondo](https://blog.devutilites.com/cloudflare-tunnel-a-fondo/): publicar servicios sin exponer tu IP.
- [Cloudflare Email a fondo](https://blog.devutilites.com/cloudflare-email-a-fondo/): los MX, SPF y DKIM de Email Routing.