Subject: RE: [ldapext] draft-ietf-ldapext-locate

From: "Paul Leach" <[email-masked]>
Date: Wed, 14 Aug 2002 16:59:45 -0700

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]] 
> Sent: Tuesday, August 13, 2002 21:36
> To: Patrik Fältström
> Cc: Michael Armijo; Paul Leach; Levon Esibov; 
> [email-masked]; [email-masked]; Ned Freed; [email-masked]
> 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
> 
>

---

From: [email-masked]
Date: Thu, 15 Aug 2002 10:12:52 -0700 (PDT)

> > > (1) This document specifies two things: How to translate a  DN to a DNS

> > > name is produced by the former. I wonder if this restriction is a good

> records to locate _LDAP servers_ more generally useful than this limited

Yes, that's the question I was asking.

> In the case of LDAP, the symbolic name is "LDAP".

Er, no. I remember this one... I wasn't an AD at the time but I was the IAB's
liason to the IESG. There was strong objection from the IESG to this DNS ops
document specifying how a particular application service should be located
using SRV records. As a result the text was modified to include the following:

   Note: LDAP is chosen as an example for illustrative purposes only,
   and the LDAP examples used in this document should not be considered
   a definitive statement on the recommended way for LDAP to use SRV
   records. As described in the earlier applicability section, consult
   the appropriate LDAP documents for the recommended procedures.

The bottom line is that if you think this sufficies as a specification of the
way to use SRV records to locate LDAP, you're mistaken. (And I know a
particular person who was on the IESG at the time who would be very amused to
hear this mistake was made.)

I don't know if this changes the previous assertion that this document
shouldn't make such a recommendation. Either way is fine with me as long
as it is clear what is meant.

				Ned

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext