Kerberos transport DNS record design

[Nathaniel McCallum]

On Sat, 2016-05-28 at 02:23 -0400, Greg Hudson wrote:
> On 05/26/2016 04:45 PM, Nathaniel McCallum wrote:
> > Would MIT consider it sufficient to do a secondary lookup in
> > this case? A secondary record could have the same format as the
> > primary
> > record. The cost for this is, of course, a secondary lookup.
> > However,
> > this only happens in the failure case.
> 
> We talked about this a bit on IRC.  For archival:
> 
> * Doing a second lookup for master KDCs is somewhat easier to
> implement
> because that's how the code inside locate_kdc.c works for other
> information sources.  However:
> 
> * Currently, we do the master lookup on success as well as failure
> (http://krbdev.mit.edu/rt/Ticket/Display.html?id=7721).  Fixing this
> is
> moderately difficult, requiring changes to the krb5_sendto_kdc() and
> k5_get_init_creds() contracts.  Unless this is fixed, and if we use a
> separate lookup for master KDCs, the TXT record feature adds two new
> DNS
> queries for most KDC lookups instead of just one, in realms where TXT
> records aren't yet deployed.
> 
> * Many realms don't have master KDCs.  Representing the absence of
> master KDCs with an NXDOMAIN response poses some minor issues: it
> would
> trigger a fallback to SRV lookups unless we take steps to avoid that)
> and the TTL for NXDOMAIN caching is global to a DNS zone.  Nico notes
> that we could allow an empty TXT record to represent the absence of
> master KDCs to avoid these issues.
> 
> Including master KDCs in the normal KDC RR set could be done by
> adding
> an alphabetical flags field to the TXT record format, where the 'M'
> flag
> indicates a master KDC entry.  If we do this, we can store an
> is_master
> value in each struct server_entry, and k5_kdc_is_master() can use
> that
> value to avoid doing the master KDC lookup.  We would wind up
> repeating
> the query for the TXT record if we actually do fall back (assuming no
> fix for #7721), but we can hope that record is cached by a local
> resolver.
> 
> > 1. Implement all the record names that MIT already supports as TXT.
> > Using exactly the same semantics that MIT already implements (i.e.
> > ignoring the weight parameter).
> 
> I don't think we need to implement or document krb524 lookups; that's
> a
> vestige.  We should be able remove those references from locate_kdc.c
> and add a comment in locate_plugin.h that locate_service_krb524 will
> never be queried in recent versions.
> 
> > 2. Make the format of the TXT record:
> > 
> >     priority:weight:udp:host[:port]
> >     priority:weight:tcp:host[:port]
> >     priority:weight:tls:host[:port]
> >     priority:weight:kkdcp:http://host[:port][/path]
> >     priority:weight:kkdcp:https://host[:port][/path]
> > 
> > This is isomorphic with the URI record with the exception of a
> > missing
> > scheme, which could be added later should the desire to use URI
> > emerge.
> > 
> > It also avoids the problem of defining a URI scheme now. I think we
> > can
> > get away with this by noting that this format isn't technically a
> > URI
> > even though it closely resembles one.
> 
> +1 except that I currently favor adding a flags field to indicate
> master
> KDC records.

We discussed this on the MIT developer call today and came to a
consensus. The plan looks like this:

1. Implement the following record names as TXT using exactly the same
semantics that MIT already implements (i.e. ignoring the weight
parameter):

    _kerberos-adm.REALM
    _kerberos.REALM
    _kpasswd.REALM

2. The following record names will not be implemented:

    _kerberos-master.REALM
    _krb524.REALM

3. The format of the TXT record is:

    priority:weight:flags:udp:host[:port]
    priority:weight:flags:tcp:host[:port]
    priority:weight:flags:tls:host[:port]
    priority:weight:flags:kkdcp:http://host[:port][/path]
    priority:weight:flags:kkdcp:https://host[:port][/path]

4. The flags field contains zero or more flag characters. Currently,
there is only one flag: M. The M flag indicates that this record refers
to a master KDC.

If you have any objections, please voice them now.