How often does MIT krb5 request for KDC info through DNS?

Nico Williams nico at
Tue Aug 5 11:46:55 EDT 2014

On Tue, Aug 05, 2014 at 12:12:06PM +0100, David Woodhouse wrote:
> On Mon, 2014-08-04 at 12:29 -0500, Nico Williams wrote:
> > Some things should be cached, like: the local host's FQDN (it shouldn't
> > change, right?), default realm (if not set and it had to be determined
> > from context, e.g., the user's or host's realm), and so on.  But not DNS
> > lookups -- that's the resolver's job.  If your resolver is not a caching
> > resolver, then fix it :)
> I'm not sure I agree with that.

Once you start using DNSSEC you may really want this.

> I've watched firefox lock up for *minutes* at a time without redrawing
> itself, and I've found that it's stuck in Kerberos code mostly doing
> the same Legacy IP and IPv6 DNS lookups for the same set of 30-odd
> domain controllers, over and over and over and over and over again.

Browsers run for a long time.  Kerberos libraries often don't.  An
in-memory DNS cache often won't help (though it might not hurt
performance, but then, it will be a source of bugs).

The FILE ccache as a general-purpose cache is a performance disaster too
(because the FILE ccache is a performance disaster, full stop), so
that's out.

> Yes, I deployed a local caching nameserver to help with that (and
> samba-winbind-krb5-locator, and now I'm playing with negative caching on
> KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN...). But I shouldn't have *had* to.

No, you shouldn't have had to.  That should have been cached in the
ccache.  (I know, I'm contradicting myself, but we already use the
ccache as the cache for the successful case...)

> Some level of "our KDC was <here> two seconds ago. Perhaps I could just
> manage to talk to it again without going out on the wire to ask the DNS
> server again" might be appropriate.

Where should this be written?

> The latency was particularly painful in my case because the DNS lookups
> were done over a VPN. Which of course made setting up the local caching
> resolver relatively painful too, since it has to cope with VPN and
> non-VPN mode...

My recommendation is to run a zone/jail/VM/whatever-your-OS-calls-it for
one of the two things (VPN vs. direct Internet access), with the
security conscious running direct Internet access in a zone/jail/VM/...


More information about the krbdev mailing list