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

["John Levine" <[e-mail]>]

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

>FWIW, the DNSBL case can be worked around using 0 as TTL for DNSBLs
>(directly on the DNSBL side, or on the caching side for resolvers with
>the ability to do that).

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.

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

>> * Is there some reasonable way for networks to publish allocation
>> granularity

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

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

R's,
John