Re: Comments surrounding draft-iab-dns-applications-01

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In message <alpine.BSF.2.00.1107042151340.62218@xxxxxxxxx>, "John R. Levine" wri
tes:
> >> Over in e-mail land, we've been pondering the behavior of spammers, who
> >> will likely hop to a different IPv6 address for every spam. If you do rDNS
> >> lookups, your cache will fill up with useless entries, maybe PTR, maybe
> >> NXDOMAIN, it hardly matters.  DNSBLs and DNSWLs, if done the same way as
> >> they are in IPv4, have the same problem.  These issues are well known in
> >> the mail ops community, where it's now the standard advice not to try rDNS
> >> lookups on incoming IPv6 mail.
> >
> > Or you just tune the cache retention times.  For NXDOMAIN/NODATA
> > that's 3 hours by default for named but could be tuned down to 10
> > minutes or lower without ill effects.  RFC 2308 recommends 1-3 hours.
> 
> DNSBLs already set the min pretty low, e.g. 150 sec for Spamhaus. 
> Doesn't really matter how low it is if you have so many entries that they 
> force out the useful ones.

DNS[WB]L's are not rDNS.  rDNS is designed to associate a name with
a address.

DNS[WB]L's have never been a good fit to the DNS, rather they have
not been a bad enough fit to require something better to be done.

The naive approach of reversing the address, converting to nibbles
and appending a suffix won't scale.

For IPv6 if you did the reverse of /48, /52, /56, /60 and /64
prefixes, which matches delegation patterns along with NXDOMAIN
synthesis, you would still be fine.  You stop the search on NXDOMAIN
or data with perhaps a new value which says to continue searching
for white listed records.  One could even start with /32 if one is
worried about spammers pretending to be ISPs.

It requires slightly more intelligence in the MTA that faking up a
address lookup.  NXDOMAIN synthesis doesn't have to be done in the
DNS cache.  It can be done in the application provided it keeps
track of the ranges covered by the NSEC{3} records returned with
the negative responses.  DNSSEC validators that support DLV do this
sort of thing.

> > I also don't see the point in worrying about this.  Caches cope
> > with spammers using a different From domains on each piece of email
> > which is looked up in the DNS.
> 
> Modern spam filters don't usually look up the author domain, since it's 
> usually a genuine address taken from the spam list so it's unrelated to 
> the real sender.  Even if they did, universe of domains that exist is a 
> vastly smaller set than even IPv4 addresses, and one which caches pretty 
> well since so many of them are at large sites like Yahoo and Hotmail.

Both are effectively infinite compared to cache sizes.
 
> In any event, we can argue about how good or bad an idea it is to use IPv6 
> rDNS, but that's tangential to the issues of deciding what are reasonable 
> applications for the DNS.  If you're right and rDNS caches well, it's a 
> good application for DNS.  If I'm right and it doesn't cache at all, it's 
> not such a good application.
> 
> Regards,
> John Levine, johnl@xxxxxxxx, Primary Perpetrator of "The Internet for Dummies"
> ,
> Please consider the environment before reading this e-mail. http://jl.ly
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@xxxxxxx
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]