Subject: [DNSOP] I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-04.txt

From: [email-masked]
Date: Tue, 03 Jul 2007 10:15:01 -0400

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-04.txt
	Pages		: 14
	Date		: 2007-7-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.  This document outlines what
   should be taken into account when deciding whether to implement
   reverse mappings of addresses to names, suggests that site
   administrators implement reverse mappings if there are no strong
   considerations against such mappings, and provides considerations to
   be taken into account when using reverse mappings.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reverse-mapping-considerations-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-04.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-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsop-reverse-mapping-considerations-04.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.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 4 Jul 2007 13:30:27 -0400

Dear colleagues,

> 	Filename	: draft-ietf-dnsop-reverse-mapping-considerations-04.txt

The draft mentioned above reflects the contemplated changes that I
sent to the list in the time since the -03 draft.  It is mostly
unchanged from the -03 submission, but it _does_ include the
contemplated reference to RFC 1912, as well as an explicit remark
(occasioned by Mark Andrews's and Dean Anderson's comments) that
overzealous interpretation of RFC 1912 can have deleterious effects
(this latter at the end of section 4.4).  I take that to be a (small)
substantive change in the document that diverges from the outlined
list of planned changes, so I am drawing attention to it.

I will note also that we did _not_ include an exhortation to
implement DNSSEC in the Security Considerations section.  We did not
receive much in the way of feedback on the suggestion one way or the
other.  Because such an exhortation seems to be merely a request that
everyone implement something already elsewhere defined, we thought it
might set a bad precedent.  The document already includes references
to the RFCs in question, so operators can presumably draw their own
conclusions.

As always, comments are solicited.  It is our fervent hope that we
have either adequately addressed the comments we have received in
this draft, or explained on the list why we did not discuss those
issues.  Your editors shall enthusiastically receive and attempt to
address specific comments that reference the current text, or that
explicitly refers to discussion on the list to which we have never
provided an answer.

Best regards,
Andrew

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

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 4 Jul 2007 13:30:27 -0400

Dear colleagues,

Best regards,
Andrew

---

From: John Schnizlein <[email-masked]>
Date: Tue, 24 Jul 2007 10:08:54 -0500

As a prelude to my comments, I should say that I appreciate your  
contribution, and do not intend to delay it.  I think the reference  
to RFC 2505 might fit properly in the history section.  My reason for  
advocating inclusion is like my reason for supporting the history  
section in general: completeness.  A little bit of summary can avoid  
accusation that something that might be important was ignored.

I suspect that the MTA language you mentioned (for which you found no  
reference) in the meeting today might be this part in RFC 2505:

2.5. Refuse mail based on SMTP_Caller address

    The MTA SHOULD be able to accept or refuse mail from a specific host
    or from a group of hosts. Here we mean the IP.src address or the  
FQDN
    that its .IN-ADDR.ARPA resolves to (depending on whether you trust
    the DNS). This functionality could be implemented at a firewall, but
    since the MTA should be able to "defend itself" we recommend it  
be able
    to as well.

    It is RECOMMENDED that the MTA be able to decide based on FQDN  
hostnames
    (host.domain.example), on wild card domain names (*.domain.example),
    on individual IP addresses (10.11.12.13) or on IP addresses with a
    prefix length (10.0.0.0/8, 192.168.1.0/24).

    It is also RECOMMENDED that these decision rules can be combined to
    form a flexible list of accept/refuse/accept/refuse, e.g:

John

---

From: John Schnizlein <[email-masked]>
Date: Tue, 24 Jul 2007 10:08:54 -0500

John

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 24 Jul 2007 14:53:16 -0400

Hi John,

> accusation that something that might be important was ignored.

Thanks for the comment.  

I am not sure that adding a reference to RFC 2505 to the history
section would be a natural fit: that section is really just about the
history of using reverse DNS as part of a security strategy.  I think
that anti-spam efforts are distinct from such a security strategy, so
I think we should keep them separate.

I can nevertheless see your argument, which is why I raised the topic
in the meeting today.  I did not hear much enthusiasm for the
addition, but I think it's worth considering in light of your comment.
Therefore, if people think it is a worthwhile addition, please send
your comments to the list.

If we want to make the addition, I propose that we add one sentence to
a paragraph in section 3.1:

   Some anti-spam systems use the reverse tree to verify existing
   reverse mapping, or to check for matching reverse mapping.  **This
   practice was encouraged by [RFC2505].** Some mail servers have the
   ability to perform such checks at the time of negotiation, and to
   reject mail from hosts that do not have matching reverse mappings
   for their hostnames.

The new sentence is enclosed in asterisks.  

If anyone wants to speak strongly in favour of this addition, then we
can decide whether we should proceed.  In the absence of strong
argument in its favour, I don't think we'll make the change, because
my sense of the room today was that most people thought we should not
add this.

A

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 24 Jul 2007 14:53:16 -0400

Hi John,

Thanks for the comment.  

A