Konsistenz von Hostname, FQDN und Reverse DNS: Warum Kerberos- und TLS-Namensprüfungen scheitern, wenn die Namen nicht übereinstimmen

Ziel

Bevor ein Kerberos- oder TLS-Fehler wie ein Problem mit Zugangsdaten oder Zertifikat behandelt wird, prüfen, ob der konfigurierte Hostname eines Hosts, sein Forward-DNS-Record und sein Reverse-Record (PTR) übereinstimmen.

Voraussetzungen

Lesezugriff auf /etc/hosts und DNS-Auflösungswerkzeuge unter Linux; unter Windows Resolve-DnsName (oder nslookup). Beides lässt sich ohne erhöhte Rechte ausführen.

Schritte

1. Unter Linux den eigenen vollqualifizierten Namen des Hosts ermitteln: hostname -f (oder hostname --fqdn). Die Man-Page definiert diesen FQDN als den kanonischen Namen, den der Resolver für den Hostnamen zurückgibt. Bei hosts: files dns entscheidet daher eine Zeile in /etc/hosts darüber und nicht DNS. Schlägt der Aufruf fehl oder liefert er nur einen kurzen Namen statt eines FQDN mit Punkten, ist die DNS-Auflösung für den eigenen Namen des Hosts bereits inkonsistent.
2. /etc/hosts auf einen Eintrag prüfen, der DNS überlagert: Das in hosts(5) dokumentierte Dateiformat ordnet pro Zeile einer IP-Adresse einen oder mehrere Namen zu. Ein Eintrag für den eigenen Namen des Hosts wird vor DNS ausgewertet (abhängig von der Reihenfolge in nsswitch.conf) und kann unbemerkt von der DNS-Antwort abweichen.
3. Forward- und Reverse-Auflösung unabhängig voneinander durchführen und vergleichen: Die Forward-Abfrage des FQDN sollte die IP des Hosts liefern, und die Reverse-Abfrage (PTR) dieser IP sollte denselben FQDN zurückgeben. Unter Windows eignet sich Resolve-DnsName <fqdn> für die Forward-Richtung und Resolve-DnsName <ip> -Type PTR für die Reverse-Richtung; die Referenz von Microsoft dokumentiert den PTR-Abfragetyp ausdrücklich.
4. Bei einem Host, der Kerberos-Client oder in eine Kerberos-Domäne eingebunden ist, ist Folgendes zu beachten: Die Anleitung von MIT zur Realm-Konfiguration behandelt die Nutzung von DNS für die Erkennung von Realm und KDC. Weichen Forward- und Reverse-Namen voneinander ab, kann die Kanonisierung des Dienstnamens bei Ticket-Anfragen zu einem anderen Namen führen als dem für den Dienst registrierten SPN. Die Folge ist eine Ticket-Anfrage für den falschen SPN oder für gar keinen. In der krb5.conf von MIT fügt rdns (Standard: true) dieser Kanonisierung eine Reverse-Abfrage hinzu; mit rdns = false oder dns_canonicalize_hostname = false entfällt die Abhängigkeit vom PTR-Record.
5. Bei TLS prüft ein Client, der die Subject Alternative Names eines Zertifikats verifiziert, den Namen, mit dem er die Verbindung aufgebaut hat, und keinen «wahren» Hostnamen. Weichen Forward und Reverse voneinander ab, können verschiedene Werkzeuge in derselben Kette (eines löst vorwärts auf, ein anderes stützt sich für Logging oder Zugriffskontrolle auf eine Reverse-Abfrage) unterschiedliche Namen erwarten.

Erwartetes Ergebnis

hostname -f liefert denselben Namen mit Punkten wie eine Forward-DNS-Abfrage des Hosts, und eine Reverse-Abfrage der IP des Hosts liefert wiederum diesen Namen – alle drei stimmen überein. Eine Kerberos-gesicherte Dienstverbindung und eine TLS-Verbindung zum Host kommen ohne namensbezogene Fehler zustande.

Grenzen und Prüfbasis

Hosts mit mehreren Netzwerkschnittstellen bzw. IPs (Multi-Homed) können legitimerweise einen PTR-Record haben, der nicht zu der Adresse passt, über die ein Client sie erreicht hat. Bevor DNS «korrigiert» wird, ist das als Designfrage zu behandeln und nicht automatisch als Fehler. Änderungen an /etc/hosts oder an DNS-Records wirken sich auf neue Auflösungen aus, sobald lokale Caches (nscd, systemd-resolved, SSSD, der Windows-DNS-Client) und die TTL des Records es zulassen. Bereits zwischengespeicherte Tickets oder bestehende Verbindungen sind davon nicht betroffen: Ein Kerberos-Ticket oder eine TLS-Sitzung, die vor der Korrektur erworben wurde, muss neu bezogen werden.