Canonicalization pains ...

[Steven Ross Brudenell]

Searching the archives of this list has revealed that the issue of
server name canonicalization has often been brought up, but I have many
questions unanswered.

Specifically: what exactly is the advantage, in terms of either security
or efficiency, of necessitating the use of canonical names over aliases?

I cannot find answers to this question in the documentation, and only
unclear references to advantages among the developers. It seems that the
ability to refer to aliased names would simply facilitate
reconfiguration (i.e., have clients connect to a GSSAPI-authenticated
LDAP server ldap.brudenell.name, which may be an alias for anything at
all). It also seems that the argument that relying on insecure (or
incorrect, or "creatively administered") DNS for the integrity of the
system is not a good idea. If not for reasons of security, then surely
for reasons of having authentication at all _work_ in the face of
reverse DNS being broken -- this is a link in the functionality chain
which is broken all too often.

In particular, I am trying to run a KDC (and other servers) from behind
a NAT firewall on a dynamic-IP cable connection. This may seem silly,
but so is using Linux. I have, of course, no control over whether my
KDC's canonical name (w.r.t. the outside world, of course -- my internal
network can be configured in any way at all) changes, even assuming the
IP stays the same. It seems that the current philosophy has no answer
for my configuration other than to create different service principal
for every service running on every host, every time the IP changes,
which is clearly unacceptable. Assuming there is a very good reason for
host canonicalization to stay, does anyone have any advice for making my
configuration work?

I would wager that changing service principal lookup mechanisms in the
already widely-deployed kerberos is hard and would upset people. Is
there any chance, therefore, of making this a feature I can turn off,
and forsake the security?

Thanks in advance ...

~Steve