RBL cache {Scanned by HJMS}

[Chris Trudeau-Personal]

Perhaps what Ugo is looking for is an "adapted" reverse lookup process.

If there are 30 messages in a batch, he doesn't want to have to query the
RBL for each of these via reverse DNS...he wants to have a local "process"
that maintains a cached query for these requests for four hours.

which is in essence a caching DNS, I'm just not sure how he could build a
caching DNS that would set the TTL to 4 hours no matter what the master DNS
said.

I can see how this could lighten the load on the RBL list maintainers and
distribute the load to local DNS servers.

seems to make sense...the easy way to do this, would be to have the list
maintainers create extended TTL on their records...this would allow for
local DNS servers to cache the balcklists for longer periods of time
reducing the number of times mailscanner implementations would have to query
the blacklists directly.

CT


----- Original Message -----
From: "Richard Lynch" <rich at MAIL.WVNET.EDU>
To: <MAILSCANNER at JISCMAIL.AC.UK>
Sent: Saturday, September 13, 2003 10:57 AM
Subject: Re: RBL cache {Scanned by HJMS}


> Ugo, what you are not realizing is that RBL systems are implemented
> using the DNS.  That's how they work.  They do not maintain some sort of
> native database where they do lookups in response to queries.  Instead
> they use an already existing, highly reliable, distributed database
> system -- the DNS.
>
> So, the client simply does a DNS lookup on a hostname and the response
> indicated whether it is blacklisted or not.  For example (simplified for
> illustration), the client issues a DNS query for
> 10.25.100.1.rblsite.net.  The response it gets will indicate whether
> 10.25.100.1 is blacklisted or not. This has huge advantages.  You get
> all the benefits of a mature, distributed, caching, database system.  No
> point in reinventing a distributed database system that already exists
> and is in widespread use.
>
> --
> Richard Lynch <rich at mail.wvnet.edu>