Slipping in/out KDCs....what is KRB5 client behaviour? Spike_White at
Fri Sep 2 12:46:26 EDT 2016


Thank you for confirming this Kerberos5 client behavior.  Yes, we set:

dns_lookup_kdc = false
dns_lookup_realm = false

For these non-site-aware apps (typically java apps).



Date: Thu, 1 Sep 2016 20:50:16 -0400 (EDT)
From: Benjamin Kaduk
Subject: Re: Slipping in/out KDCs....what is KRB5 client behaviour?
To: Spike_White at
Cc: krbdev at
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 1 Sep 2016, Spike_White at wrote:

> All,
> I have a question about KDC client behavior that does not seem to be documented well. (I think I know the behavior but want to confirm.)
> Long boring back-story why I need to know this behavior, won't bore you with the full details. Suffice to say, these particular apps are not site-aware, so these KRB5 clients cannot do the basic DNS SRV lookups to find their KDCs. (Else they may be round-robined to a KDC geographically far far away.)
> Instead, they do this:
> [realms]
> kdc =
> kdc =
> kdc =
> ...
> }
> We've stood up new KDCs and are in the process of retiring old KDCs.
> My understanding is that Kerberos clients always consults the KDC in the first kdc entry. So unless this above pool above returns a KDC, this client will never consult and .
> Thus as long as the load-balanced kdc pools are populated w/ only the new KDCs, the above syntax will not produce errors. (It's aesthetically poor, but the alternative is touching thousands of prod servers - to improve aesthetics.)
> BTW, this load-balancing technology only round-robins among responsive geographically-close KDCs (well, daemons listening on port 88 anyway).
> Is my KRB5 client understanding correct? I.e., they go sequentially in order in consulting KDCs, according to their entries in the krb5.conf file?

Well, I thought the default behavior was to do a SRV lookup for the KDC
list, which should round-robin through the DNS entries with the resolver's
behavior, but if you disable dns_lookup_kdc, that's correct. (And maybe
I'm wrong about the default behavior.)


More information about the krbdev mailing list