No mention of _kerberos TXT in RFCs / but we have DNSSEC now
Jeffrey Altman
jaltman at secure-endpoints.com
Fri Oct 17 18:15:28 EDT 2014
On 10/17/2014 2:24 AM, Rick van Rein wrote:
> Thanks Ken & Benjamin,
>
> Your combined response indicates that there is no clear reason that TXT
> records ought to stay out, and indeed, that the recent introduction of
> DNSSEC into the landscape means it could have some re-evaluation.
>
> That’s pretty much what I wanted to know. No need to dig up detail-ridden
> discussions from the past! Had it been public, then I think I would have
> found it already anyway.
>
> Cheers,
> -Rick
Rick,
Speaking as the other author of draft-ietf-krb-wg-krb-dns-locate-03, I
have no objection to revisiting the discussion of using TXT records
Kerberos in order to further reduce the need for client side
configuration. However, I would be unhappy if the implemented
"_kerberos.<fqdn>" entry be standardized as-is.
In 2001 there wasn't much experience using TXT records and the choice of
"_kerberos.<fqdn>" was somewhat controversial in the DNS community. In
2014, the current DNS best practice for use of TXT records is that the
TXT record be applied to the <fqdn> directly where the TXT record has a
format of
"v=<protocol><version>; [tag=value;]+"
For Kerberos an initial version describing only the REALM might be:
"v=krb1; r=REALM;"
which would permit use to distribute other mandatory configuration in
the future. However, I could imagine other information being provided
such as pre-auth hints; and public key information for the realm.
This discussion would be best held on the IETF Kitten mailing list.
Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4529 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20141017/919e66ec/attachment.bin
More information about the Kerberos
mailing list