Kerberos transport DNS record design

[Nathaniel McCallum]

On Thu, 2016-05-26 at 11:12 -0400, Greg Hudson wrote:
> On 05/26/2016 10:39 AM, Nathaniel McCallum wrote:
> > > * Do we want to include master KDCs in the same query as normal
> > > KDCs,
> > > or
> > >   should they be in a separate record?  (Master KDCs are used as
> > > a
> > >   fallback by the MIT client code when we receive a KDC error
> > > which
> > >   could have resulted from out-of-date data due to propagation
> > > delays.)
> > > 
> > >   - If we do communicate master KDCs in the same record, should
> > > it be
> > >     possible to exclude a master KDC from the normal server list
> > > (so
> > >     that it is only contacted if a normal KDC returns an error),
> > > or
> > > is
> > >     it sufficient to be able to assign master KDCs a low
> > > priority?
> > 
> > If the only reason to specify a master KDC is as a last-ditch
> > fallback,
> > then priority should be sufficient.
> 
> Priority only affects the order in which KDCs are contacted when
> higher-priority KDCs fail to answer at all.  Master KDCs are used as
> a
> fallback if a non-master KDC returns an error like "preauth failed"
> which could result from stale KDC data.
> 
> So, priority might be a sufficient alternative to "master only," but
> it
> cannot handle the problem entirely.  If we do not include an
> indication
> of master KDCs in the TXT record payload, we will have to make a
> second
> query of another record to find them.  (In theory this query is only
> necessary on failure, but currently the code does it whenever it gets
> a
> KDC response.)

How likely is this failure from non-master KDCs due to synchronization
issues? Is this a real historical problem? Does this problem persist
today?

Does anyone else implement this logic?