DNS privado para redes VPS: cómo funciona y cuándo lo necesitas

Levantas un tercer servidor, necesitas que las máquinas se localicen por nombre en lugar de por IP y buscas "private DNS VPS". Aparecen tres resultados y no coinciden. Uno es un ajuste de Android que cifra las consultas de tu teléfono. Otro es una guía de cPanel para personalizar los servidores de nombres de un dominio. Otro es un documento de AWS sobre zonas alojadas privadas. El 20 de julio de 2026, Cloudflare lanzó Internal DNS en disponibilidad general y lo describió como "a veces también llamado DNS privado", así que ahora la colisión también viene de los proveedores de infraestructura.

El término está sobrecargado. Este artículo separa los distintos significados y luego se centra en el de las redes VPS: una zona DNS interna para la comunicación entre servidores. Al terminar, sabrás identificar qué sistema necesitas, decidir si tu flota requiere DNS privado y evitar los errores de diseño más comunes.

TL;DR

• "DNS privado" nombra al menos tres sistemas sin relación entre sí: una zona DNS interna para una red de servidores, la función de cifrado DNS-over-TLS de Android y los servidores de nombres personalizados de cPanel. Este artículo usa el término en el primer sentido: una zona DNS interna para una red VPS.
• Una zona DNS privada de VPS es un espacio de nombres interno acotado a la red que asigna nombres de host como db.internal.example.com a IP privadas. Sus registros no se publican en el DNS público.
• Para un puñado de servidores con IP estables, /etc/hosts es realmente suficiente. Un servidor DNS interno se justifica cuando la flota crece, las IP cambian con frecuencia o los servicios necesitan una resolución de nombres fiable.
• Para la mayoría de las redes VPS en producción, usa un subdominio de tu propiedad, como internal.example.com. Usa el espacio de nombres .internal solo en una instalación aislada donde sean aceptables las colisiones de nombres entre redes, la gestión de certificados con una CA privada y un tratamiento especial de DNSSEC. Evita .local, que mDNS reserva.

Lo que este artículo no cubre

Este artículo se limita al sentido de red VPS del DNS privado. No cubre usos ajenos de consumo ni de marcas de hosting:

• Configurar el ajuste de DNS privado o DNS-over-TLS de Android en un teléfono.
• Configurar servidores de nombres privados de cPanel para una marca de hosting.
• Un tutorial completo de instalación de BIND 9, Unbound, dnsmasq o CoreDNS. Aquí la implementación se queda a nivel de referencia, no de configuración paso a paso.
• Los resolutores cifrados de consumo como 1.1.1.1 o NextDNS, más allá de distinguirlos del sentido de red.

¿Qué significa realmente "DNS privado"?

"DNS privado" no es un solo sistema. El término nombra al menos tres sin relación entre sí: una zona DNS restringida a la red que resuelve nombres de host internos dentro de una red VPS o VPC, la función de cifrado DNS-over-TLS de Android y los servidores de nombres autoritativos personalizados de cPanel. Este artículo trata el primero, la zona interna que tus servidores consultan para encontrarse. También existe un cuarto uso más laxo: los resolutores públicos cifrados que se comercializan como "privados".

Los cuatro significados comparten un nombre y nada más:

El anuncio de disponibilidad general de Internal DNS de Cloudflare es un ejemplo gestionado y actual del primer significado, y una de las razones por las que la colisión se ha vuelto visible: un proveedor de infraestructura usa ahora "DNS privado" como sinónimo de DNS interno en su texto de lanzamiento. El sistema que describe, un Gateway Resolver más Internal Authoritative DNS para clientes Enterprise, es la misma categoría de sistema que construyes tú mismo en una flota de VPS, solo que gestionado.

Conclusión de la sección: los principales sistemas llamados "DNS privado" comparten una etiqueta, no una función. Identifica el significado antes de seguir una guía de configuración.

¿Cómo funciona el DNS privado en una red VPS?

