Subject: [dnsop] Review of draft-ietf-dnsop-inaddr-required

From: Andrew Sullivan <[email-masked]>
Date: Fri, 27 Jan 2006 17:32:57 -0500

Hello,

Last December, I committed to review
draft-ietf-dnsop-inaddr-required.  My apologies for being late with
this.

I have read draft-ietf-dnsop-inaddr-required-07.txt.  I have also
reviewed the archives about the history of this document.  I have
some reservations, although not ones I think are significant.  It
appears to me that there is something slightly confusing to users
about the draft.

The discussion in section 3 notes that there are a number of
unfortunate consequences of missing IN-ADDR.  It seems to me
therefore that the recommendations in section 4 come out as a little
too ambivalent: the suggestion appears to be that IN-ADDR is a good
thing, but that people shouldn't really use it.  In particular, one
reading of section 4.2 very nearly says, "You can't, and shouldn't,
use IN-ADDR."  If, however, I'm reading this right, the idea is more
strongly expressed as, "Applications SHOULD NOT rely [exclusively] on
IN-ADDR for proper operation".  I'd also like to see softenend the
part that says, "generally just increases load on DNS servers," to
"often" or even "almost always just increases load on DNS servers."

The reason I think this is that there are some cases where IN-ADDR,
particularly coupled with the lookup from the PTR, is still a good
basis on which to take a decision.  Email remains, I suspect, the
best example, because of the hordes of spambot nets.  If one's
bandwidth is being completely consumed by illegitimate email
attempts, then choosing to reject connections on what would otherwise
be an illegitimate basis might be defensible in that case.

The other trouble I see is that the document appears to suggest that
the IN-ADDR strategy is a bad way to apply "points" when
automatically evaluating mail as possibly spam.  I'm aware that there
are a lot of other methods for handling this, and that it is a rare
case when the strategy will actually help.  But some pointers to
those other methods would probably be needed if one is going to
convince people not to continue to rely on this method.  

Best regards,
Andrew

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

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 30 Jan 2006 09:41:13 +0100

On Fri, Jan 27, 2006 at 05:32:57PM -0500,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 54 lines which said:

> thing, but that people shouldn't really use it.

If I may, IMHO, the real issue is not wether PTR are good or not but
"Are people able to create and modify them?" and the answer is NO for
many cases. 

Because, even if you love PTR and you want to add them, you depend on
persons above (in the DNS reverse tree) you. I deeply regret that the
draft does not emphasize this problem (may be because IETFers are
typically working near the ".arpa" apex and do not see the problems of
the poor guys at the bottom of the tree).

Therefore, mandating the use of PTR records is a Bad Thing.

[I can add that getting a ip6.arpa or in-addr.arpa delegation from
above is more difficult in some parts of the world. Mandating PTR
records means banning Africa, for instance.]

> best example, because of the hordes of spambot nets.

I've often read that and I always challenge the persons who claim so
to back these claims with surveys, figures, etc.

With most IAP, every PC gets a PTR, wether it hosts a zombie or not,
so I doubt it can be a spam indicator.

> But some pointers to those other methods would probably be needed if
> one is going to convince people not to continue to rely on this
> method.

I disagree: when an idea is a bad one, you can say so even if you have
nothing to replace it right now.

Many sysadmins would like to have a sure way to tell if a SMTP client
is a spammer or not and they are ready to rely on snake oil for
that. IMHO, the IETF should tell them that there is no magic solution.

.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 Jan 2006 07:26:39 -0500

> "Are people able to create and modify them?" and the answer is NO for

