Hostname, FQDN and reverse DNS consistency: why Kerberos and TLS name checks break when they disagree

Goal

Verify that a host's configured hostname, its forward DNS record and its reverse (PTR) record all agree, before troubleshooting a Kerberos or TLS failure as if it were a credentials or certificate problem.

Prerequisites

Read access to /etc/hosts and DNS resolution tools on Linux; Resolve-DnsName (or nslookup) on Windows; either can be run without elevated privileges.

Steps

1. On Linux, get the host's own idea of its fully qualified name: hostname -f (or hostname --fqdn). The man page defines this FQDN as the canonical name the resolver returns for the host name, so with hosts: files dns an /etc/hosts line decides it, not DNS. If this fails or returns a bare short name instead of a dotted FQDN, DNS resolution for the host's own name is already inconsistent.
2. Check /etc/hosts for an entry that shadows DNS: the file format documented in hosts(5) maps an IP address to one or more names on each line; an entry here for the host's own name is consulted before DNS (subject to nsswitch.conf order) and can silently disagree with what DNS says.
3. Resolve forward and reverse independently and compare: forward lookup of the FQDN should return the host's IP, and a reverse (PTR) lookup of that IP should return the same FQDN. On Windows, Resolve-DnsName <fqdn> for the forward direction and Resolve-DnsName <ip> -Type PTR for the reverse; Microsoft's reference documents the PTR query type explicitly.
4. For a Kerberos-joined or Kerberos-client host specifically, note that MIT's own realm-configuration guidance discusses relying on DNS for realm and KDC discovery — if forward/reverse names disagree, canonicalization of the service name during ticket requests can resolve to a different name than the SPN registered for the service, causing a ticket request for the wrong (or no) SPN. In MIT's krb5.conf, rdns (default true) adds a reverse lookup to that canonicalization; rdns = false or dns_canonicalize_hostname = false removes the PTR dependence.
5. For TLS, a client verifying a certificate's Subject Alternative Names checks the name it used to connect, not a "true" hostname; if forward and reverse disagree, different tools in the same chain (one resolving forward, one relying on a reverse lookup for logging or access control) can end up expecting different names.

Expected result

hostname -f returns the same dotted name as a forward DNS lookup of the host, and a reverse lookup of the host's IP returns that same name — all three agree. A Kerberized service connection and a TLS connection to the host succeed without name-related errors.

Limits and test basis

Multi-homed hosts (more than one network interface/IP) can legitimately have a PTR record that does not match the address a client used to reach it; treat that as a design question, not automatically a bug, before "fixing" DNS. Changing /etc/hosts or DNS records takes effect for new resolutions once any local cache (nscd, systemd-resolved, SSSD, the Windows DNS client) and the record's TTL allow, but does not affect already-cached tickets or connections; a Kerberos ticket or TLS session obtained before the fix must be re-obtained.