This is nearly a straight rehash of the ill-fated in-addr draft. As
with that draft, there is a fundamental wrong assumption embedded in the
draft, as exemplified in this sentence of Section 4.1:
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. Those who think there is some "universally correct"
answer have no legitimate foundation for that belief. They are really
just trying to impose their _site's_ practices on everyone else in the
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
be achieved even if everyone were to adopt their practices. [ignoring
the fact that some sites cannot adopt those practices and have very good
reasons for their different practices.]
This draft merely uses different words to express the same wrong ideas
and assertions as did the previous in-addr draft. The same objections
that applied to the previous in-addr draft apply to this draft.
Is the working group seriously considering this draft? I must have
missed it on the agenda. (though I note the archive only goes back
to 11/30/06) I've been busy, recently.
--Dean
On Wed, 3 Jan 2007 [EMAIL PROTECTED] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations Working Group
> of the IETF.
>
> Title : Considerations for the use of DNS Reverse Mapping
> Author(s) : D. Senie, A. Sullivan
> Filename : draft-ietf-dnsop-reverse-mapping-considerations-01.txt
> Pages : 10
> Date : 2007-1-3
>
> Mapping of addresses to names is a feature of DNS. Many sites
> implement it, many others do not. Some applications attempt to use
> it as a part of a security strategy. The goal of this document is to
> outline what should be taken into account when deciding whether to
> implement reverse mappings of addresses to names.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reverse-mapping-considerations-01.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [EMAIL PROTECTED] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-ietf-dnsop-reverse-mapping-considerations-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [EMAIL PROTECTED]
> In the body type:
> "FILE
> /internet-drafts/draft-ietf-dnsop-reverse-mapping-considerations-01.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
