ietf-mxcomp
[Top] [All Lists]

RHSBL scalability (affects MARID proposals).

2004-05-12 20:45:45

Has anyone here considered the issue of RHSBL scalability, compared to regular DNSBL scalability? It seems that the problem of making a DNSRBL work on a large scale is something we think we can solve - some not so well run ones have been DDoSed to death, but others have learned and manage to survive large scale DDoS attacks. A simple IPv4DNSRBL (that just answers yes/no for a listing) can, absolute worst case, store its DB in 512MB (2^32 bits) of RAM. If we assume spammers will churn through $5 domains in very high volume, and notice if any of them get expired by BL maintainers, so they all need to stay in BLs, how big a BL are we talking about? Of course compression (e.g. an algorithm used for spellcheck dictionaries) can be used; bind uses something, but I don't know what; don't know what djbdns uses either; I could look at the code. This is relevant because all the proposals (SPF explicitly and other proposals at least implicitly - DMP, RMX, FSV, DK, CID, and CSV) require RHSBLs to work.

Are there going to be 'subject matter experts' on DNS at the upcoming meetings, apropos agenda item 5:
5. DNS Record Type
who perhaps would also address this concern? I'm cc: ing the group's Technical Advisors, whom, I note, haven't posted yet.
** <mailto:roy(_dot_)arends(_at_)telin(_dot_)nl>