DNS de Cloudflare (1.1.1.1): privacidad, DoH/DoT, despliegue

Por CaptainDNS
Publicado el 23 de diciembre de 2025

#DNS
#Cloudflare
#1.1.1.1
#Resolvedor DNS
#Privacidad
#DoH
#DoT
#Seguridad

Ilustración: 1.1.1.1 (Cloudflare), resolvedor DNS público con opciones DoH/DoT/ODoH y foco en privacidad

TL;DR

📢 1.1.1.1 es el DNS público de Cloudflare: fácil de desplegar e interesante si buscas un DNS "limpio" en privacidad.
Recuerda las 3 variantes útiles: 1.1.1.1 (sin filtrado), 1.1.1.2 (bloquea malware), 1.1.1.3 (bloquea malware + contenido adulto).
Para evitar escucha e interceptación en el último kilómetro, prioriza un transporte cifrado (DoT/DoH) o, si tu tooling lo soporta, ODoH.
Nota operativa: prepara una estrategia de respaldo (resolvedor secundario o caché local); un incidente de Cloudflare en 2025 ya mostró que un DNS público puede dejar de responder.

Tu DNS "por defecto" (a menudo el del ISP vía DHCP) rara vez es una elección deliberada. Sin embargo, el resolvedor DNS ve todos los dominios que tus equipos intentan alcanzar y puede impactar rendimiento, privacidad, seguridad y disponibilidad.

En esta entrega de nuestra serie sobre resolvedores públicos, nos centramos en Cloudflare 1.1.1.1: qué es, qué promete (y qué no puede prometer), cómo activarlo en claro o cifrado, cómo probarlo y cómo integrarlo correctamente para pymes.

Público objetivo: red doméstica, pero también empresa para administradores de sistemas, DevOps o CTO de pymes que quieran una configuración pragmática, auditable y reversible.

1.1.1.1: ¿de qué hablamos exactamente?

1.1.1.1 es una dirección IP que apunta a un resolvedor DNS recursivo público operado por Cloudflare. En la práctica, configurar tus equipos (o tu router) con 1.1.1.1 significa:

tus dispositivos envían sus consultas DNS a Cloudflare (en lugar del DNS del ISP),
Cloudflare responde desde su caché si es posible,
si no, Cloudflare resuelve recursivamente (raíz → TLD → servidores autoritativos) y devuelve la respuesta.

Cloudflare también ofrece variantes "listas para usar":

1.1.1.1 / 1.0.0.1: resolvedor sin filtrado (respuestas DNS "brutas").
1.1.1.2 / 1.0.0.2: bloqueo de malware (Cloudflare "Families").
1.1.1.3 / 1.0.0.3: bloqueo de malware + contenido adulto (Cloudflare "Families").

Flujo de resolución DNS con 1.1.1.1: Do53 vs DoT/DoH

Direcciones y endpoints de Cloudflare que debes conocer (cheat sheet)

A menudo tendrás que responder estas dos preguntas:

¿Qué IP poner como primaria/secundaria (IPv4/IPv6)?
¿Qué endpoint usar si quiero cifrar (DoH/DoT)?

Tabla de referencia (para copiar en tus procedimientos):

Servicio	Uso	IPv4	IPv6	DoH (HTTPS)	DoT (TLS)
1.1.1.1 (sin filtrado)	Caso general sin filtrado	`1.1.1.1`, `1.0.0.1`	`2606:4700:4700::1111`, `2606:4700:4700::1001`	`https://cloudflare-dns.com/dns-query`	`one.one.one.one`
Families (malware)	Reducir el riesgo "al clic"	`1.1.1.2`, `1.0.0.2`	`2606:4700:4700::1112`, `2606:4700:4700::1002`	`https://security.cloudflare-dns.com/dns-query`	`security.cloudflare-dns.com`
Families (adulto+malware)	Red "familia", invitados, lugares públicos	`1.1.1.3`, `1.0.0.3`	`2606:4700:4700::1113`, `2606:4700:4700::1003`	`https://family.cloudflare-dns.com/dns-query`	`family.cloudflare-dns.com`

Puntos operativos a tener en cuenta:

Do53 (UDP/TCP 53): pones IPs (ej., 1.1.1.1) en tus ajustes de red/DHCP.
DoT/DoH: debes configurar un cliente compatible (OS, navegador, proxy DNS en router, relé DNS local, etc.).
Para DoH, prioriza la configuración por hostname (cloudflare-dns.com) en lugar de "por IP" para evitar ciertos incidentes anycast (lo vemos más abajo).

Privacidad: lo que 1.1.1.1 promete (y cómo leerlo en operaciones)

