Re: DNSBL caches and IPv6, again

Dave Warren <[email protected]>
Newsgroups gmane.ietf.asrg
Message-ID <[email protected]>
On 9/19/2012 2:33 PM, John R. Levine wrote:
> As I've mentioned a few time, I'm trying to figure out the cache 
> behavior of DNSBLs, so we can try and predict whether IPv6 BLs would 
> make the DNS melt down.
>
> If I had traces of [IP,timestamp] from some medium sized mail sytems, 
> I could do some cache simulations.  Medium is in in the range of a 
> million connections a day.  Anyone have access to one of those?  
> Nobody has IPv6 mail at that scale yet, but IPv4 would do fine for this.
>
> I don't need to know whether the connection was for real mail or 
> spam.  If you consider the IPs confidential, hashes or tokens would be 
> fine so long as the same token consistently corresponds to the same IP.


Isn't the fear that with IPv6, spammers simply won't use the same 
address twice, thereby causing cache meltdown on a scale that isn't 
possible in today's IP-scarce IPv4 world?

In other words, the data you get from legitimate mail servers in IPv4 
may roughly correspond to the  data you'd get from legitimate mail 
servers in IPv4, but the data you get from spammers today won't be at 
all representative of IPv6 spammer's potential behaviour.

Heck, even the data from legitimate mail might not mean much going 
forward. I'd be at least a little tempted to send mail from different 
clients from different IPs (or possibly even with more granularity for 
clients who send person to person, bulk and transactional mail, but 
don't currently send enough to justify wasting IPs to segregate such 
traffic), so even legitimate sites might end up using a lot more 
outbound IPs, simply because they can.

In other words, as much as I'd love to see some concrete data on this 
going forward, I'm not sure that these simulations will apply to future 
real-world situations.

-- 
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.