krb5_sname_to_principal or LDAP/SASL/GSSAPI and reverse DNS

[Paul W. Nelson]

I know there was a discussion about SASL and reverse DNS lookups about a
year ago.  I have a problem where a user has no reverse lookup for one
Microsoft domain controller.  Other domain controllers for the same domain
get a different FQDN than their principal name - for example:
    srv1.ad.usauniversity.edu  - reverse lookup fails
    srv2.ad.usauniversity.edu  - reverse lookup returns both srv2.ad.
usauniversity.edu and srv2.usauniversity.edu (in that order).
srv3 and srv4 are also domain controllers and reverse lookups for these work
just like srv2.

In this scenario, I'm an LDAP client.  My LDAP/SASL/GSSAPI combination does
two reverse lookups when a connection is made.  One is done in the LDAP
library, and the other is done in krb5_sname_to_principal.  Details of the
LDAP code are included below.

My question is more of a SASL/GSSAPI question.  When sasl_client_new is
called, a call is eventually made to krb5_sname_to_principal (via
gss_import_name).  Should krb5_sname_to_principal only be called by
applications when they are not sure if the server name matches the principal
name?  

Since krb5_mk_req calls krb5_sname_to_principal, is the call unavoidable?

Is this code known to be broken?  For example, getnameinfo only returns ONE
name (and in my case the one I DON¹T want).  Does anyone know if this is a
problem with Kerberos or is this person's DNS service just incorrect?

The other problem has to do with LDAP and SASL, and is not related to
Kerberos per se.  The current ldap code from OpenLDAP does a similar thing
using ldap_host_connected_to.  This function uses the peer address (in this
case that's the server) and passes it to getnameinfo (in function
ldap_pvt_get_hname).  It does not require an address, so in my case, it
returns the dotted decimal host number.  This string (dotted decimal) is
then passed to sasl_client_new.  (In an older version of LDAP that uses
gethostbyaddr, no string is returned and LDAP will not connect, returning a
LOCAL error 0x82). 

The user is a relatively well known university in the USA.  They claim their
DNS is configured correctly and are not about to make any changes to it.

-- 
Paul W. Nelson
Thursby Software Systems, Inc.