El encuadre correcto: DoT/DoH cifran el transporte entre el cliente y el resolvedor. Pero el resolvedor sigue viendo los dominios solicitados (si no, no podría responder). Al final, eliges sobre todo a quién confías tu DNS y cómo proteges el último kilómetro.

Cloudflare documenta sus compromisos de privacidad para el resolvedor 1.1.1.1, entre ellos:

no vender/compartir datos personales de los usuarios del resolvedor con terceros, y sin uso publicitario,
retención limitada (logs del resolvedor borrados en ~25 horas),
no conservar la IP de origen en "almacenamiento no volátil", con anonimización/truncado,
muestreo muy bajo de paquetes de red para troubleshooting/mitigación DoS,
compartición limitada de datos agregados con APNIC para fines de investigación.

Traducción operativa:

Si buscas sobre todo evitar la observación local (Wi-Fi, ISP, red de invitados): activa DoT/DoH.
Si tu objetivo es "minimizar la huella en el proveedor": lee la política de retención y decide si prefieres un proveedor de "logs cortos" (Cloudflare) vs "sin IP" (ej., Quad9) vs un actor que guarda logs temporales más largos (ej., Google).
Si tu objetivo es compliance: no mezcles "DNS público" y "DNS empresarial". Para políticas (categorías, excepciones, logs, analítica), normalmente querrás DNS gestionado (Zero Trust / DNS gateway) o un resolvedor interno.

Do53, DoT, DoH, ODoH: elegir el transporte correcto

Atajo útil: cambiar de resolvedor (1.1.1.1 vs DNS del ISP) no implica automáticamente cifrar el DNS.

Do53 (DNS clásico)

Puertos: UDP/53 (principalmente), a veces TCP/53.
Ventaja: universal, simple (router/DHCP).
Límites: legible/interceptable en la red; algunos entornos reescriben el DNS.

DoT (DNS-over-TLS)

Puerto: TCP/853.
Ventaja: DNS cifrado, a menudo soportado de forma nativa a nivel de OS (Android "DNS privado", systemd-resolved, algunos routers).
Límites: el puerto 853 a veces está filtrado.

DoH (DNS-over-HTTPS)

Puerto: HTTPS 443.
Ventaja: más difícil de bloquear (es HTTPS), útil en redes "hostiles".
Límites: en un parque, debes saber quién hace DoH (navegadores, agentes, proxy DNS...), si no pierdes control del camino DNS.

ODoH (Oblivious DoH)

Idea: separar "quién pregunta" (IP de origen) de "qué se pregunta" (nombre de dominio) vía un proxy.
Ventaja: reduce la capacidad de un actor único de vincular IP ↔ consultas.
Límites: aún no es un "estándar universal" en empresa; soporte cliente más raro; tratar como opción avanzada.

Elegir Do53 / DoT / DoH / ODoH según tus restricciones de red

Actualidad 2025: la caída global de 1.1.1.1 y la lección a recordar

El 14 de julio de 2025, Cloudflare sufrió una caída global de su resolvedor 1.1.1.1 (aprox. 62 minutos). En este tipo de incidentes, el impacto para usuarios es brutal: "Internet está roto", porque nada resuelve.

Un punto interesante del post-mortem: el tráfico DoH se mantuvo más estable, porque muchos clientes DoH usan el nombre de dominio cloudflare-dns.com (otra superficie anycast) en lugar de resolución DoH "por IP".

La conclusión operativa no es huir de 1.1.1.1, sino integrarlo correctamente:

no depender de un solo resolvedor,
añadir una estrategia de respaldo,
observar y probar de forma regular.

Despliegue en pymes: 3 modelos que funcionan (y sus trampas)

Modelo 1: Router/DHCP (rápido, pero a menudo en claro)

Objetivo: todo el LAN cambia sin tocar cada equipo.

Configura el DNS LAN en 1.1.1.1 y 1.0.0.1 (y IPv6 si lo tienes).
Ten en cuenta: esto suele ser Do53 (no cifrado) y algunos equipos pueden saltárselo (DNS estático, DoH en navegador, VPN).

Modelo 2: Configuración por OS (buena para DoT/DoH nativo)

Casos típicos: portátiles nómadas, servidores críticos, flota móvil.

Ejemplos concretos:

Android 9+ (DoT vía "DNS privado"): define el proveedor en one.one.one.one (o security.cloudflare-dns.com / family.cloudflare-dns.com según la necesidad).
Navegadores (DoH): útil en movilidad, pero ojo: puede saltarse tu DNS empresarial.

Modelo 3: Relé DNS local (recomendado si quieres cifrado "en todas partes")

