Ticket History #8037: Documentation__Principal names and DNS

I presented today at the DNSOP WG about reverse DNS, and how it's used.
The context is that in IPv6, it is hard for ISPs to populate PTRs. So, is
it worth the effort? see draft-howard-isp-ip6rdns

Someone said, "SSH using PTRs for security is stupid" and there was
thunderous applause. I'm following up on the DNSOP mailing list to
confirm, but there seems to be consensus that the default behavior of
rejecting an SSH connection because a PTR record is missing is stupid.

So, what would it take to change the default behavior from rdns = true to
rdns = false?

Thanks,
Lee


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

This conversation would be better situated on the krbdev@mit.edu
list, but I will answer here.

We absolutely think the rdns=true behavior is dumb and recommend
turning it off. But we also try very hard to make upgrades as
painless as we can--especially on the client side, where they often
happen as part of OS upgrades without anyone explicitly consenting
and reading the release notes. When we have floated the idea of
changing the default, we got feedback that it would definitely affect
some environments in a negative way:

http://mailman.mit.edu/pipermail/kerberos/2011-July/017313.html

The concern isn't so much that those particular environments would be
adversely affected; anyone who is sufficiently informed could simply
turn it on explicitly. But we would undoubtedly surprise people who
run similar environments and aren't on the kerberos@mit.edu list.

We have a rough design, but not a timeline, for getting rid of both
forward and reverse canonicalization at the KDC's option:

http://mailman.mit.edu/pipermail/kerberos/2011-July/017313.html