Re: [Asrg] rDNS and cache issues, was How will we manage IPv6 spam?

["Emanuele Balla (aka Skull)" <[e-mail]>]

On 8/20/12 1:38 AM, John Levine wrote:
>> If this problem is going to raise, it's going to raise exactly the same
>> way with rDNS as well, so having v6 DNSBLs in place is going to make the
>> problem worse by just a factor related only with the number of DNSBLs in
>> place. 2x? 5x?
> 
> That's true, but people I've talked to at large mail systems say
> they're not planning to do rDNS lookups for v6 mail, both because of
> the cache problems and because they don't think it will catch much
> spam.

Other than the spam problem there are other needs for rDNS lookups,
starting from logging...

So while I understand the approach (not that I completely agree with
it), but I'm not sure it's completely feasible unless we change a lot of
things in the way we usually work...


> That's true, but what would be really nice would be DNSBLs that tried
> to be smart about TTLs based on the amount of traffic an IP sends.
> I'd think it should be possible to estimate that pretty well from
> query logs.

Sure, that could be a way: starting every listing with 0 TTL and
increasing it up to a maximum if it's generating an intense mail flow.
Doing the opposite, though (lowering the TTL as the mail source "calms
down") could be less easy to do: the same presence of caching inhibits
the DNSBL from estimating the lookup rate...

Note anyway that we're only considering the case of positive DNS answers
(or listed entities), but I'd expect that most of the cache blowup
problem will be generated by NXDOMAINs, at list at first.
We have much less control on that...


>> make it query for the /64 network instead of the full address, ...
>> This would significantly reduce the size of the caching problem, but
>> would render listings much less granular and whiltelisting of single
>> hosts basically impossible...
> 
> I think you'll also find that you're blacklisting whole racks at
> hosting companies when one customer has an insecure PHP script.

Know that, yes...


>> I already had the chance to tell you that, but RIPE DB provides an
>> "assignment-size" field with this explicit purpose:
> 
> Do you really want people querying that at DNSBL rates?  This needs
> to be at a lower level.

Not suggesting it for end-user lookups. Simply suggesting that if that
information is published in whois, it's there for whoever wants to
collect it and use it (starting with DNSBLs).

BTW, in order to make the same information available and easily
queryable from end users, the most obvious place to put it is probably
rDNS; but again, you'll have all the caching problems again.


>>> * Can we build models to predict this stuff now, since under the most
>>> optimistic scenario it'll still be years before the v6 mail volume
>>> approaches v4 mail volume.
>>
>> DUNNO
> 
> Hey, I know a research group where we could give it a try.

;-)