¿Nombre DNS privado o solo una IP? Decida antes de compartirlo

Dos preguntas se mezclan cuando un servicio privado se abre a usuarios remotos. La primera es qué nombre deben usar los clientes; la segunda, qué fuentes debe admitir el servicio. Respóndalas en ese orden, porque un nombre correcto detrás de una regla de acceso equivocada sigue fallando, y una regla correcta detrás de un nombre que no se resuelve nunca llega a probarse.

Condición uno: ¿qué ruta de resolutor tienen los clientes?

Un nombre privado solo funciona si el resolutor del cliente puede responderlo. Eso significa que un cliente remoto autorizado debe llegar a un servidor DNS que tenga la zona, ya sea por el túnel o por un resolutor que la organización ya ejecuta para usuarios remotos. El túnel es un transporte, no un directorio. Da al cliente una ruta hacia un resolutor, y no le dice qué zona preguntar.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

Un resolutor público no aprenderá una zona privada porque el portátil se haya conectado a una VPN.

El sufijo merece la misma atención. Use un subdominio de un dominio que la organización controle, para que la propiedad y la planificación de certificados sigan explícitas. Evite .local: la especificación de DNS multicast ata ese sufijo a la resolución link-local, y un túnel enrutado no reproduce ese comportamiento por usted.

Condición dos: ¿qué fuente recibe el servicio?

Las reglas de admisión se escriben contra direcciones, así que la pregunta útil es qué dirección ve el servicio tras el enrutamiento y la traducción. Para un servicio de ejemplo en 10.20.30.40, los clientes de oficina llegan desde 10.20.30.0/24 y los clientes remotos desde un grupo separado como 10.99.0.0/24.

Si una puerta de enlace traduce el grupo remoto, el servicio ve al traductor, y una regla escrita para 10.99.0.0/24 no coincidirá.

Lea esto desde el lado del servicio y no desde el lado del cliente. Un registro de escucha o una captura de paquetes en el host del servicio muestra la fuente que llegó realmente; la dirección del propio cliente solo es una conjetura sobre lo que sobrevivió a la ruta.

Condición tres: ¿el nombre está ligado a un servicio o a un host?

Un nombre que apunta a la dirección de una máquina vincula a cada cliente con esa máquina. Un nombre que apunta a un balanceador de carga o a una dirección de servicio estable sobrevive a la sustitución del host que hay detrás. Elija a conciencia, porque cambiarlo después significa cambiar los marcadores de cada cliente y el sujeto de cada certificado.

Para un único servicio interno, un registro directo suele estar bien y es más sencillo de razonar.

Para cualquier cosa que vaya a sustituirse, reconstruirse o escalarse, un frontal estable merece la configuración adicional. La prueba es simple: si puede sustituir el backend sin avisar a los usuarios, el nombre está ligado al servicio; si no puede, está ligado a un host.

Pruebe las dos decisiones por separado

Resuelva primero, luego conecte. Una prueba de resolución que devuelve la dirección esperada demuestra la ruta del nombre y no dice nada sobre la admisión. Una prueba de conexión demuestra la ruta y la regla juntas, así que ejecútela solo después de que la resolución tenga éxito.

curl -sv --max-time 5 https://files.corp.example/health

Después pruebe una fuente prohibida una vez y registre el resultado.

Mantenga los dos registros separados en su documentación: el nombre y su zona, las fuentes admitidas y el propietario de la regla. Cuando uno cambia, el otro no tiene por qué.

Dónde suele salir mal la decisión

El fallo habitual es un servicio publicado bajo un nombre que solo se resuelve en la red de oficina, con una regla de admisión que solo admite el rango de oficina. Los usuarios remotos informan entonces de un servicio roto que en realidad son dos omisiones separadas. El segundo fallo habitual es el inverso: una regla de admisión amplia añadida para eliminar un problema de nombre deja el servicio accesible desde fuentes que nadie pretendía. Ambas son omisiones de configuración, y desde la silla del usuario se ven igual.

Ninguno de los dos errores es visible desde una sola prueba correcta. Por eso las dos decisiones merecen registros separados y pruebas separadas, incluso cuando las toma la misma persona.

Escriba ambas antes de que el servicio entre en producción, porque el siguiente cambio será más fácil de razonar. El registro es corto: una línea para el nombre y su zona, una línea para las fuentes admitidas y el propietario de la regla.