[3903] in Kerberos
Re: hierarchical realms
daemon@ATHENA.MIT.EDU (Vincent Del Vecchio)
Thu Sep 22 16:51:26 1994
To: kerberos@MIT.EDU
Date: Thu, 22 Sep 1994 18:20:29 GMT
From: vdelvecc@crispus.camb.inmet.com (Vincent Del Vecchio)
> But this is three entries, when we really only needed two, since
> lcs.mit.edu defaults to LCS.MIT.EDU without a krb.realms entry.
"Really only needed" because of the semantics you would use for krb.realms.
If you use longest-match, then three are needed. There is an engineering
tradeoff here, obviously. It seems to me that three entries rather than
two is a much smaller price than the iastate administrators have to pay.
> If you subdivide a namespace just for the sake of subdividing the
> namespace, you are doing yourself a disservice. First, you have this
> type of problem. Second, you have to make sure that all your hosts
> are using different names. For example, if you have
> ponderous.cc.your.site and ponderous.xx.your.site, but cc.your.site
> and xx.your.site share a kerberos realm, you now have a name conflict!
> How do you solve that? By making sure all the names are in a flat
> namespace! But if you are doing that, then why subdomain in the first
> place?
The unique names requirement is just another Kerberos restriction.
So your argument seems to be essentially that one should not subdivide
the namespace gratuitously because Kerberos doesn't handle it well.
I would argue that DNS systems have been in common use much longer than
Kerberos has, and many administrators had divided their namespaces for
organizational or other purposes well before they had Kerberos. It
seems unreasonable, to them and me, to either have to flatten their
namespace so that Kerberos works better, or to have to set up a
different realm for each subdomain, since setting up a realm can be
an order of magnitude more work than setting up a new subdomain, and
there may already be many subdomains.
The solution used in Kerberos works for MIT, but it seems to me that
longest-match would work about as well for sites with flat namespaces,
and many times better for sites with many subdomains.
Since the software was developed at MIT primarily for use at MIT, the
decision is neither surprising nor entirely unreasonable, and it seems
everyone else has to live with it, or add local hacks. That doesn't mean
we can't complain when we don't like it, though.