I haven't run into this issue; but to the extent it's a problem (and
I've no reason to doubt you), you're quite right that the draft needs
to discuss it.

> so I doubt it can be a spam indicator.

You're quite right that every PC usually gets a PTR; but the
technique that people use is to look at the greeting, look at the
results of the reverse lookup, and compare them.  If they don't match
(for some value of match -- often this means the greeting just needs
to be in the domain of the reverse lookup), you reject the
connection.

But in any case, you can't back this up with figures, &c., because
the decision is a subjective one.  It's a matter of how much you
trust the sender.  Since the problem of spam is basically one that
arises because of the low cost to the sender, then an email
administrator might legitimately decide that s/he is willing to make
it slightly harder to send mail to a site, in an effort to reduce the
junk that comes in.  The idea here is that of a bozo filter: if the
mail is coming from a site that hasn't managed to configure things so
that everything matches, then maybe you don't want mail from that
site.  Probably that mail should be coming through the ISP's mail
relay anyway, so this is a useful technique.

> nothing to replace it right now.

Sure.  But if one actually hopes to influence behaviour, one had
better have something to say about the goals of the behaving parties. 
If we believe the technique causes more harm than benefit, we need to
say why that is the case; and the "why" had better not be "some mail
won't get through", since that's the whole point.  I don't see that
in the draft at hand.  

If the idea is that the document should provide guidance to people
not to use the technique even though they believe it helps them,
then the argument needs to be stronger as to why it's a harmful
technique.  The document currently just says this:

   The use of IN-ADDR, sometimes in conjunction with a lookup of the
   name resulting from the PTR record provides no real security, can
   lead to erroneous results and generally just increases load on DNS
   servers.  Further, in cases where address block holders fail to
   properly configure IN-ADDR, users of those blocks are penalized.

If I were a current user of this technique, I'd respond this way:

1.	I don't want real security; I'm using this as a bit of
evidence in a probabilistic calculation.

2.	I don't mind the erroneous results, as I'd rather reject in
error than allow traffic I don't want.

3.	That's what the DNS is for.  I pay my ISP for this.

4.	I _want_ to penalise people who fail to properly configure
IN-ADDR.  I don't want such people communicating with me.

I know a lot of sysadmins who would respond exactly this way.  In
some cases, I have a great deal of sympathy for them.  Telling such
people, "Don't do this, and no we don't have an alternative," is a
way to ensure our advice is ignored.  

I'll note, by the way, that some people might be susceptible to the
argument that this isn't what the DNS is for, and that the ISP isn't
providing the service anyway, so that using this technique is as
costly to the rest of the Internet as spam is to the recipient (i.e.
that using this technique all the time causes the same free rider
problem spam itself causes).  So strengthening this part of the
document might help.

> is a spammer or not and they are ready to rely on snake oil for

I don't think that's a fair characterisation of what the sysadmins
are doing.  They want a way to tell, on balance, whether their trust
limits are met for inbound connections.  It's a probabilistic, not a
binary, matter.  In some cases, they can afford to reject possibly
good traffic in favour of reduced traffic.  Making such decisions is
their job; that's why they're called "admins".

A

.

---

From: "Brett Carr" <[email-masked]>
Date: Mon, 30 Jan 2006 13:40:48 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephane 
> Bortzmeyer
> Sent: Monday, January 30, 2006 9:41 AM
> To: Andrew Sullivan
> Cc: [email-masked]
> Subject: [dnsop] Re: Review of draft-ietf-dnsop-inaddr-required
> 
> On Fri, Jan 27, 2006 at 05:32:57PM -0500,  Andrew Sullivan 
> <[email-masked]> wrote  a message of 54 lines which said:
> 
> > unfortunate consequences of missing IN-ADDR.  It seems to 
> me therefore 
> > that the recommendations in section 4 come out as a little too 
> > ambivalent: the suggestion appears to be that IN-ADDR is a 
> good thing, 
> > but that people shouldn't really use it.
> 
> If I may, IMHO, the real issue is not wether PTR are good or 
> not but "Are people able to create and modify them?" and the 
> answer is NO for many cases. 

I would say in the majority of cases most end users (by this I mean
businesses willing and able to run their own stable dns servers) are able to
get reverse delegation from their network provider.
What are these cases, maybe we can address the problem of what causes this
inability to provide reverse delegation.

> Because, even if you love PTR and you want to add them, you 
> depend on persons above (in the DNS reverse tree) you. I 
> deeply regret that the draft does not emphasize this problem 
> (may be because IETFers are typically working near the 
> ".arpa" apex and do not see the problems of the poor guys at 
> the bottom of the tree).

Then maybe this problem also needs addressing in a separate draft, but I
don't think that difficulty in obtaining PTR should stop us encouraging the
use of it.

> Therefore, mandating the use of PTR records is a Bad Thing.

Well I would also say that maybe this document is badly titled as it doesn't
seem to mandate the use of PTR so much as encourage it.

Taken from the Introduction:

"This document both encourages the presence of these mappings and
discourages reliance on such mappings for security checks."

> [I can add that getting a ip6.arpa or in-addr.arpa delegation 
> from above is more difficult in some parts of the world. 
> Mandating PTR records means banning Africa, for instance.]
> 

Well I don't think any of us wants to see moves that would ban users In
Africa from using the internet however I still say encouraging users to use
reverse mappings where they are able to do so (especially in areas of
Internet growth such as Africa) is an important message.

Brett

--
Brett Carr                              RIPE Network Coordination Centre
Systems Engineer -- Operations Group    Amsterdam, Netherlands
GPG Key fingerprint = F20D B2A7 C91D E370 44CF  F244 B6A1 EF48 E743 F7D8

.

---

From: "'Stephane Bortzmeyer'" <[email-masked]>
Date: Mon, 30 Jan 2006 13:53:14 +0100

On Mon, Jan 30, 2006 at 01:40:48PM +0100,
 Brett Carr <[email-masked]> wrote 
 a message of 71 lines which said:

> I would say in the majority of cases
                     ^^^^^^^^^^^^^^^^^
                     May be in RIPEland but not everywhere on the
		     Internet.

> What are these cases, maybe we can address the problem of what
> causes this inability to provide reverse delegation.

Sure, but it is a long-term effort. You need to convince a lot of lazy
or incompetent IAP.

> I don't think that difficulty in obtaining PTR should stop us
> encouraging the use of it.

The problem is that, once a RFC is out with sentences like "you really
should have a PTR", two things will happen:

* people will have something to show to their lazy and incompetent IAP
to encourage them to set up arpa delegation (a good thing),

* more people will filter based on the lack of PTR records (a bad thing).

> Well I don't think any of us wants to see moves that would ban users
> In Africa

I vividly remember a public meeting about spam where the AOL
representative (Nicolas Pioch) proudly claimed "We have blacklisted
the three-quarters of Africa".

> encouraging users to use reverse mappings where they are able to do
> so (especially in areas of Internet growth such as Africa) is an
> important message.

Since Afrinic works, things are certainly getting better. However, I
just have to open a few messages at random in an african mailing list
and I can find in the Received headers the following mail servers
without PTR:

62.56.190.2 (62.56.188.0/22 has not been transferred to Afrinic, for
reasons I do not know) There is no arpa delegation from the RIR.

213.136.96.104 There is a delegation but no PTR

...
.

---

From: Jim Reid <[email-masked]>
Date: Mon, 30 Jan 2006 13:48:18 +0000

> their job; that's why they're called "admins".

Well this sysadmin has kludged their mail server to drop SMTP  
connections from hosts that don't have a reverse DNS entry. [ie: No  
PTR record, no service.] This is remarkably effective at reducing  
spam and doesn't seem to create too many false positives. If this  
policy has the side effect of getting people to fix their reverse  
DNS, then that's an added bonus.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Daniel Senie <[email-masked]>
Date: Mon, 30 Jan 2006 08:56:53 -0500

