Kerberos transport DNS record design

Petr Spacek pspacek at
Wed Jun 1 06:34:37 EDT 2016

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

indicates that it might be possible to standardize this if you try it.

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

More information about the krbdev mailing list