Re: Make SASL hostname canonicalization optional (RFC on patch approach)

[Brad Knowles <b.knowles@its.utexas.edu>]

Joel Johnson wrote:

> 1) As an ISP service provider I may have several DNS service names that
> happen to be on the same server, yet I want to maintain separate identities
> to make the services nearly transparent to migrate to dedicated hardware in
> the future if the need arises. Suppose that I have directory.example.com and
> imap.example.com on the same box, whose hostname is lucy.example.com. I
> would have three A records (or one A record and two CNAMES) for the same
> box, but since I can only have one PTR record,

First off, you don't ever want to use CNAME aliases for mail services. 
That's going to seriously screw you up right there.  Have everything 
directly resolve to the same IP address.  That will solve a lot of 
canonicalization problems.

Secondly, there's absolutely nothing in the DNS that says you can't have 
multiple PTR records.  However, application behaviour in the face of 
multiple PTR records is not defined by the standard, and different 
applications will handle this in different ways.  You need to find out 
how your applications handle it.

Thirdly, you could always have the same services on the same server, but 
with multiple IP aliases bound to the same machine.  Each service could 
get a separate IP address, and there would be one and only one PTR 
record for that IP address.  If/when you decide to move that service to 
another machine, just move the IP address and leave everything else alone.

I've worked at both large & smaller scale ISPs and these problems are 
well-known, and their solutions are also well-known.

> 2) On my home network I wish to use OpenLDAP, but my local server is on a
> DSL connection and I have no control over the DNS PTR records, and as such
> the records are effectively meaningless to the operation of my system. I do
> impose the requirement of mandatory TLS (via security ssf=128) which in and
> of itself provides stonger server authentication than name canonicalization
> via reverse DNS.

I've seen a lot of cases where the certificate is more screwed up than 
the reverse DNS.  Scratching this itch might help your one particular 
case where you can guarantee the reverse, but this isn't likely to be of 
much use in the general populace where such a feature would just give 
them more ammo to use in blowing off their feet with their own 
thermo-nuclear shotgun.

> I propose that this would be a very valuable option, especially since there
> are cases where name canonicalization is infeasible if not impossible, as
> well as the fact that combined with TLS stronger server authentication is
> available. To use GSSAPI with SASL, it should also be noted that the more
> recent Kerberos RFCs have specifically required that reverse DNS *not* be
> used [3]. I'm looking for comments on the viability of such a patch being
> included in the base software, as well as comments on the patch itself.

That's a good question.  If it were me, I might accept the patch into 
the tracking system, but it wouldn't be a high priority item to fix. 
But then I'm not one of the core developers.

--
Brad Knowles <b.knowles@its.utexas.edu>
Sr. System Administrator, UT Austin ITS-Unix
COM 24  |  5-9342