At Fri, 6 May 2016 14:59:12 -0400, Ted Lemon <mel...@fugue.com> wrote:
> > While a reverse mapping is generally useful for informational > > purposes, some people use it even more aggressively, such as for > > access control or host validation based on the existence of a > > reverse mapping, and often also on matching between the reverse and > > forward mapping. It is believed that those practices are not very > > effective at best, especially for their side effect of punishing > > otherwise-legitimate users and their service providers. Although an > > ideal solution to this is to encourage stopping those harmful > > practices possibly with replacing them with more effective ones, > > the sad operational reality is that it's less likely that the > > operators employing those practices will listen anytime soon. Until > > then, the victim end users and their service providers will pay the > > cost of the practices, and the only realistic intermediate remedy is > > to provide required reverse mappings and often ensure the > > revers-forward match. This document shows possible options on how > > to do this for those latter types of operators. > > The problem with this text when it was proposed before (it was proposed > before!) is that not everybody agrees on it either. So last time we had > this discussion (which we have had more than once already, not counting > this time), we decided to just be neutral, rather than either saying "this > is a bad idea" or "this is a great idea." I think the document is still > useful, because honestly I do not think it is going to make much difference > as far as host name checking goes. I think if we want host name checking > to die, we should talk to authors of open source software that support this > feature into taking it out. I think, for example, that openssh does this. > Maybe we should talk to them. To be clear, I didn't (yet) intend to suggest using the above text in the draft. It was just to see whether we are basically on the same page if we described it without trying to be *too neutral* or whether we are in disagreement on some more fundamental point. Interpreting the above response as it's the former, and hopefully some more share the same view, I'd personally like to propose including some text like this - it could be weakened if some part of it is considered controversial, but I'd at least like to do the harm as a result of being afraid of controversial and being too neutral (and therefore ambiguous). Of course, this is just one personal feedback. As you said it may be that we can't simply agree on any kind of this text. It's ultimately up to the wg to decide. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
