Coherencia entre hostname, FQDN y DNS inverso: por qué fallan las comprobaciones de nombre de Kerberos y TLS cuando no coinciden

Objetivo

Comprobar que el hostname configurado de un equipo, su registro DNS directo y su registro inverso (PTR) coinciden entre sí, antes de diagnosticar un fallo de Kerberos o TLS como si fuera un problema de credenciales o de certificado.

Requisitos previos

Acceso de lectura a /etc/hosts y herramientas de resolución DNS en Linux; Resolve-DnsName (o nslookup) en Windows. Ambas opciones pueden ejecutarse sin privilegios elevados.

Pasos

1. En Linux, obtén el nombre completo (FQDN) que el propio equipo cree tener: hostname -f (o hostname --fqdn). La página del manual define este FQDN como el nombre canónico que el resolvedor devuelve para el nombre del host; por tanto, con hosts: files dns, lo determina una línea de /etc/hosts y no el DNS. Si el comando falla o devuelve solo un nombre corto sin puntos en lugar de un FQDN, la resolución DNS del nombre del propio equipo ya es inconsistente.
2. Revisa en /etc/hosts si hay una entrada que oculte al DNS: el formato descrito en hosts(5) asocia una dirección IP con uno o más nombres en cada línea; una entrada para el nombre del propio equipo se consulta antes que el DNS (según el orden de nsswitch.conf) y puede discrepar en silencio de lo que dice el DNS.
3. Resuelve por separado el sentido directo y el inverso y compara: la consulta directa del FQDN debe devolver la IP del equipo, y la consulta inversa (PTR) de esa IP debe devolver el mismo FQDN. En Windows, usa Resolve-DnsName <fqdn> para el sentido directo y Resolve-DnsName <ip> -Type PTR para el inverso; la referencia de Microsoft documenta explícitamente el tipo de consulta PTR.
4. En el caso concreto de un equipo unido a Kerberos o cliente de Kerberos, ten en cuenta que la propia guía de MIT sobre la configuración de realms comenta el uso de DNS para descubrir el realm y el KDC. Si los nombres directo e inverso no coinciden, la canonicalización del nombre del servicio durante las solicitudes de ticket puede resolverse a un nombre distinto del SPN registrado para el servicio, y la solicitud de ticket se hará para un SPN incorrecto (o para ninguno). En el krb5.conf de MIT, rdns (por defecto true) añade una búsqueda inversa a esa canonicalización; con rdns = false o dns_canonicalize_hostname = false se elimina la dependencia del PTR.
5. En TLS, un cliente que verifica los Subject Alternative Names de un certificado comprueba el nombre con el que se conectó, no un hostname «verdadero». Si el sentido directo y el inverso discrepan, distintas herramientas de la misma cadena (una que resuelve en sentido directo y otra que se apoya en una búsqueda inversa para registros o control de acceso) pueden acabar esperando nombres diferentes.

Resultado esperado

hostname -f devuelve el mismo nombre con puntos que una consulta DNS directa del equipo, y una consulta inversa de la IP del equipo devuelve ese mismo nombre: los tres coinciden. Una conexión a un servicio con Kerberos y una conexión TLS al equipo se establecen sin errores relacionados con el nombre.

Límites y base de verificación

Los equipos con varias interfaces o IP (multihomed) pueden tener legítimamente un registro PTR que no coincide con la dirección que usó un cliente para llegar a ellos; antes de «arreglar» el DNS, trátalo como una cuestión de diseño y no automáticamente como un error. Los cambios en /etc/hosts o en los registros DNS surten efecto en las nuevas resoluciones una vez que lo permiten las cachés locales (nscd, systemd-resolved, SSSD, el cliente DNS de Windows) y el TTL del registro, pero no afectan a los tickets ni a las conexiones que ya están en caché; un ticket de Kerberos o una sesión TLS obtenidos antes de la corrección deben obtenerse de nuevo.