Cohérence entre nom d'hôte, FQDN et DNS inverse : pourquoi les vérifications de nom Kerberos et TLS échouent en cas de désaccord

Objectif

Vérifier que le nom d'hôte configuré d'une machine, son enregistrement DNS direct et son enregistrement inverse (PTR) concordent, avant de diagnostiquer un échec Kerberos ou TLS comme s'il s'agissait d'un problème d'identifiants ou de certificat.

Prérequis

Un accès en lecture à /etc/hosts et aux outils de résolution DNS sous Linux ; Resolve-DnsName (ou nslookup) sous Windows. Dans les deux cas, aucun privilège élevé n'est nécessaire.

Étapes

1. Sous Linux, obtenir le nom complet (FQDN) que l'hôte se donne lui-même : hostname -f (ou hostname --fqdn). La page de manuel définit ce FQDN comme le nom canonique que le résolveur renvoie pour le nom de l'hôte ; avec hosts: files dns, c'est donc une ligne de /etc/hosts qui en décide, et non le DNS. Si la commande échoue ou renvoie un simple nom court au lieu d'un FQDN avec des points, la résolution DNS du nom propre de l'hôte est déjà incohérente.
2. Vérifier dans /etc/hosts s'il existe une entrée qui masque le DNS : le format décrit dans hosts(5) associe une adresse IP à un ou plusieurs noms sur chaque ligne ; une entrée correspondant au nom de l'hôte est consultée avant le DNS (selon l'ordre défini dans nsswitch.conf) et peut diverger silencieusement de ce que dit le DNS.
3. Résoudre indépendamment le nom en direct et en inverse, puis comparer : la résolution directe du FQDN doit renvoyer l'IP de l'hôte, et la résolution inverse (PTR) de cette IP doit renvoyer le même FQDN. Sous Windows, utiliser Resolve-DnsName <fqdn> pour le sens direct et Resolve-DnsName <ip> -Type PTR pour le sens inverse ; la documentation de référence de Microsoft mentionne explicitement le type de requête PTR.
4. Pour un hôte joint à Kerberos ou client Kerberos en particulier, noter que les recommandations de MIT sur la configuration des realms évoquent le recours au DNS pour la découverte du realm et du KDC. Si les noms direct et inverse divergent, la canonicalisation du nom de service lors des demandes de ticket peut aboutir à un nom différent du SPN enregistré pour le service, ce qui entraîne une demande de ticket pour un mauvais SPN (ou pour aucun). Dans le krb5.conf de MIT, rdns (true par défaut) ajoute une résolution inverse à cette canonicalisation ; rdns = false ou dns_canonicalize_hostname = false supprime la dépendance au PTR.
5. Pour TLS, un client qui vérifie les Subject Alternative Names d'un certificat contrôle le nom qu'il a utilisé pour se connecter, et non un nom d'hôte « réel » ; si les résolutions directe et inverse divergent, différents outils d'une même chaîne (l'un résolvant en direct, l'autre s'appuyant sur une résolution inverse pour la journalisation ou le contrôle d'accès) peuvent finir par attendre des noms différents.

Résultat attendu

hostname -f renvoie le même nom pointé que la résolution DNS directe de l'hôte, et la résolution inverse de l'IP de l'hôte renvoie ce même nom : les trois concordent. Une connexion à un service Kerberisé et une connexion TLS vers l'hôte réussissent sans erreur liée aux noms.

Limites et base de vérification

Un hôte multi-homed (plusieurs interfaces réseau ou adresses IP) peut légitimement avoir un enregistrement PTR qui ne correspond pas à l'adresse utilisée par un client pour l'atteindre ; il faut y voir une question de conception, et non automatiquement un bogue, avant de « corriger » le DNS. Une modification de /etc/hosts ou des enregistrements DNS ne s'applique aux nouvelles résolutions qu'une fois que les caches locaux (nscd, systemd-resolved, SSSD, client DNS de Windows) et le TTL de l'enregistrement le permettent, et n'affecte pas les tickets ni les connexions déjà en cache ; un ticket Kerberos ou une session TLS obtenus avant la correction doivent être obtenus à nouveau.