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

Spike_White@dell.com Spike_White at dell.com
Tue Aug 5 15:50:17 EDT 2014


Doesn't "name service caching"  via nscd solve this?

Setting up a caching-only DNS server is pretty simple.

Changing 1-2 lines in /etc/nscd.conf and chkconfig/starting the nscd service is even easier.

Spike

Message: 3
Date: Tue, 05 Aug 2014 12:12:06 +0100
From: David Woodhouse
Subject: Re: How often does MIT krb5 request for KDC info through DNS?
To: Nico Williams
Cc: krbdev at mit.edu
Message-ID:
Content-Type: text/plain; charset="utf-8"

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.

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.

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.

Some level of "our KDC was 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.

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...

Thankfully, NetworkManager under Linux copes with this fairly well these days, but in the general case it's not a trivial thing that you're suggesting.

--
dwmw2


More information about the krbdev mailing list