Sean Straw / PSE wrote:
> I concur with this POV - Analog should NOT have a bunch of extra code
> added to do rDNS. If anything, having Analog automatically invoke some
> program with some options, specifying the logfile which Analog will be
> running against, but before Analog opens it, might be a nice option (to
> make the preprocessing basically transparent), but Analog itself should
> still focus on the actual log analysis -- not resolving data that
> perhaps should have been resolved by the webserver or by some other
> program intended to handle that sort of thing.
This seems like a good idea. If Analog had a DNSLOOKUP command similar
to the UNCOMPRESS command, it would make it simpler to plug-in
third-party rDNS tools. Since Analog's goal is to provide only basic DNS
lookups, this would encourage the use of plug-in tools when needed.
> BTW, if you're running a webserver, also running an installation of BIND
> just to manage cached lookups (if you're not already running BIND for
> primary DNS) can significantly improve DNS lookup response, because once
> a specific host has been resolved, you're not pounding on the network
> looking the same host up just a moment later.
Actually Sean, resolving DNS from the Webserver is not efficient on high
traffic sites. There just isn't time to do the necessary lookups before
the page needs to be delivered. And whether you're running BIND locally
or not, a cache very close by will likely contain all your recent
lookups. Of course it would be faster to run BIND on the machine doing
the lookups, but it may not be that big a savings (depending on who else
is using the nearby cache).
> OTOH, perhaps revising the format of the DNS cache file would be a good
> idea. <developer's talk snipped>
Judging from the popularity of jdresolve, this may be a good idea.
However, your solution still stores one IP address per hostname in the
table. To efficiently handle jdresolve lookups it would make sense to
have a format the allows for a range of addresses (like "192.168.0.0/255
localnet" ).
> I think the above changes (and any number of variations) might be best
> served by a library which Analog (written in perl after all)
Analog is written in C. It is not possible to write any significant log
analysis program in Perl. It's just not fast enough or scalable enough.
> would use
> -- say Analog initialized the resolution library by calling a function
> like hostresolve_init() to allow the resolution library to do
> initializations (whether this is loading the cache file in its entirety,
> or doing something like I outline above, or just opening the files),
> then when a resolution is needed, calling hosresolve( ipaddr ), and on
> program completion, doing the right thing can calling
> hostresolve_shutdown().
Opening up an API like this to other programs would be a complicated
endeavor. I think that a simple DNSLOOKUP command, as described above,
would be much simpler and provide essentially the same service. If it
were necessary to init and shutdown a DNS lookup service then those
commands could be added as well, or could be run as prefix and postfix
to the Analog command (e.g. "myDNS start; analog; myDNS stop")
--
Jeremy Wadsack
Wadsack-Allen Digital Group
------------------------------------------------------------------------
This is the analog-help mailing list. To unsubscribe from this
mailing list, go to
http://lists.isite.net/listgate/analog-help/unsubscribe.html
List archives are available at
http://www.mail-archive.com/[email protected]/
and
http://lists.isite.net/listgate/analog-help/archives/
------------------------------------------------------------------------
