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.
That's why I designed my B-tree scheme so that the shared context is
in the DNS cache. Nearby lookups will fetch exactly the same records
and get good cache behavior, without having to remember anything in
the MTA.
With a system like yours, you could certainly posit a shared local
daemon that caches the info, but if you're going to do that, you might
as well use a daemon-to-server query system that gets 40 ranges per
query rather one that only gets two or three.
R's,
John
PS:
* 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.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg