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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
