> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Tuesday, August 13, 2002 21:36
> To: Patrik Fältström
> Cc: Michael Armijo; Paul Leach; Levon Esibov;
> rlmorgan@washington.edu; ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se
> Subject: Re: [ldapext] draft-ietf-ldapext-locate
<snip>
>
> >(1) This document specifies two things: How to translate a
> DN to a DNS
> >name and how to use a DNS name to locate a corresponding LDAP server.
>
> I argue that the document specifies one process, to locate
> LDAP servers with knowledge of a particular DN, which has two steps.
>
> >The document seems to imply that the latter is only used when a DNS
> >name is produced by the former. I wonder if this restriction
> is a good
> >idea: Isn't the ability to use SRV records to locate more generally
> >useful than this limited context?
>
> I don't believe this document restricts how DNS SRV records
> can be used.
I think the real question being asked was "Isn't the ability to use SRV
records to locate _LDAP servers_ more generally useful than this limited
context?".
If so, then I agree that it is more generally useful. Independently of
DC laden DNs, ff one has the name of a domain, name, say "mit.edu", and
wants to find LDAP servers associated with that domain, then it is
logical that one should look up SRV RRs for "_ldap._tcp.mit.edu".
However, I think that this capability is already adequately specified in
RFC 2782 (DNS SRV RR RFC), where it says:
"The format of the SRV RR
Here is the format of the SRV RR, whose DNS type code is 33:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
(There is an example near the end of this document.)
Service
The symbolic name of the desired service, as defined in Assigned
Numbers [STD 2] or locally. An underscore (_) is prepended to
the service identifier to avoid collisions with DNS labels that
occur in nature.
..."
In the case of LDAP, the symbolic name is "LDAP".
If the question was really intended to NOT be LDAP specific, then it is
clear that RFC 2782 is the place where the ability to use SRV records in
general is specified.
Paul
It also doesn't restrict construction of
> additional processes for locating LDAP servers with knowledge
> of a particular DN. In fact, draft-zeilenga-ldap-x500-locate
> suggests a process for DNs using geo-political naming.
>
> Additionally, DNS SRVs could be used to answer questions such
> as "Are there LDAP servers associated with this domain?". Of
> course, this would be followed by, "What DN is used by the
> owner of this domain for their objects?". If a listed server
> provides 100s of namingContext, which one is the right one?
> Luckily, we have RFC 2247 which says how the owner of the
> domain should name objects.
>
> >The answer to this may be no, but if so, the rationale for
> that answer
> >should be part of the specification.
> >
> >(2) I don't see any provision for fallback to A records if
> SRV records
> > don't exist. I can easily see this being a Bad Idea,
> if so, there
> > should be an explicit prohibition of it in the
> document along with
> > some explanation of why it is a bad idea.
>
> It is a bad idea. A short explanation would be appropriate.
>
>
>
>
> >-------
> >References should be split in normative and non-normative.
> >-------
> >I wonder about the reference to RFC1700, which has been obsoleted by
> >RFC3232, and that RFC actuallt talks about a DB that
> contains the info.
> >So How should this doc refer to that?
> >-------
> >Needs better abstract; doesn't even use the word "SRV". (and the rfc
> >editor will surely complain when they get it...)
> >
> >Might be good to use SRV in the title as well, as opposed to just
> >"DNS". But this I'm less concerned about, as there are two
> steps, and
> >only the second step is SRV records.
> >
> >E.g., maybe change:
> >
> > Discovering LDAP Services with DNS
> >
> >To something like:
> >
> > Discovering LDAP Services with DNS SRV Resource Records
> >
> >However, the rfc editor probably won't like the abbreviation "SRV".
> >Unfortunately, I don't think the acronym expands into
> anything useful.
>
> SRV is not an abbreviation, but IANA-registered DNS RR Type.
> http://www.iana.org/assignments/dns-parameters
>
>
> >-------
> >I
> have three concerns here:
>
> see above.
>
> Kurt
>
>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature