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.
;-)
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg