On 2021-11-10 11:47 a.m., Rob McEwen via mailop wrote:
The only issue here is that, for every user/customer that needs a unique
key, an entirely different set of data has to be loaded into memory on
the server. That's a huge limitation. It doesn't "scale". Therefore, for
invaluement, in our new-ish direct query system (that started in 2018),
that uses such unique keys for each DNS query customer, I had to
basically custom program rbldnsd to overcome this. It took dozens of
hours of very frustratingly-difficult programing, but that's partly
because I'm not very good at C++! (by doing this myself, that was
especially helpful for keeping this very hard-earned expertise in-house
and very guarded!)
Not sure why we/you should keep it 'inhouse', as it seems that all RBL
operators are adopting a similar strategy.
We need more co-operative opensource collaboration, and ensure that
RBLDNSD doesn't end up with twenty forks, so it gets even better
performance, and simply has an option to treat all queries to a 'keyed'
subdomain, either to be served a single data source, or individual data
sources, based on a configuration item ;)
And of course, the DSO support ;)
Already, the source/git are in too many multiple places. Whatever
happened to giving back to opensource? I think you are building on
other's 'hard-earned expertise' as well.
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
