No mention of _kerberos TXT in RFCs / but we have DNSSEC now

[Rick van Rein]

Hello,

Most of us know about the practice of the _kerberos TXT records in DNS; this can help to translate a servername to a REALM name, which is especially helpful if we want to crossover to other realms.  This is coded into MIT krb5, and I bet many of our domains implement it.

A grep on my RFC collection showed no RFC that defines the TXT discipline; even RFC 4120 does not, even though
https://datatracker.ietf.org/doc/draft-ietf-krb-wg-krb-dns-locate/history/
says it has “incorporated into RFC 4120” the draft that introduced the TXT records.

The TXT records were always considered unreliable, but we’ve seen DNSSEC become a reality these days, so it might be up for another chance.  If I’m not mistaken?


I’m finishing a TLS-with-krb5-and-DH proposal which relies on this record.  Without it, there is no chance of knowing how to crossover  to other realms (the mechanics of that being unsettled).  I may now have to introduce these TXT records in that specification.


Concerning *how* to use these records… I would prefer to not search as exhaustively as the draft proposes, but rather:
 - first try at _kerberos.${SERVERNAME} TXT
 - ignore unsigned responses
 - is it absent (with signed NSEC or NSEC3)?  then pickup the zone apex from the SOA
 - lookup _kerberos.${ZONEAPEX} TXT
 - ignore unsigned responses
 - permit multiple TXT records, each suggesting a realm name (or permit them combined in one TXT record)

This has a few advantages:
 - Never look for _kerberos in parent domains, notably TLDs
 - Parent zones cannot dictate child zones’ realm name
 - There is an option of declaring one (or more) realm names so the client can search for a path
 - Less resolving means faster responses (DNSSEC takes time!)

It has only one disadvantage:
 - less fine control over assigning realms to servers

Moreover, it is probably in line with what we’re all doing now anyway.


Does this make sense?


Cheers,
 -Rick