ldap_int_sasl_bind() and canonical Kerberos names

[Geert Jansen <geert@boskant.nl>]

Hi,

at the moment, ldap_int_sasl_bind() uses ldap_host_connected_to() to get 
a fully qualified host name that will be used as the server fqdn with 
the sasl client. This fqdn is acquired by ldap_host_connected_to() using 
a reverse DNS lookup. The code explains why this is done:

       /*
        * do a reverse lookup on the addr to get the official hostname.
        * this is necessary for kerberos to work right, since the official
        * hostname is used as the kerberos instance.
        */

Using reverse DNS names has however always been problematic. The 
following comment is from the MIT code: (lib/krb5/os/sn2princ.c):

               /* XXX: This is *so* bogus.  There are several cases where
                  this won't get us the canonical name of the host, but
                  this is what we've trained people to expect.  We'll
                  probably fix it at some point, but let's try to
                  preserve the current behavior and only shake things up
                  once when it comes time to fix this lossage.  */

To address this issue, a draft RFC has been written 
(draft-ietf-krb-wg-kerberos-referrals-09) that adds server-side name 
canonicalisation to Kerberos and therefore removes the need to use 
reverse DNS for this. This draft has been implemented in MIT Kerberos 
1.6. The feature is enabled by default and if you want to use it you 
probably want to set "rdns = false" in [libdefaults] to disable 
canonicalisation based on reverse DNS.

Disabling these reverse DNS lookups however is not possible at the 
moment with the OpenLDAP client as explained above. I did a quick patch 
to have ldap_int_sasl_bind() use a value based on the LDAP option 
LDAP_OPT_HOST_NAME and that worked as expected.

Would you guys be interested in a patch that allows the disabling 
hostname canonicalisation based on reverse DNS? The patch would need to 
make this behaviour optional and non-default as some real workloads may 
break and also it would somehow need to handle LDAP URIs with multiple 
hosts.

Regards,
Geert Jansen