[36540] in Kerberos
No mention of _kerberos TXT in RFCs / but we have DNSSEC now
daemon@ATHENA.MIT.EDU (Rick van Rein)
Mon Oct 13 07:58:11 2014
From: Rick van Rein <rick@openfortress.nl>
Date: Mon, 13 Oct 2014 13:57:08 +0200
To: "<kerberos@mit.edu>" <Kerberos@mit.edu>
Message-Id: <0D161257-4C35-4390-ADCE-7C1385DDE679@openfortress.nl>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset="windows-1252"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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
