Preliminary discussion: DB alias entries
Nicolas.Williams at sun.com
Thu Mar 5 12:23:13 EST 2009
On Thu, Mar 05, 2009 at 10:04:16AM -0500, Sam Hartman wrote:
> Greg, if you do something like what you are talking about, I think
> Love's approach is the best: a separate key space for aliases. I
> understand there will be multiple lookups but I think that's OK.
I agree. Multiple lookups are not an issue unless they can block a
single-threaded KDC (e.g., imagine using DNS lookups here).
> However, I'd like to ask you to think about whether adding alias
> support to db2 done this way makes any sense at all. If you have a
> major sponsor who really wants aliases in db2 manipulated through
> kadm5, then by all means go forward. What you are proposing is not
> harmful; it just seems like something that very few people will find
> useful and thus is likely to be an inefficient use of the consortium's
> time. Here's why I say that.
Storing aliases in the KDB is almost certain to lead to double entry
procedures for hostname aliases. Like Sam I'm not sure that's a good
idea -- it's OK as an option, but not OK as the only option unless...
...there's a process for synchronizing alias information in the KDB with
a customer's primary source (or DNS, but handled securely). In other
words, I'm arguing for any reasonable variant of Sam's "SQLite3 DB
loaded from DNS zone files" option, including that option too.
Using the LDAP backend doesn't seem like a great idea because it's
likely in some cases that the LDAP backend's DIT will be separate from
the primary DIT for the realm, in which case we're back to double entry
or synchronization, and even if the backend is using the realm's DIT we
still have the problem that full host and aliasing data might not be
present in it.
The one common denominator is that almost every environment using
Kerberos V also uses DNS. So I think we're looking for any reasonable
variant of Sam's "SQLite3 DB loaded from DNS zone files" or any solution
using DNS securely:
* Look in specific DNS domainnames using a _local_ nameserver. Don't
use recursive queries, don't follow delegations, ... If the
canonical name of an alias is not found immediately, then stop
A KDC admin can probably arrange to replicate DNS data to a server
private to the KDC.
I don't terribly love this -- it's exactly what I would want in terms
of avoiding double entry and in terms of how easy it is to arrange
this, but in so far as one could misconfigure the system to do the
lookups on a public, caching server, it scares me.
* Have the KDC do DNS zone transfers (secured somehow) of relevant
zones (the base domainnames can be determined from the contents of
the KDB) and then load them in a DB.
* Use DNSSEC (and multi-thread krb5kdc or re-factor it to be async, and
since the standard resolver APIs are not async, do the DNS lookups in
More information about the krbdev