Por qué un registro SRV solo ayuda a un cliente que lo consulta

Añadir un registro SRV a su zona no enseña a ningún cliente VPN a buscarlo. El cliente tiene que conocer la etiqueta, decidir enviar la consulta y actuar según lo que vuelva, y el DNS no puede aportar las dos primeras cosas. Por eso la mayoría de los planes SRV fallidos son problemas de cliente disfrazados de DNS. Lea primero el comportamiento de descubrimiento del cliente y luego publique solo la etiqueta que realmente consulta.

Un registro que nadie consulta no puede ayudar a nadie

El SRV publica la ubicación de un servicio; no lo anuncia. Nada empuja un registro hacia un cliente, y ningún resolutor ofrece un nombre que nunca se pidió. La búsqueda empieza cuando la aplicación decide hacerla, así que la etiqueta tiene que venir de la documentación del producto o de observar el software en la red. Donde el cliente no tiene ningún paso de descubrimiento, un registro cambia la zona y nada más.

Por eso un producto en una red puede empezar a funcionar mientras otro no se ve afectado por el mismo cambio. La variable es el software, y el servidor DNS hace exactamente lo que se le dijo. Vuelva a leer la zona después de la edición, porque una etiqueta mal escrita se esconde con facilidad entre registros que parecen todos iguales.

Lea los campos antes de escribirlos

Un registro lleva cuatro valores, y cada uno responde a una pregunta distinta: la prioridad ordena los destinos que un cliente puede probar, el peso reparte la carga entre destinos de igual prioridad, el puerto nombra el puerto de transporte y el destino nombra el host. La especificación también permite que un destino de . signifique que el servicio no está disponible a propósito, lo cual es una respuesta útil y no una rota.

Ninguno de esos campos lleva credenciales, una política de certificados ni una versión de la aplicación, y un cliente que ignora el peso se conecta igual, solo que sin el equilibrio previsto. El destino necesita registros de dirección propios, y debería ser un nombre canónico en lugar de un alias. Publicar un registro que apunta a un host sin ningún receptor produce un error de conexión que se lee como un fallo de DNS, y ese es el tipo de engaño más caro. Publique toda la cadena o nada de ella.

Encuentre la etiqueta que el cliente envía de verdad

Establezca la etiqueta a partir de pruebas y no de una suposición sobre el nombre del producto. O bien la documentación indica el nombre del servicio, o bien una captura muestra la consulta que sale del cliente al arrancar. Ambas rutas terminan en el mismo punto: un nombre y un tipo exactos para probar contra el resolutor.

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

Compare la respuesta con el registro que publicó, carácter a carácter, porque los guiones bajos y el punto final forman parte del nombre. Una respuesta vacía a una consulta que sí se envió apunta a la zona, mientras que la ausencia total de consulta apunta al cliente, y esos hallazgos le llevan a equipos distintos. Una respuesta real se parece a la línea de abajo, donde la prioridad 20 pierde frente a cualquier registro de prioridad más baja y el cliente marca el puerto 8443 en el destino indicado.

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

El destino también tiene que existir

Un destino que resuelve no es lo mismo que un servicio que responde. Compruebe los registros de dirección del destino y luego compruebe que algo escucha en el puerto y el protocolo publicados. Un registro TCP que apunta a un receptor solo UDP es una discrepancia que ninguna edición de la zona repara. Mantenga el TTL corto mientras el destino sea inestable, y alárguelo cuando el nombre deje de moverse.

Los clientes que sí implementan el descubrimiento varían en cuánto del registro respetan. Algunos usan solo la prioridad, otros tratan el peso como consejo y unos pocos ignoran el puerto y suponen un valor por defecto. Esas diferencias pertenecen a sus notas junto a la etiqueta, porque explican un comportamiento que de otro modo parece un fallo del resolutor.

El descubrimiento no es autenticación

Una respuesta SRV dice a dónde conectarse, y no dice nada sobre en quién confiar una vez que llega. Deje la validación del certificado y las comprobaciones de identidad del servidor del cliente exactamente como estaban, porque un registro que otro puede falsificar no debería convertirse en una decisión de confianza. Las respuestas DNS se pueden almacenar y editar por quien controla la zona, lo que las convierte en un mal lugar para codificar políticas.

Para un cliente sin soporte de descubrimiento, distribuya el perfil o la URL de puerta de enlace que sí acepta, y anote qué producto usa qué método. Esa nota impide que el siguiente administrador añada un registro y espere que funcione en todas partes. La especificación SRV describe la selección entre destinos, y leerla como un mecanismo de autorización es la forma en que un registro útil se convierte en una suposición de seguridad. Publique a conciencia, nombre la etiqueta en su documentación y trate al cliente como el componente que decide si algo de esto importa.