Re: [Ldapdns-users] Quick Questions for a new subscriber

[Mrs. B. <mrs...@ni...>]

On Fri, 2004-06-25 at 21:09, Dennis Willson wrote:
> One of my projects is a spammer blacklist that's DNS based and I have 
> built Spam honey pot that picks up Spam, tests the source if it's an 
> open relay then enters the results into an SQL database. Every hour a 
> cron job runs, scans the database and builds BIND zone files, 
> transfers them to the master server and then performs an rndc against 
> the master. The public quiries a set of slave servers which are 
> updated when the master sends out its notification about the zone 
> updates. It would be great if I could use this system to do "realtime" 
> updates to the master LDAP server and stop a Spam spew as it happens!

This is one of the motivations for building LDAPDNS. Btw, why bother
testing the source? Surely if it's a good honeypot it should only be
found by robots anyway....

> Is this something that would be possible with this system? How much 
> load can the system take compared to BIND? My slave servers that the 
> public quiries are dual 2.8Ghz P4 Xeon systems with 1GB RAM. Each name 
> server is using about 500Kb/s of bandwidth. 

Poop on a stick is faster than BIND. That out of my system, the BIGGEST
BOTTLENECK is OpenLDAP. Under high load, I've noticed OpenLDAP perform
poorly with Berkley's DB. Using older versions (!) seems to help. I have
reports of Microsoft's Active Directory kicking OpenLDAP's ass, although
I suspect this has more to do with Berkley than any genius Microsoft
might have.

Anyway, EVEN WITH OpenLDAP at it's worst, ldapdns happily reports 2-3
times faster than BIND.

I have absolutely no idea why BIND is so slow, and I'll likely never
find out. Is BIND "fast enough"? If it is, LDAPDNS is too.

Note: Because of the round-trip time with OpenLDAP, LDAPDNS has
turnaround. When OpenLDAP's doing good, I've seen round trip time over a
1mbit/sec connection be as low as 19msec (see list archives for some
woo-hoos). It gets better when using multiple OpenLDAP servers in
parallel. Compare to BIND which seems to want to take 50-60 msec to
answer the same (albeit loaded) query when memory is tight.

HOWEVER: I would not be fair if I didn't suggest that your best bet is
something like rbldnsd or rbldns...

> Also is this project still currently active and will it stay active 
> for at least a while?

That depends on interest :)

LDAPDNS3 started out of contempt for OpenLDAP. I'm looking to solve the
bottleneck described earlier in a more permanent way (and fix bugs)
before I do any new features/releases.