At its base, Kerberos isn't an overly complicated protocol. I have also already successfully configured a server to accept Kerberos authentications via SPNEGO HTTP headers. I'm new in this area though, so maybe I have just overlooked something…
The confusing part of Kerberos and their implementations is the optional reverse DNS lookup of server's hostname made by clients before they send the resulting SPN to KDC in order to obtain a ticket for the server / application identified by that SPN. As a result, clients may either use the originally requested hostname (this may be an alias – CNAME), OR the reverse-looked up name of the IP-address-owning server in the resulting SPN. This complicates Kerberos setups greatly.
The Kerberos specification (RFC 4120) seems to prefer avoiding the reverse lookup (also referred to as "canonicalization"):
1.3. Choosing a Principal with Which to Communicate
…
Implementation note: Many current implementations do some degree of
canonicalization of the provided service name, often using DNS even
though it creates security problems. However, there is no
consistency among implementations as to whether the service name is
case folded to lowercase or whether reverse resolution is used. To
maximize interoperability and security, applications SHOULD provide
security mechanisms with names that result from folding the user-
entered name to lowercase without performing any other modifications
or canonicalization.
For example, the widespread MIT Kerberos implementation gives an option to disable the reverse lookup and there are even several scenarios suggesting when the reverse lookup should be disabled, in their documentation. On the other side, in Windows the reverse lookup seems to be pretty much hard-coded (see a related question Globally disable reverse DNS lookup for Kerberos on Windows?).
The problem is that the reverse lookups not only break the usage of server aliases (CNAMES), but their optional-ity can cause really unexpected and unstable behavior when different programs on the same machine decide to handle it differently. Like for example when Fiddler makes Kerberos authentication work. And from my tests, the current Firefox, unlike Chrome or IE, even rejects to send Keberos token to a server if requested hostname and hostname looked up by a used Kerberos client library don't match.
So here comes the question: Why is there this mostly problematic default behavior of Kerberos clients? Is there any real benefit nowadays from doing the reverse lookups, other than to maybe get FQDN of a server when FQDN isn't supplied, or to be "backwards-compatible"? Isn't the identity of the called server somewhat confirmed by the widespread usage of SSL anyway?
A bonus question: No new standard coping with this Kerberos "quirk" on the way?
Best Answer
I've always assumed it's to break CNAMES.