On 1/8/2011 4:26 PM, John Levine wrote:
1) The listed entry "below" the one requested
2) The listed entry "above" the one requested
3) If available, a "matching" entry
Interesting approach, and as always, experiments are informative.
With that information, a "intelligent" application / query library can
greatly reduce the number of lookups required
Well, that's the problem. Some MTAs keep shared context for all
incoming connections, some (particularly on Unix-ish systems) don't.
Even on systems that share context, it's common to have a cluster of
servers each with their own context. If you don't have the shared
context, this has triple the queries of a naive system.
Consider the situation with many larger server infrastructures. Not
only do you have multiple clusters of machines, but each machine may be
using threads. While there are ways to share server context, in the
large, they can still be bottlenecks even on a single machine.
I can't help thinking that divide and conquer - as in, a highly
efficient distinct cache (whether DNS or not) is better.
* I don't know of a way to serve this off of a generic nameserver
(other than that nameserver being proxy to a "hidden master").
Oh. that's easy, you just have some offline process make up the zone
files and poke the server to load them. It's conceptually no different
from putting files of CIDRs into rbldnsd.
That's how my local rbldnsd infrastructure works. Single query to a
zone that's a merge of the DNSBLs we use.
Spfilter is old (now impractical) code that can do this. I don't know
of any free implementation of anything better - so I had to write my own.
Asrg mailing list