On Wed, 2011-07-06 at 16:02 -0400, Jeffrey Altman wrote: > On 7/6/2011 2:22 PM, Simo Sorce wrote: > > I would resolve all these issues by using aliases at the KDC level, but > > thank you for explaining, it's valuable data on the way KDC/DNS are used > > to keep track off. > > The primary thing that the Kerberos development team needs to keep in > mind every time a change is made is that Kerberos deployments are > distributed and federated. In many of the environments there are many > realms involved which are managed by different organizations. Upgrading > clients and KDCs cannot be performed in lock step and there is no > ability to coordinate which comes first the KDC / KDB update or the > client deployments. > > Any transition plan to alter canonical name resolution processing must > take that into account. It must be possible for a client machine to be > updated in one organization or on one individual's machine and have it > continue to work when the KDC/KDB for the realm that client communicates > with is not updated to support KDC side aliasing. > > Just my two cents ...
Jeffrey, as far as I understand the proposal it to simply change the default, I have seen no request to remove the rdns parameter, so if you need reverse resolution at most you'll have to change rdns = true in krb5.conf on clients. It may be annoying to have to do that in a haste if you don't know in advance and merrily upgrade to 1.10, that's why Greg asked on the list before changing the default. Simo. -- Simo Sorce * Red Hat, Inc * New York ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos