Thanks for the quick responses, this was what I feared. In the mean time, I have thought a bit about the design. I think I will start not with the cache, but rather by checking to see if I can move the reverse name resolution further down in the processing flow AND move it to one central location. That makes it easier and more efficient to do caching.
One drawback when doing so is that the name resolution potentially happens much later than the message reception. Just think about a busy system, or even one waiting for an upstream server to come online again, that lacks behind some minutes or even some hours. When I do the name resolution in the backend thread, the reverse entries may have changed since the message was received :( For many cases, this may be acceptable, for some not. I will probably need to at least define a config value which enables direct queries vs. deferred ones. Any comments on that issue would also be most welcome. Thanks, Rainer > -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of RB > Sent: Wednesday, September 30, 2009 5:55 PM > To: rsyslog-users > Subject: Re: [rsyslog] DNS cache and expiration > > On Wed, Sep 30, 2009 at 08:31, Rainer Gerhards > <[email protected]> wrote: > > After my bughunt looks almost completed, I have come back to > implementing the > > name lookup cache. However, I just found out that obtaining the > expiration > > period of the name lookup seems not to be covered by the "usual" > socket > > calls. Or did I just miss them? > > Unfortunately not - most resolver libraries provide only what the > programmer usually wants - the symbolic (name) or numeric (IP) result > of a query. I've not looked carefully at APIs like res_query, though, > and that might bring what you need. > > > Any advise, comments and hints regarding name caching and expiration > would > > deeply be appreciated. > > This was my greatest concern with doing *good* internal caching in > rsyslog - you're almost guaranteed to use and/or implement a large > chunk of proper resolver functionality. Depending on how readable you > find Perl, the Net::DNS infrastructure may provide some good pointers > on implementing custom resolution toolkits. The djbdns 'dnscache' > program (and perhaps the djbdns client resolver library itself) could > also be good pointers. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
