Domain Name Server Operations (dnsop)

Andrew Sullivan | 4 Jul 2007 19:30

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

Dear colleagues,

On Tue, Jul 03, 2007 at 10:15:01AM -0400, 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-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

(Continue reading)

headers

John Schnizlein | 24 Jul 2007 17:08

regarding RFC 2505

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:

(Continue reading)

headers

Andrew Sullivan | 24 Jul 2007 20:53

Re: regarding RFC 2505

Hi John,

On Tue, Jul 24, 2007 at 10:08:54AM -0500, John Schnizlein wrote:

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

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

(Continue reading)