Kerberos transport DNS record design

Greg Hudson ghudson at mit.edu
Wed May 25 17:48:07 EDT 2016


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?


More information about the krbdev mailing list