>don't think that difficulty in obtaining PTR should stop us encouraging the

I concur on this. The reality is some regions of the world have 
little trouble with this, while others have a lot. Similarly some 
classes of connectivity have more trouble than others. That some 
large broadband providers, in their quest to race to the bottom of 
the pricing heap, have no margin left to service business customers 
adequately is a business problem, not a protocol problem.

The point of this document, or any other BCP-tracked document, is to 
recommend how things should be done, not to explain how to live with 
things as they are. BCP38 is a good example of this. There are lots 
of folks who still don't want to do ingress filtering, yet there are 
many who do it and it helps. Should we not have published BCP38 
because the recommendations require much cooperation to be effective 
or that some network operators won't cooperatively implement it? 
Having a BCP say "this is the preferred way to do something" would in 
this instance provide those not getting PTR record control from their 
ISPs with something to point to, saying "it'd be nice if you gave us 
a way to do PTR record work, so that we can comply with BCP xxx" or some such.

>seem to mandate the use of PTR so much as encourage it.

Please look at the actual title in the draft, and not the file name. 
The file naming is historical. The tone and scope has changed 
significantly since the first draft, to tone done the requirement aspect.

.

---

From: Andras Salamon <[email-masked]>
Date: Mon, 30 Jan 2006 16:13:18 +0200

> reasons I do not know) There is no arpa delegation from the RIR.

So RIPE and Afrinic didn't coordinate transfer of the netblock properly.
I don't see how this relates to the publication or otherwise of a draft
which encourages DNS admins to provide PTR records.

> 213.136.96.104 There is a delegation but no PTR

So, we seem to have an ISP in Cote d'Ivoire that hasn't bothered with
international best practice.  Maybe publishing an RFC that recommends
that they do, in fact, provide PTR records, will help this situation.
It might mean that the responsible individuals can become aware of the
issue, and justify to management why they should spend effort on what
otherwise can seem an unnecessary frill.

Prior to the establishment of Afrinic, large amounts of address space was
delegated to ISPs and organisations all over Africa, and PTR records were
set up for these as a matter of course.  Some other African organisations
chose not to provide PTR records.  However, I don't see why we should
accept poor operational practice and use it to justify why we should
not publish a document that intends to help the situation.

In fact, your arguments seem to completely support publication of the
draft.  If people are already blackholing based on lack of PTR mapping
(which clearly they are), then publishing a document 1) encouraging people
to provide these mappings, and 2) discouraging the practice of filtering
based on non-availability of PTR records, both seem to be highly sensible.

(Greetings from Johannesburg, South Africa)

-- Andras Salamon                   [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 30 Jan 2006 15:55:44 +0100

On Mon, Jan 30, 2006 at 01:48:18PM +0000,
 Jim Reid <[email-masked]> wrote 
 a message of 19 lines which said:

> doesn't seem to create too many false positives.

You mean that you received no email complaint from people who were
blocked?
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Jim Reid <[email-masked]>
Date: Mon, 30 Jan 2006 15:54:28 +0000

> You mean that you received no email complaint from people who were  

Nope. Once or twice the blocked complain via an intermediary and then  
fix their broken reverse DNS. Or they find some other way of reaching  
me.

.

---

From: Shane Kerr <[email-masked]>
Date: Mon, 30 Jan 2006 17:32:11 +0100

>which encourages DNS admins to provide PTR records.
For the record, 62.56.128.0/17 is allocated to an Local Internet
Regsitry (LIR) which is in the RIPE NCC service region. LIRs are free to
use their allocations in any part of the world they want:

http://tinyurl.com/exvex

--
Shane
.