Kerberos transport DNS record design

[Roland C. Dowdeswell]

On Thu, May 26, 2016 at 05:25:19PM +0000, Brandon Allbery wrote:
>

> - For either one, using LDAP backend with its replication facilities
> makes fallback unnecessary.

Does the LDAP backend promise that all of the slaves are up to date
before kadm5_create_principal() returns successfully?  If not,
there will still be a race condition.  We are currently starting
to see our developers deploy new services using VMs and containers
in an on-demand fashion on a large scale expecting to be able to
hit those services the moment the master KDC reports that the
principal has been created.

I also quite like the master failover because it provides additional
resiliency against things like: a slave's clock going out of skew;
an administrator truncating the Kerberos DB on a slave; a slave
running out of disk space and somehow rubbishing the KDB causing
the KDC to respond inappropriately; or an administrator of DNS
(often people in a different group in the organisation) messing up
the one of the SRV RRs to point at a different realm's KDC.  I
suppose that I don't think that it makes sense for the client to
simply give up at the first sign of errors when there is a decent
chance that one of the other KDCs may very well have a better
answer.  Remember that in many environments, almost all requests
to the KDCs should succeed, after all: if I'm making a TGS_REQ for
a service then in general I've connected to the service in question
and it has asked me to use GSSAPI/Kerberos authentication (at least
in the case of protocols like HTTP/Negotiate, SSH, SASL where GSSAPI
auth is negotiated.)

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/