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