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

David Woodhouse dwmw2 at infradead.org
Tue Aug 5 07:12:06 EDT 2014


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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20140805/e4ec4341/attachment-0001.bin


More information about the krbdev mailing list