DNS SRV Record Misconfiguration — Common Cause of Kerberos Authentication Failures

[Vahid Shaik]

Hello,

I wanted to share some patterns I've observed around DNS-related Kerberos failures, since DNS misconfiguration remains one of the most common root causes of "Cannot find KDC for realm" errors.

Kerberos relies on DNS SRV records (_kerberos._udp.REALM, _kerberos._tcp.REALM) and TXT records (_kerberos.REALM) for KDC discovery. When these are misconfigured, authentication silently fails — often without helpful error messages.

Common issues I've seen:

1. Missing SRV records — admins configure A records for the KDC but forget the _kerberos._udp and _kerberos-adm._tcp SRV records. Clients fall back to broadcast or /etc/krb5.conf and discovery breaks in multi-site setups.

2. TTL too high on SRV records — during KDC migration, a 24h TTL on the old SRV record means clients keep hitting the decommissioned KDC for up to a day. Setting TTL to 300s before migration avoids this.

3. Split-horizon DNS — internal vs. external DNS returning different results for _kerberos SRV records. Remote/VPN users get the external response and can't reach the KDC.

4. DNSSEC validation failures — if the realm's DNS zone is DNSSEC-signed but the validating resolver has a stale trust anchor, SRV lookups fail with SERVFAIL. The Kerberos client just sees "no KDC found” with no hint it's a DNSSEC issue.

For diagnosing these, checking the actual DNS responses from the client's perspective is critical — the records may look correct from the admin's resolver but broken from the client's. Tools like DNS Robot (https://dnsrobot.net/dns-lookup) can help verify what different resolvers return for SRV and TXT records globally.

Has anyone else dealt with DNSSEC-related Kerberos failures? Curious if there are best practices for coordinating DNSSEC key rollovers with Kerberos-dependent zones.

Best regards,

Shaik Vahid

DNS Robot — https://dnsrobot.net<https://dnsrobot.net/>

Free DNS & Network Diagnostic Tools