Hi Dean,

On Thu, Jan 04, 2007 at 01:15:56PM -0500, Dean Anderson wrote:
> This is nearly a straight rehash of the ill-fated in-addr draft.   

Since as a matter of history it's a revival of that draft under a
different filename (as some people objected to the "required"), that
shouldn't be too surprising.

>    In general, the DNS response to a reverse map query for an address
>    ought to reflect what is supposed to be seen at the address by the
>    machine initiating the query.
> 
> There is no exact definition of "what is supposed to be seen at the
> address by the machine initiating the query".  This incorrect assertion
> is at the very heart of the mistaken uses of 'reverse DNS as security
> mechanism'.  The correct answer to "what is supposed to be seen" is
> _site_ dependent.  

The point of the "supposed to" and "by the machine initiating the query"
language is precisely to capture that site dependency that you,
quite correctly, point out.  If you have another way to state that, a
patch to the text is welcome.  If you think it's unclear, please
suggest the language that will make that intention clearer.  

> Those who think there is some "universally correct" answer have no
> legitimate foundation for that belief.

Of course there is no universally correct answer; see above.  What I
claim is true, though, is this: since DNS is deterministic, there is
a right answer to every _particular_ query, when the particulars of
the query include its origin. 

> belief that if everyone else did what they did, they could use reverse
> DNS for security or anti-spam or some such.  The ends, however, cannot

I think the draft says that you should not rely on reverse DNS for
security, and that more importantly, if you decide to, you'd better
be aware of the consequences.  If that isn't clear, please tell me
where I can make it clearer.

> the fact that some sites cannot adopt those practices and have very good
> reasons for their different practices.]

And I think the draft _also_ says that there may indeed be some cases
where those different practices are in fact a good idea.  We've
included some.  If you have some more examples, please send them
along so that we can include them.  Text is welcome and encouraged. 
The point of this draft is not to say, "Thou shalt provide reverse
mapping."  It _is_ to say that, on balance, the reverse tree is
potentially useful, and that therefore site administrators should
think very hard before they neglect its maintenance.  Similarly, it
is trying to say that, since some sites might make that determination
for good reasons, and that since other sites might just be careless,
one should think pretty hard about using the reverse tree as any sort
of guarantor of anything.

> missed it on the agenda. (though I note the archive only goes back 
> to 11/30/06)  I've been busy, recently.

I did discuss this at the San Diego meeting, and I note the
discussion made it into the jabber notes and the minutes.  I also have
put all the issues into the tracker, so you could have a look at
them there if you'd like.  

Best regards,
A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[EMAIL PROTECTED]>                              M2P 2A8
jabber: [EMAIL PROTECTED]                 +1 416 646 3304 x4110

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop

Reply via email to