The reason for this is an authentication issue you might experience when using Kerberos and SharePoint. And since SharePoint 2013, were NTLM is deprecated, this issue might hit you when planning an update of your farm. More details can be found in the following Technet article:
Kerberos configuration known issues (SharePoint Server 2010)
Of particular interest in this article is the following passage:
Kerberos authentication and DNS CNAMEs
There is a known issue with some Kerberos clients (Internet Explorer 7 and 8 included) that attempt to authenticate with Kerberos enabled services that are configured to resolve using DNS CNAMEs instead of A Records. The root of the problem is the client does not correctly form the SPN in the TGS request by creating it using the host name (A Record) instead of the alias name (CNAME).
Example:
A Record: wfe01.contoso.com
CNAME: intranet.contoso.com (aliases wfe01.contoso.com)
If the client attempts to authenticate with http://intranet.contoso.com, the client does not correctly form the SPN and requests a Kerberos ticket for http/wfe01.contoso.com instead of http/intranet.contoso.com
Details regarding the issue can be found in the following articles:
http://support.microsoft.com/kb/911149/en-us
http://support.microsoft.com/kb/938305/en-us
To work around this issue, configure Kerberos enabled services using DNS A records instead of CNAME aliases. The hotfix mentioned in KB article will correct this issue for Internet Explorer but will not correct the issue for the .NET framework (which is used by Microsoft Office SharePoint Server for web service communication).