Una zona DNS privada de VPS es un espacio de nombres acotado a la red, servido por un resolutor que tus servidores están configurados para usar. Asigna nombres de host internos como db.internal.example.com a IP privadas dentro de un rango que tú controlas. Los registros no se publican en el DNS público, aunque las consultas puedan pasar por un túnel privado o un plano de control DNS gestionado antes de llegar al resolutor. Esa separación es el núcleo de la distinción entre DNS privado y DNS público: el protocolo es el mismo, pero la visibilidad de la zona y su alcance de acceso son distintos.

Tres piezas hacen el trabajo. Un servidor autoritativo o una fuente de zona guarda la zona interna y sus registros. Un resolutor responde a las consultas que envían tus servidores. Y los registros A y AAAA de la zona asignan nombres de host internos a direcciones privadas, de modo que app.internal.example.com apunta a la capa de aplicación y db.internal.example.com apunta a la base de datos. Otros tipos de registro pueden aportar alias o información de servicio. Cuando la zona y la ruta del resolutor están bien configuradas, el resolutor responde la consulta interna localmente en lugar de enviarla hacia la raíz del DNS público.

Las plataformas cloud lo acotan a la red en lugar de a la máquina, lo que resulta un modelo de referencia útil. Las zonas alojadas privadas de AWS Route 53 solo funcionan cuando la VPC tiene enableDnsHostnames y enableDnsSupport en true, y el resolutor responde desde la zona privada para cada VPC que asocies a ella. Las zonas privadas de Google Cloud están acotadas a las redes VPC autorizadas y, en el orden de resolución estándar de una VPC se consultan antes que el DNS público, salvo que una política de servidor saliente cambie la ruta. Léelo como ilustraciones del patrón, no como tutoriales de plataforma: un servidor DNS interno autogestionado es la misma idea, ejecutada en tu propio VPS.

Mantener la zona fuera del DNS público es solo la mitad del trabajo. Vincula el servicio DNS a una interfaz privada o restringe el puerto 53 en UDP y TCP a tu red privada o VPN. No expongas el servicio recursivo a la internet pública: un resolutor abierto puede ser aprovechado en ataques de amplificación DNS.

Las zonas privadas y públicas usan el mismo modelo de registros y de caché DNS. Los registros llevan un TTL y los resolutores con caché suelen reutilizar una respuesta hasta que ese TTL expira, aunque los ajustes propios de cada resolutor pueden cambiar el tiempo de caché efectivo. Ese comportamiento se aborda en nuestra guía para apuntar un dominio a un VPS, incluidos los fundamentos de la propagación DNS y el TTL, así que no se vuelve a explicar aquí.

¿Cuándo necesita realmente DNS privado tu red VPS?

Para dos o tres servidores estáticos, /etc/hosts es realmente suficiente. Un servidor DNS interno se justifica cuando la flota crece, las IP cambian con regularidad o las aplicaciones necesitan un descubrimiento de servicios fiable. El detonante real es la complejidad operativa, no un número fijo de servidores.

/etc/hosts es un mapa estático de nombre de host a IP que ya existe en cualquier máquina Linux. No necesita demonio ni archivo de zona, pero las copias obsoletas o inconsistentes son fallos muy reales. Añade la IP privada de cada servidor al archivo, mantén las copias sincronizadas y las máquinas podrán encontrarse por nombre. Para una flota pequeña y estable esa es la respuesta correcta, y recurrir en su lugar a BIND 9 solo añade un demonio que mantener sin ganar nada.

Deja de escalar en tres situaciones. Cuando añades y quitas servidores con frecuencia, mantener un archivo estático coherente en cada host se convierte en trabajo manual pesado. Cuando las IP cambian, por autoescalado, reconstrucciones o reasignaciones del proveedor, el archivo queda obsoleto en silencio. Y cuando los contenedores o los entornos aislados no heredan las entradas del host, la correspondencia deja de ser universal. Cualquiera de esas situaciones es el detonante real. El número de servidores por sí solo es una aproximación burda, no la señal auténtica.

Conclusión de la sección: el detonante es la rotación operativa, no el número de servidores. Una flota congelada de diez máquinas puede vivir con /etc/hosts; una flota de tres máquinas que se reconstruye cada noche probablemente no.

Construye sobre un VPS Linux con acceso root, NVMe y la potencia de AMD EPYC.

Ver planes Linux

