>>>>> On Tue, 6 Feb 2007 09:43:18 -0500,
>>>>> Andrew Sullivan <[EMAIL PROTECTED]> said:
> I believe that the draft as it stands is consistent with the second
> view, and that it expresses a view that is contrary to the first
> view. In other words, the draft as written says, I think, that
> administrator of site A is perfectly entitled to make decisions about
> site B on the basis of reverse mappings, _but_, the administrator of
> site A is cautioned that there are plenty of pitfalls in that
> strategy, and they ought to be taken into consideration.
Okay, that was actually what I thought, while being confused, was the
intent of this document. On top of the understanding that this
document actually supports the second view rather than being neutral,
I have next concern. The problem of this stance is that this document
does not explain (at least not to me) why the following is justified:
> administrator of site A is perfectly entitled to make decisions about
> site B on the basis of reverse mappings,
> but that, on balance, unless
> you have pretty good reasons not to maintain it, you should maintain a
> reverse mapping.
Perhaps the intent is to explain it in Section 3.3, but they are
basically just "there are applications that make decisions about site
X on the basis of reverse mappings". In particular, it does not
answer the question of how the behavior of such applications is valid.
On the other hand, Section 4.2 (seems to) indicate such usage is
not really valid:
Operators and users are reminded that the use
of the reverse tree, sometimes in conjunction with a lookup of the
name resulting from the PTR record, provides no real security, can
lead to erroneous results and generally just increases load on DNS
servers.
It would be okay if this document took a neutral position describing
two controversial views. But since it is going to support, even
mildly, one particular view, it should provide why it's justified in a
convincing way.
Perhaps the following part of the intent was expected to be used as an
excuse:
> _but_, the administrator of
> site A is cautioned that there are plenty of pitfalls in that
> strategy,
but at least to me it's not enough; a "caution" can easily be ignored,
particularly when one is told "it is perfectly entitled to do it".
So...
> I'd like to know whether people think that is a reasonable thing to
> say. If the answer is, "No," then I'm not sure what we can say about
> reverse mappings at all.
sorry, but the answer is "No" to me. And I tend to agree that it'll
be not really sure whether we can say anything (as I indicated my
previous message), but I can still see some options:
1. update the draft with the opposite (first) view. This is basically
what I proposed in my previous message, and I believe it can
explain why one should do this although I admit I'm biased on this
point.
2. keep the current position (i.e, support the second view), but
explain why the recommendation is justified despite the description
against it (which must be more than "because there are such
applications").
BTW: if we keep this view, the abstract and the Introduction should
be clearer on this; currently, these read as if this document
simply talks about issues regarding reverse mappings in a neutral
position. This is actually one of the reasons why I was confused
about the purpose of this document.
3. update the draft without supporting any view, in a neutral
position. In that case, we'll probably simply make "cautions" of
not-providing and relying on reverse mappings equally rather than
making specific recommendations. As you indicated above, this
approach may weaken the value of this document, but since this
seems to be a subtle, controversial issue, I think it's the most
balanced compromise.
Not sure how many of others agree with me, but I'm happy to volunteer
to provide suggested text for option 1 or 3.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
