[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: alternate "dc" naming conventions



At 12:55 PM 7/5/2001, Michael Helm wrote:
>"Kurt D. Zeilenga" writes:
>> I thought your approach was, like the PKI suggestion, to use
>> all the DC RDNs contained in the DN.
>
>> >They're altogether in one sequence.  It's just the order
>> >of rdn's is different than the locator draft's. 
>> 
>> So, your approach is to use the first (when looking right
>> to left) adjacent set of RDN containing DCs.  This is interesting,
>
>Yes
>
>> but I'd still be concerned that DNs held in different servers
>> would have to share the same SRV RRs.
>
>Understood. 
>
>Is there any reason to think this might not be a problem in
>other infrastructures anyway (eg the Active Directory - based
>W2K domain)?  Suppose a simpler example: one
>directory that manages authentication, with basename ou=users,
>dc=es,dc=net, & another that manages a phone book, basename
>ou=staff,dc=es,dc=net; these two are only loosely coordinated
>(or not).
>Sure, the clients of these servers could get confused.
>They would have to be smart enough to rotor thru the 
>DNS SRV RR's they get back (unlikely).

No.  In the absence of knowledge information in the servers
holding these two contexts, the client would either
        1) success
        2) noSuchObject

both are definitive answers.

In this setup, which is quite common BTW, the superior service
needs to hold a subordinate reference and the subordinate
service needs to hold a superior reference.  Then the client
gets either
        1) success
        2) referral

and things work.

I guess my concerns are restricted to a subcase of the case
I described.

When there are two DNs:
        ou=foo,dc=example,dc=com
        ou=bar,dc=example,dc=com

which may likely held on two different servers and it is
generally expected (and required for "locate" I-D to work)
that the server holding "dc=example,dc=com" holds knowledge
information regarding its subordinates.  To avoid the referral,
dc should be used for the subordinate contexts (which allows
for independent SRVs).

However, if one has two DNs:
        ou=foo,dc=example,dc=com,o=X
        ou=bar,dc=example,dc=com,o=Y

which are likely held on two different servers, it generally NOT
expected that there be a superior service holding knowledge
information for its subordinates.  It should not be assumed
from these entries related in any particular way to entries
at:
        dc=example,dc=com

or to domain example.com.

>> I believe co-existence requires the server which SRV points the
>> client at to hold either the entry or knowledge information to
>> where the entry is held.
>
>Is it "requires"?

IMO, yes.  Because the knowledge cannot be held in DNS (using
dc-based DNS SRV RRs), it needs be held in LDAP.