SSL, TLS and DNS SRV

[Daniel Pocock <daniel@pocock.com.au>]

I have slapd listening on port 636 only because I want to enforce use of
SSL/TLS

It all works successfully (I now have my UNIX users, mail, and about a
dozen apps authenticating against it), however...

I wanted fault tolerance, and I thought that the way to achieve this
would be using DNS SRV and replication (which was also easy to get working)

What I've observed:

- if I create _ldaps._tcp.example.org SRV records, they are ignored

- if I create _ldap._tcp.example.org SRV records, and I ldapsearch with
a URI of the form "ldaps:///dc%3Dexample%2Cdc%3Dorg" it works

So, it seems to be the combination of the ldaps URI prefix with the
_ldap._tcp SRV record that is working, this doesn't seem right

I've also found that other LDAP apps have slightly different
expectations too:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661955

I went searching for a definite answer:

+site:ietf.org ldaps srv

http://tools.ietf.org/html/rfc2782 refers to the name of the service
from `Assigned Numbers',
http://tools.ietf.org/html/rfc1700
which omits ldaps, but it is defined elsewhere as a distinct service name:
http://www.ietf.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

Therefore, my feeling is that

 - if an ldaps: URI is used, the SRV query should be seeking
_ldaps._tcp, and

 -if an ldap: URI is used (and StartTLS may or may not be requested by
the user), the SRV query should be looking for _ldap._tcp

Also, can anyone comment on why the URI needs to be escaped manually
when using DNS SRV?