¿Qué servidor DNS deberías usar: BIND 9, Unbound, dnsmasq o CoreDNS?

Elige según la forma de tu flota. dnsmasq encaja en redes pequeñas que quieren un DNS ligero y, cuando aplica, DHCP desde el mismo demonio. Unbound es un resolutor recursivo validador y austero que además puede responder una zona local modesta. BIND 9 aporta amplias capacidades autoritativas y recursivas con la mayor superficie de configuración. CoreDNS encaja en flotas de contenedores y Kubernetes donde el DNS forma parte del descubrimiento de servicios.

La lógica de selección es corta. Si necesitas un resolutor pequeño respaldado por un archivo tipo hosts, o ya repartes concesiones DHCP, dnsmasq elimina una pieza móvil. Si sobre todo necesitas un resolutor validador que reenvíe hacia fuera y responda una zona interna modesta, Unbound aporta ese conjunto más acotado sin un despliegue completo de BIND 9. Si necesitas control autoritativo total, delegación y el mayor cuerpo de documentación en el que apoyarte a las 3 de la mañana, BIND 9 es la elección conservadora pese a su mayor superficie de configuración. Si el DNS ya forma parte de una pila de descubrimiento de servicios con contenedores o Kubernetes, CoreDNS encaja allí mismo. La regla general es ejecutar la cosa más pequeña que cubra la forma de tu flota.

En una flota de producción, no conviertas una sola instancia DNS en el único camino hacia cada nombre interno. Ejecuta al menos dos instancias DNS que puedan responder la zona, colócalas en dominios de fallo separados cuando sea práctico y configura a los clientes para que alcancen ambas. De lo contrario, una sola caída de DNS puede hacer que servicios sanos parezcan muertos.

¿Cómo deberías nombrar tu dominio interno: .internal, .local o un subdominio?

Para la mayoría de las redes VPS en producción, usa un subdominio de tu propiedad, como internal.example.com. Usa el espacio de nombres .internal solo en una instalación aislada donde sean aceptables las colisiones de nombres entre redes, la gestión de certificados con una CA privada y un tratamiento especial de DNSSEC. Evita .local, que mDNS reserva.

El problema de .local es concreto. RFC 6762 da a los nombres terminados en .local un tratamiento especial para Multicast DNS, así que una zona unicast de BIND 9 o Unbound con el mismo sufijo puede chocar con el comportamiento mDNS en dispositivos Apple y otros sistemas con mDNS. Usa otro espacio de nombres en lugar de confiar en apaños específicos de cada cliente.

Consejo profesional: si heredaste una zona interna en .local, trátala como deuda técnica. Algunos clientes envían las consultas .local a mDNS en lugar de a tu servidor DNS unicast, lo que puede provocar fallos dependientes del cliente o con apariencia intermitente.

La Junta de la ICANN reservó de forma permanente .internal de la delegación en la raíz del DNS público en julio de 2024, tras una recomendación previa del SSAC. Por diseño, los nombres bajo ese TLD no se resolverán a través del DNS global. Eso trae contrapartidas: los nombres .internal no son únicos a escala global, no se espera que las autoridades de certificación públicas emitan certificados para ellos y los resolutores que validan DNSSEC apoyándose en el ancla de confianza global no lograrán resolverlos. Si necesitas HTTPS en .internal, prevé operar una CA privada.

Aquí conviene distinguir dos cosas. La reserva de la ICANN es definitiva. Por otro lado, un Internet-Draft activo, draft-davies-internal-tld-06, se publicó el 6 de mayo de 2026 para documentar el espacio de nombres y compararlo con el direccionamiento privado de la RFC 1918. Sigue siendo un Internet-Draft en curso y no una RFC publicada, así que describe .internal como un TLD de uso privado reservado por la ICANN, no como un estándar del IETF.

Para la mayoría de las flotas de VPS, un subdominio de un dominio que controlas es la opción por defecto más segura. El ISC recomienda una jerarquía de subdominios, como un subdominio interno de tu propio dominio, en lugar de mantener versiones internas y públicas separadas e incompletas de la misma zona padre. Esa preferencia no es cuestión de estilo: evita el fallo de la siguiente sección.

