Redes

Cloudflare Internal DNS ya es oficial: cuándo puede simplificar tu DNS privado de verdad

Cloudflare Internal DNS ya está en disponibilidad general. Te contamos qué aporta para DNS privado, split-horizon y Zero Trust, y qué conviene revisar antes de adoptarlo.

Cloudflare hizo oficial el 20 de julio de 2026 una pieza que muchas redes llevaban tiempo resolviendo a base de parches: unir DNS público y DNS privado en el mismo plano de control. Su nueva propuesta, Cloudflare Internal DNS, combina resolución recursiva, zonas internas y políticas de resolución para que un mismo equipo gestione nombres públicos, recursos privados y escenarios de split-horizon sin mantener plataformas separadas.

La noticia importa porque el DNS interno sigue siendo uno de esos servicios que en muchas empresas vive aparte: servidores heredados, resolvers de cada nube, políticas distintas y poca visibilidad común. Cloudflare quiere cerrar ese hueco usando la misma base sobre la que ya corre 1.1.1.1 y su plataforma Zero Trust. Si administras redes, acceso remoto, apps internas o sedes distribuidas, la pregunta útil no es solo “qué ha lanzado Cloudflare”, sino si esto te ayuda de verdad a simplificar operación, reducir deriva y controlar mejor quién resuelve qué.

Resumen rápido: qué ha pasado y qué aporta

• 20 de julio de 2026: Cloudflare anunció la disponibilidad general de Internal DNS.
• La propuesta une DNS autoritativo interno y resolución recursiva bajo el mismo plano de control.
• El enfoque está pensado para redes privadas, aplicaciones internas, bases de datos, entornos híbridos y escenarios de split-horizon DNS.
• Cloudflare lo apoya en tres piezas: Internal Zones, DNS Views y Resolver Policies.
• Para clientes Enterprise, Cloudflare indica que está incluido con Gateway sin coste adicional.

Qué es Cloudflare Internal DNS en lenguaje claro

Cloudflare Internal DNS es una forma de publicar y resolver nombres privados dentro de tu organización sin separar del todo el DNS interno del resto de la política de red. En vez de tener una herramienta para DNS público, otra para nombres internos y otra distinta para decidir qué usuarios o dispositivos pueden resolver cada cosa, Cloudflare propone centralizarlo.

La arquitectura oficial gira en torno a tres bloques:

• Internal Zones: contienen los registros privados de recursos internos, como aplicaciones, bases de datos o servicios por entorno.
• DNS Views: permiten que distintos usuarios o dispositivos vean respuestas diferentes para el mismo nombre, algo clave en escenarios de split-horizon.
• Resolver Policies: deciden qué consultas van a cada vista o resolver según contexto, usuario, dispositivo o reglas de Gateway.

Dicho de otra forma: no se trata solo de “tener DNS privado”, sino de ligar ese DNS a identidad, dispositivo, política y visibilidad operativa. Ahí está la parte interesante para equipos que ya usan Cloudflare One, Tunnel o Gateway.

Por qué esta disponibilidad general puede ser relevante de verdad

Muchas redes corporativas han crecido con una mezcla difícil de mantener: DNS local para oficina, resolver distinto por nube, VPN o agente para acceso remoto y políticas de seguridad repartidas. Cuando además aparece split-horizon DNS, los riesgos de inconsistencia suben: el mismo hostname puede resolver de forma distinta dentro y fuera, y si los sistemas no se mantienen sincronizados, llegan las incidencias.

Cloudflare vende esta GA como una forma de simplificar justo eso. En sus palabras, public y private DNS quedan en una sola plataforma, con una sola API, una sola auditoría y un solo lugar donde aplicar política. La idea encaja bastante bien con algo que ya vimos al hablar de 1.1.1.1 y EDE 33 en DNSSEC: cuando el DNS deja más contexto y menos cajas negras, el soporte y la operación mejoran mucho.

También aporta una lectura Zero Trust clara. Si una herramienta puede decidir qué usuario, qué dispositivo o qué contexto resuelve una vista interna concreta, el DNS deja de ser esa capa “de confianza implícita” que a menudo queda fuera del control fino. En equipos distribuidos, contratistas, BYOD o sedes con políticas distintas, eso sí puede marcar diferencia.

Qué cambia en la práctica para un equipo técnico

La novedad no significa que mañana debas tirar tu DNS actual. Sí cambia la conversación técnica. Ahora ya no es solo “qué servidor responde a intranet.empresa.local”, sino cómo mantienes vistas internas, políticas de resolución, auditoría y acceso remoto sin capas separadas ni soluciones duplicadas.

Si el planteamiento encaja en tu entorno, lo más útil es pensar en estos efectos prácticos:

• Menos deriva entre DNS público y privado.
• Menos dependencia de appliances o resolvers heredados difíciles de escalar.
• Más control sobre qué equipos y usuarios resuelven determinados recursos internos.
• Más coherencia entre políticas DNS y el resto del tráfico que ya pasa por Gateway.
• Más visibilidad al centralizar logs, reglas y auditoría.

Para quien venga de una red más clásica, también conviene aterrizar expectativas: esto no sustituye por sí solo todo el diseño de nombres, segmentación, autenticación o acceso a aplicaciones internas. Es una pieza potente, pero sigue necesitando una topología bien pensada.

Qué conviene revisar antes de plantearte el cambio

Si la noticia te interesa, la mejor reacción no es migrar con prisa. Es revisar si tu situación actual justifica el movimiento. Estos son los puntos más útiles para una primera evaluación:

• Cuántos planos DNS mantienes hoy: público, privado, nube, oficinas, laboratorios o sedes.
• Si tienes split-horizon real: mismos hostnames con respuestas distintas dentro y fuera.
• Qué parte de tu acceso remoto depende de nombres internos y cuánto te cuesta sostenerlo.
• Qué resolvers o appliances heredados arrastras y si te limitan por escalado, auditoría o mantenimiento.
• Cómo aplicas política hoy: por red, por VPN, por IP, por identidad o casi sin control fino.
• Qué herramientas usan tus equipos para depurar DNS cuando algo falla o resuelve distinto según el contexto.

La documentación actual de Cloudflare también deja un detalle práctico importante: el tráfico hacia IPs y hostnames privados debe estar bien incluido en Split Tunnels cuando el flujo depende del cliente de Cloudflare One. Si eso se configura mal, el producto puede parecer “roto” cuando en realidad el problema es de ruta y no de DNS.

Cuándo tiene más sentido y cuándo quizá no tanto

Cloudflare Internal DNS tiene más sentido si ya trabajas con Cloudflare One, Tunnel, Gateway o una estrategia Zero Trust más avanzada; si operas varias sedes, varias nubes o recursos híbridos; o si mantener sincronizados tus sistemas DNS te está costando tiempo, errores y soporte.

Puede tener menos sentido si tu red es pequeña, estable y muy local; si apenas usas nombres internos fuera de una sede; o si tu problema real no es DNS sino autenticación, segmentación o inventario de servicios. En esos casos, cambiar de plano de control quizá no sea la primera palanca que más valor te da.

Qué haría hoy si quiero evaluarlo con criterio

1. Inventariar dominios internos, zonas, resolvers y flujos que ya dependen de nombres privados.
2. Identificar dónde sufres más deriva: split-horizon, teletrabajo, multi-cloud, sedes o accesos de terceros.
3. Revisar si tu política de Cloudflare One ya cubre usuarios, dispositivos y rutas privadas de forma coherente.
4. Probar con un conjunto pequeño de zonas internas antes de pensar en migración amplia.
5. Medir si realmente reduces complejidad operativa, tickets de soporte y tiempo de diagnóstico.

Esa prudencia encaja bastante mejor con el estilo de su-ip.es que una promesa grandilocuente. Igual que ocurre al tocar la base de una red doméstica en una guía real para configurar un router Movistar, el valor no está en “activar una novedad”, sino en entender qué problema resuelves y qué nuevas dependencias introduces.

FAQ rápida

Cloudflare Internal DNS sustituye automáticamente a cualquier DNS privado actual?

No. Puede ayudar a consolidar y simplificar, pero la migración depende de cómo estén montadas tus zonas, tus vistas, tu conectividad y tus políticas actuales.

Esto va solo de resolver nombres internos?

No del todo. También va de gobernanza y política: quién resuelve qué, desde qué dispositivo, con qué visibilidad y con qué integración con el resto de la plataforma Zero Trust.

Sirve para escenarios split-horizon?

Sí. De hecho, uno de los mensajes centrales de Cloudflare es simplificar split-horizon DNS mediante vistas separadas sobre zonas compartidas y un mismo plano de control.

Qué error común conviene evitar al probarlo?

Confundir un problema de rutas o Split Tunnels con un fallo de DNS. Si el cliente no enruta bien hacia hostnames o resolvers privados, la experiencia puede fallar aunque la configuración DNS base sea correcta.

Fuentes oficiales

• Cloudflare Blog: Cloudflare Internal DNS is now generally available
• Cloudflare Docs: Resolver policies
• Cloudflare Docs: Private DNS
• Cloudflare Docs: Connect a private hostname

Conclusión

Cloudflare no ha lanzado solo “otro DNS privado”. Lo relevante de esta disponibilidad general es el intento de juntar DNS interno, política y visibilidad en la misma superficie de operación donde muchas empresas ya gestionan parte de su tráfico y su acceso Zero Trust.

Para algunas redes será una mejora clara. Para otras, una opción a evaluar con calma y sin prisa. Pero la idea de fondo sí merece atención: si el DNS interno sigue viviendo aparte, también seguirá siendo un punto ciego operativo. Y eso, en entornos híbridos y distribuidos, cada vez cuesta más sostenerlo.