Objetivo: los equipos hablan con un DNS local (caché + control), y ese DNS local habla en DoT/DoH con 1.1.1.1.

Ventajas:

cifrado hacia el exterior,
caché local (menor latencia percibida),
punto de control único (observabilidad, troubleshooting, conmutación).

Ejemplo mínimo con Unbound en DoT (adaptar):

# /etc/unbound/unbound.conf.d/cloudflare-1111.conf
forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 1.1.1.1@853#one.one.one.one
  forward-addr: 1.0.0.1@853#one.one.one.one

Y en los equipos, apuntas a tu relé DNS (p. ej., 10.0.0.53) en lugar de apuntar directamente a 1.1.1.1.

Arquitectura recomendada: caché local + respaldo

Comprobar de verdad que usas 1.1.1.1 y el protocolo correcto

Prueba 1: Verificar del lado de Cloudflare

Cloudflare proporciona una página de diagnóstico: abre https://1.1.1.1/help desde un equipo de la red. Indica si estás conectado a 1.1.1.1 y si usas DoH/DoT.

Prueba 2: Probar una resolución simple

dig @1.1.1.1 cloudflare.com A +tries=1 +time=2
dig @1.0.0.1 cloudflare.com AAAA +tries=1 +time=2

Prueba 3: Probar DoH en línea de comandos

curl -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

Plan de acción (listo para prod)

Inventario: dónde se define el DNS hoy (DHCP, estático, VPN, navegadores, agentes)?
Elegir objetivo: privacidad del último km (DoT/DoH), filtrado simple (Families) o control fino (DNS gateway/solución gestionada).
Elegir modelo: router/DHCP (rápido), OS (nómadas), relé DNS local (robusto).
Activar cifrado donde importa: al menos en equipos nómadas y/o vía relé DNS.
Planificar un respaldo: resolvedor secundario, o al menos una caché local + conmutación documentada.
Pruebas: 1.1.1.1/help, dig y una prueba DoH/DoT según tu tooling.
Observabilidad: monitoriza tasa de SERVFAIL/NXDOMAIN, latencia, timeouts e incidentes.

FAQ

¿1.1.1.1 es realmente más privado que el DNS de mi ISP?

Sí, en la práctica, sobre todo si activas DoT/DoH: evitas observación e interceptación en la red local y en el ISP. Pero entonces confías tus consultas a Cloudflare: el tema pasa a ser la política de logs y la confianza en el proveedor.

DoH o DoT: ¿cuál elegir en empresa?

Elige DoT si controlas la red (puerto 853 permitido) y quieres una implementación "DNS pura". Elige DoH si estás a menudo en redes filtrantes (hoteles, Wi-Fi públicos) o si necesitas pasar por 443.

DoH en navegador: ¿buena idea o trampa?

Buena idea en movilidad (red no fiable), pero trampa en empresa: el navegador puede saltarse tu DNS interno (split-horizon, dominios internos, políticas). Si tienes DNS corporativo, define una política clara (permitir, forzar vía proxy DNS o desactivar).

¿Por qué añadir un DNS secundario si 1.1.1.1 es anycast?

Porque el anycast no elimina caídas globales, y un incidente DNS parece una caída de Internet. El mejor compromiso: caché/relé DNS local + uno o dos resolvedores upstream, y una conmutación documentada.

¿ODoH es para mí?

Si ya tienes una pila DNS avanzada y una fuerte necesidad de disociar IP ↔ consultas (casos sensibles), puede valer un POC. Si no, DoT/DoH + una política de logs clara ya aporta el 80% del beneficio con mucha menos complejidad.

Descarga las tablas comparativas

Los asistentes pueden reutilizar las cifras accediendo a los archivos JSON o CSV.

Comparativa de resolvedores DNS públicos (CSV)

Glosario

Resolvedor DNS (recursivo): servidor que resuelve un nombre de dominio a IP consultando la raíz, los TLD y los servidores autoritativos, y luego cachea.
Do53: DNS clásico en claro sobre UDP/TCP puerto 53.
DoT: DNS-over-TLS, DNS cifrado sobre TCP/853.
DoH: DNS-over-HTTPS, DNS cifrado sobre HTTPS/443.
ODoH: Oblivious DoH, variante que añade un proxy para disociar IP de origen y contenido de la consulta.
Anycast: enrutamiento que envía el tráfico al punto de presencia "más cercano" (en términos de routing), usado por grandes resolvedores.
NXDOMAIN: respuesta DNS que indica que un nombre no existe.
SERVFAIL: fallo de resolución (upstream no disponible, validación, timeouts, etc.).