On 5/9/16, 2:15 PM, "DNSOP on behalf of 神明達哉" <[email protected] on behalf
of [email protected]> wrote:
>At Fri, 6 May 2016 14:59:12 -0400,
>Ted Lemon <[email protected]> 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.
I think we tried this in 2006-2008 with reverse-mapping-considerations, and in
2009 with early versions of this draft, and occasionally in the following
years. I think the existing document balances the considerations and
represents, if not everyone's opinion, the best consensus that currently exists.
Lee
>
>--
>JINMEI, Tatuya
>
>_______________________________________________
>DNSOP mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/dnsop
________________________________
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.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
