Internet-Drafts | 3 Jan 21:50 2007
Picon

I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-01.txt

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 
i-d-announce-request <at> ietf.org 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".

(Continue reading)

Andrew Sullivan | 3 Jan 22:26 2007

Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-01.txt

Dear colleagues,

On Wed, Jan 03, 2007 at 03:50:01PM -0500, Internet-Drafts <at> ietf.org wrote:

> 	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

This version of the draft is our attempt to address all the comments
we received on the list and in San Diego about the -00 draft.  The
text that I originally proposed on the list for issue 10 has been
mostly replaced by that which emerged from Ed Lewis's discussion of
the issue.  I hope it is better this way.

Any comments are, as always, welcome.  Thanks very much.

A

--

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew <at> ca.afilias.info>                              M2P 2A8
jabber: ajsaf <at> jabber.org                 +1 416 646 3304 x4110

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
(Continue reading)

Dean Anderson | 4 Jan 19:15 2007

Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-01.txt

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
(Continue reading)

Dean Anderson | 4 Jan 19:23 2007

Email List Archives broken?

I noticed this with some other IETF archives:

The dnsop archive pages only go back to November 30, 2006. This is true
for some other IETF working groups. (e.g. GROW)

I notice that the IETF Trust creation document gives CNRI special access
to the ISOC/IETF archives.

Is it the case that the IETF intends to deny access to the email list
archives to members? [I would have a problem with that] If not, when
will the list archives be fixed and available again?  [I asked this 
offlist before the holidays, and did not get a response]

		--Dean

--

-- 
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 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop

Joe Abley | 4 Jan 20:01 2007

Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-01.txt


On 4-Jan-2007, at 13:15, Dean Anderson wrote:

>    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".

I'm not sure I understand why you think this is a problem.

> The correct answer to "what is supposed to be seen" is
> _site_ dependent.

Assuming you mean the site responsible for the address concerned,  
then surely this presents no great problem.

If you mean that every other site on the Internet ought to be able to  
assert its own policy on the name associated with a remote address,  
then that seems like an unusual perspective.

Perhaps you could clarify.

> 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.

You might like to review the minutes of the meeting in Montreal.

(Continue reading)

Joe Abley | 4 Jan 20:04 2007

Re: Email List Archives broken?


On 4-Jan-2007, at 13:23, Dean Anderson wrote:

> I noticed this with some other IETF archives:
>
> The dnsop archive pages only go back to November 30, 2006. This is  
> true
> for some other IETF working groups. (e.g. GROW)

Those are both lists which were recently moved from machines at the  
University of Oregon. It would probably be more constructive to  
address your request for the inclusion of historical archives to the  
current operators of the lists, not the working groups.

Joe

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop

Andrew Sullivan | 4 Jan 20:24 2007

Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-01.txt

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
(Continue reading)

Edward Lewis | 4 Jan 20:27 2007

Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-01.txt

At 13:15 -0500 1/4/07, Dean Anderson wrote:

>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.]

I can speak to the motivation of this because I think I was the one 
that suggested the words.

The motivation had nothing to do with security.  Your point is well 
taken and I agree that there is little value in the reverse map in 
providing security.  (Arguably, some value, not enough to justify the 
expense certainly.)  But the vagueness ot the text is borne from 
other observed uses of DNS, for example Akamization and what some 
call "directional DNS".  There are folks that purposefully answer 
differently based on where a query comes from.  It can be argued that 
these folks are violating coherency and they can retort that no, they 
are abusing dynamic update (with a wink).  Whatever, it happens, and 
we need to recognize reality and not try to argue theory.

The other scenario I had in mind was split-DNS, in which I answer 
with more detail to my own machines than the Internet. Such as -
(Continue reading)

Peter Koch | 5 Jan 17:35 2007
Picon

Re: Email List Archives broken?

On Thu, Jan 04, 2007 at 02:04:31PM -0500, Joe Abley wrote:

> >The dnsop archive pages only go back to November 30, 2006. This is  
> >true
> >for some other IETF working groups. (e.g. GROW)
> 
> Those are both lists which were recently moved from machines at the  
> University of Oregon. It would probably be more constructive to  

the pre-NOV-30 archives are temporarily unavailable. The files have been
deleted from their previous location and will be made available together
with the more recent data soon. Apologies for the inconvenience.

-Peter

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop

Dean Anderson | 5 Jan 20:42 2007

Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-01.txt

On Thu, 4 Jan 2007, Joe Abley wrote:

> 
> On 4-Jan-2007, at 13:15, Dean Anderson wrote:
> 
> >    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".
> 
> I'm not sure I understand why you think this is a problem.

I suggest you review the (or your personal) archives of the in-addr
discussion.  This was all discussed.  I think you participated, if
memory serves.

> > The correct answer to "what is supposed to be seen" is
> > _site_ dependent.
> 
> Assuming you mean the site responsible for the address concerned,  
> then surely this presents no great problem.

That is exactly the problem.  To refresh and review:

The debate is over "the right answer" given for reverse DNS queries.  
The position of the "security/spam" crowd is that no reverse anwser is
wrong, and that if forward doesn't match reverse, that is also wrong.
They assert that matching forward/reverse imply security and
(Continue reading)


Gmane