krb5 uses reverse DNS records for creating service principals from host names. This is non-standard behavior. Apparently most other clients do not do this, and the RFC 4120 does not specify this behavior. Being the only client that uses PTR records for this purposes causes problems, as unfortunately realms often have missing or incorrect information present in PTR records. We should change the builtin default behavior to match other clients. Upstream is considering such a change: http://mailman.mit.edu/pipermail/kerberos/2011-July/017313.html Because this represents a change in defaults, we should make this happen in RHEL 7 (rather than a point release) and Fedora 19. The previous behavior would still be available by changing the krb5.conf. This is related to: https://fedoraproject.org/wiki/Features/LessBrittleKerberos
Changing the setting in /etc/krb5.conf in krb5-1.11-2.fc19. The hardwired default remains unchanged.
Part of the work in Fedora 18 was to allow use of kerberos wîthout a krb5.conf. Are you sure we want to have our kerberos behavior dictated by always having a krb5.conf present? Or perhaps for Fedora 19 we could change the default in a file, but in RHEL 7 we actually change the hardwired default? What do you think?
Stef, we discussed the default with upstream. The long term plan there is to make most of resolution eventually go through the KDC, so that clients configuration is not so overwhelmingly fragile. In order to maintain backwards compatibility upstream suggest to not change the actual internal default, but only change the default configuration file. This way existing deployments that rely on PTR record resolution and distribute krb5.conf files via things like puppet won't be broken. I would argue preserving the classic behavior in RHEL7 is probably more important than Fedora 19.
The main thing we don't achieve by this is fixing the RDNS problems for users who upgrade their systems. It doesn't seem possible to solve both: * Keep compatibility for existing deployments that rely on PTR records * Unbreaking kerberos for upgraded Fedora installs on invalid or non-existent PTR records But I'm fine with the trade-off upstream has chosen. Perhaps we might revisit this later, once upstream has worked done their KDC work. Thanks for explaining.