[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: alternate "dc" naming conventions
"Kurt D. Zeilenga" writes:
> 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
I think what are you saying is, anything that is registered
in dns as
_ldap._tcp.es.net
like
w2kdomain.es.net
whitepages.es.net
grid-yellowpages.es.net
must be prepared to provide service or referrals for anything
with dc=es,dc=net as the (appropriate) part of its base name,
is that right?
(If not) please straighten me out!
(If so)
I didn't realize this level of coherence was required ... I don't
think it's that explicit in the locator draft. Should it be?
(Same applies to forbidding chasing dns search upwards)
Something about this level of coherence makes me nervous, but I'm
not exactly sure what. I don't think I expect it to work perfectly
(suppose one of the _ldap._tcp.es.net rr's points to a
stupid server that gives out bad or incomplete information). I would be
inclined to code an ldap client to look up all the servers
it gets from the dns lookup and exhaust the list of servers in case the
previous ones didn't have the base name it was looking for.
But maybe that's undesirable behavior in some other context.
Leaving aside the dangling o=grid rdn, it seems like one
appropriate way to use dns srv for grid directory servers
is to register a referral server that could deal with the
restriction above & that clients could find by the usual
_ldap._tcp.my.domain query. How or whether the other servers
would be registered in dns is tbd. They probably should be
registered, if at all, as some other service or services.