Kerberos, DNS and AAAA records

james bardin jbardin at bu.edu
Thu May 21 11:55:29 EDT 2009


On Thu, May 21, 2009 at 10:43 AM, Ken Raeburn <raeburn at mit.edu> wrote:
>
> This is probably a result of specifying KDC names in krb5.conf without the
> trailing ".", the standard notation for indicating a fully-qualified name.
>  If the trailing dot isn't included, typically the DNS library software will
> follow the DNS search path (which in the typical case just involves
> appending the local domain, but more than one domain can be given) trying to
> "complete" the name and find the first one that exists.  So sometimes you
> can see queries for "host.foo.com.foo.com" resulting from having
> "host.foo.com" (no trailing dot) given.  If you add the trailing dot in the
> config files, that should fix that problem.  If you use DNS SRV records
> instead of config file entries, the hostnames there are defined to be
> fully-qualified, so again this problem should go away -- though you've added
> back some DNS queries for the SRV records.
>

That is exactly what I needed to know. I didn't think to try adding
the trailing dot in the config file, because it's not in any MIT
kerberos documentation (that I found). Upon testing, this resolves the
excessive AAAA lookups.

> There have also been bugs in some of the getaddrinfo() library
> implementations where the searches for A and AAAA records are done
> completely independently, and each search is done until some name returns
> data.

I think we're OK here. We simply don't have AAAA records in place yet,
and they are checked first by default. I've also seen some bugs
mentioned about getaddrinfo(), so I may look into it a bit more later.


> There are probably also cases where we look up names more times than is
> necessary, because of the current structure of the code.  In many system
> configurations a local name service cache makes this reasonably efficient
> anyways.  But we should try to eliminate some of that redundancy.  We do
> have an in-library cache for some DNS data in case there's no local cache,
> but I think it's currently only enabled for some platforms, and I don't
> think it caches negative responses.
>
>> Why does every kerberos call need to lookup every kdc in the config
>> file, and not just the server which is going to be queried, and is
>> this configurable?
>
> It's not going to only talk to one of them; it'll go through the list
> repeatedly, trying each until it gets an answer, or times out.  Again, it's
> a matter of the structure of the code -- we get a list of addresses and then
> loop over the list.  We could restructure it to look up the address when
> first needed, i.e., the first time we try to reach each server, but that'll
> add complexity to already complicated routines.  (We juggle multiple file
> descriptors, so if we don't get a response back promptly from the first
> server address and decide to go try the next one, we still keep listening
> for a response from the first in case it's just slow and not actually
> unreachable.  But that means we're eventually managing up to one file
> descriptor per server address, some UDP, some TCP.)  There are also
> asynchronous name-lookup techniques, but I think the most portable versions
> require multithreading support and creation of threads, which capabilities
> we're not requiring of the OS and application at present.
>

This is what I suspected. Thanks for all the info!

-jim

-- 
James Bardin <jbardin at bu.edu>
Systems Analyst / Administrator
Boston University




More information about the Kerberos mailing list