[39584] in Kerberos

home help back first fref pref prev next nref lref last post

=?Windows-1252?Q?DNS_SRV_Record_Misconfiguration_=97_Common_Cause_of_Kerb?=

daemon@ATHENA.MIT.EDU (Vahid Shaik)
Mon Mar 2 12:19:48 2026

From: Vahid Shaik <vahid@dnsrobot.net>
To: "kerberos@mit.edu" <kerberos@mit.edu>
Date: Mon, 2 Mar 2026 17:19:29 +0000
Message-ID: <LV1P223MB1304C2F015A429A91DBB9FB5C47EA@LV1P223MB1304.NAMP223.PROD.OUTLOOK.COM>
Content-Language: en-IN
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit

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

________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos


home help back first fref pref prev next nref lref last post