Conclusión de la sección: la decisión sobre el espacio de nombres es de largo recorrido. Un subdominio que controlas es la opción por defecto en la mayoría de los entornos de producción, porque preserva la unicidad global y funciona con la PKI pública. Usa .internal cuando un espacio de nombres privado y aislado encaje mejor y aceptes sus contrapartidas de DNSSEC, certificados y colisiones.

DNS de horizonte dividido y los errores que lo rompen

El DNS de horizonte dividido devuelve para un mismo nombre de host una respuesta distinta según quién pregunte: la IP privada desde dentro, la IP pública desde fuera. Se rompe casi siempre por la trampa del NXDOMAIN en el mismo dominio, de resolutores alternativos que sortean la vista prevista y de rutas DNS de contenedores que no llegan al upstream esperado. Acertar depende de tres cosas a la vez, no de una.

La trampa NXDOMAIN es justamente el fallo del que el ISC advierte directamente. Si tus servidores internos son autoritativos para el dominio padre pero su versión de la zona no contiene un registro público como el host www, un cliente interno que consulte ese nombre recibe NXDOMAIN aunque la zona pública sí lo tenga. La zona interna es autoritativa y no recurre al DNS público para el dominio padre. Justamente por eso el enfoque de jerarquía de subdominios de la sección de nombres es el diseño que prefiere el ISC.

Consejo profesional: antes de apuntar tus servidores a un montaje de horizonte dividido sobre el mismo dominio, prueba desde dentro de la red a resolver un nombre público conocido de ese dominio. Una respuesta NXDOMAIN para un nombre que resuelve bien desde fuera es la firma de esta trampa.

Otros tres escollos pasan desapercibidos con facilidad. Un resolutor alternativo configurado en un host o contenedor puede sortear la separación; según la implementación del resolutor, puede consultarse tras un tiempo de espera o en paralelo, de modo que las respuestas varían. Los contenedores en el bridge por defecto de Docker reciben al arrancar una copia de la configuración DNS del host, mientras que los de redes personalizadas consultan el resolutor integrado de Docker en 127.0.0.11. Ese resolutor reenvía las consultas externas a los servidores DNS configurados para el host o el contenedor, así que el comportamiento del split-DNS depende de la configuración de Docker y del host, y no solo del archivo de resolución propio del contenedor. Si un servicio interno está detrás de un proxy inverso como Gestor de Proxy Nginx, la validación del certificado puede fallar si este no cubre el nombre de host solicitado o si la CA que lo emitió no es de confianza para el cliente. Usar un certificado distinto en el interior no es, por sí mismo, un error. Son huecos de configuración, no fallos de las herramientas.

Los clientes remotos pueden toparse con el mismo fallo cuando una VPN autoalojada no envía ni enruta las consultas DNS al resolutor interno previsto.

También hay una dimensión de seguridad. Si nombres de host internos e IP privadas se filtran a registros DNS públicos, has expuesto parte de tu esquema interno de nombres y direcciones a cualquiera que consulte. El horizonte dividido existe en parte para mantener ese mapa dentro, y una zona pública mal configurada lo deshace en silencio.

Conclusión de la sección: los fallos del horizonte dividido son trampas de configuración, no defectos de las herramientas. La corrección depende de la disciplina de nombres, de saber a qué resolutor consulta realmente cada cliente y de acotar bien la zona, no de un único ajuste.

LEER

Cómo apuntar un dominio a VPS: guía rápida

Conclusión: elegir el diseño de DNS privado adecuado

Ya sabes identificar a qué sistema de "DNS privado" te refieres realmente. Para redes VPS es la zona DNS interna, no el ajuste DNS-over-TLS de Android ni los servidores de nombres autoritativos con marca. Si tu flota es pequeña y estable, /etc/hosts es una elección defendible. Si no lo es, usa un subdominio de tu propiedad como espacio de nombres por defecto, elige el servidor DNS más pequeño que encaje con la flota y mantén explícitos el acceso, la redundancia y el alcance interno frente al público de la zona. Usa .internal solo cuando un espacio de nombres aislado encaje mejor y aceptes sus contrapartidas de certificados, DNSSEC y colisiones.

Preguntas frecuentes