Kerberos transport DNS record design

[Petr Spacek]

On 25.5.2016 23:48, Greg Hudson wrote:
> Currently we can map from a Kerberos realm name to the TCP and/or UDP
> addresses of a KDC, kpasswd, or kadmind server.  Several of us have been
> discussing how to best extend that mechanism to include MS-KKDCP, and at
> the same time minimize the number of DNS lookups required to contact a
> realm without configuration.
> 
> We had been planning to use the URI record type, but after a recent
> round of discussion, we don't think it's likely that popular DNS hosting
> providers will allow customers to create URI records (since it seems
> like no one else is using them).  Some middle-boxes would also block DNS
> queries for URI records.  That problem would be even worse if we create
> a new record type.  So, we are planning to use the TXT record type.  It
> seems unlikely that we can standardize on a TXT record through the IETF
> (except perhaps as an informational RFC), but it seems like the only
> deployable option for individuals and small organizations.
> 
> If we use the TXT record type, we have to define the payload format,
> which is the primary subject of this thread.  The payload must
> communicate:
> 
> * Priority, because DNS records are unordered
> * Transport type--currently one of TCP, UDP, and MS-KKDCP
> * For the TCP and UDP types, the hostname and optional port
> * For the MS-KKDCP type, the proxy URL
> 
> The format must be extensible to future transport types, including
> ones that use TCP, UDP, or HTTP in different ways.  Examples could
> include Heimdal's HTTP proxy protocol or RFC 6251 (Kerberos over TLS).
> 
> That leaves a lot of questions:
> 
> * Do we want to include weights as well as priorities?  I think weights
>   are unnecessary complexity, even just as an optional field in the
>   format, but I seem to be in the minority.
> 
> * 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?
> 
> * Do we want to make our payload isomorphic to the URI payload, in
>   anticipation of migrating to the URI record type in the future?  I
>   would argue that such a migration is vanishingly unlikely.  If we go
>   this way, the payload contains a priority, a weight, and a URI, so we
>   have to encode everything but the priority inside a URI, opening a
>   bunch of other inter-related questions:
> 
>   - Should we register a new URI scheme to represent TCP and UDP
>     transports, or use the unregistered tcp: and udp: schemes as some
>     other applications have done?
> 
>   - Should we use a new URI scheme (probably the same one as above) for
>     MS-KKDCP, or should we just use the https: URI of the proxy?
> 
>   - If we do create new URI schemes, should we use use separate schemes
>     for krb5/kpasswd/kadmin, or use the same scheme since we already
>     know the application protocol going in?
> 
>   - Should we use fragment identifiers (#suffix) to indicate master-ness
>     and/or the transport type, or should we use a prefix?
> 
>   If we don't restrict ourselves to an isomorphic-to-URI payload format,
>   we still have to decide whether and how to represent master KDC
>   entries, but the other concerns largely go away.
> 
> * At the bikeshed level, what should we use as a separator between
>   fields?  Is it more convenient for DNS administrators if we avoid
>   using whitespace as a separator?

For the record, opinions of DNS gurus from dnsop list can be found in dnsop
archives:
http://www.ietf.org/mail-archive/web/dnsop/current/msg17526.html

Message
http://www.ietf.org/mail-archive/web/dnsop/current/msg17527.html
indicates that it might be possible to standardize this if you try it.

Message
http://www.ietf.org/mail-archive/web/dnsop/current/msg17534.html
argues that URI is good enough and that TXT is a bad practice.


Pick an answer which suits you the best :-)

-- 
Petr Spacek  @  Red Hat