Either the time, OR, it could be 'bad' data in the dnsCache.db (that's what the textinfo.html results would show).
Although the structure used in dnsCache.db had a field for the TTL, it wasn't being used until a few months ago, when I fixed the code. Still, the entry did 'exist' (it was found in the database), but of the wrong length, so it was ignored. I think this was then caught later on and so ntop tried to do a resolution - hence the huge # of calls. It may be that we want to push this into the make install process and the rpm's - delete older files??? Gotta think about that... -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > [EMAIL PROTECTED] > Sent: Thursday, March 11, 2004 9:22 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [Ntop] Yet another DNS question.... > > > > Burton, thanks for the reply. I did a couple of things this > morning to try > and pin this down: > > - I deleted the addressQueue.db and the dnsCache.db files. > - Built a bind server local to the Linux box and updated my > /etc/resolv.conf to point at 127.0.0.1 > - Configured the BIND server to be secondary for all reverse zones in my > building, 15 of them. > > This seems to have solved the problem. It apparently was related to the > time it was taking to do the name lookups?? > > > > -- > > J. Eric Josephson > Director of Network and System Operations > 978-720-2159 > mailto:[EMAIL PROTECTED] > > > > > > "Burton M. > > Strauss III" To: > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED] cc: > > rt.com> Subject: RE: > [Ntop] Yet another DNS question.... > Sent by: > > [EMAIL PROTECTED] > > it > > > > > > 03/10/2004 08:02 > > PM > > Please respond to > > ntop > > > > > > > > > > No beating, just... > > Remember DNS resolution is a three layer process... see > resolveAddress() in > address.c - This runs in an async thread, handling the queue. > > 1. If it's in the cache (dnsCache.db), that value is used. Cached entries > have a TTL that is unique to ntop - CONST_DNSCACHE_LIFETIME in > globals-defines.h. Default is 24*3600 seconds or 24 hours. > > 2. If it's not cached, ntop uses the host's gethostbyaddr() calls (these > will hit the /etc/hosts file, DNS server, whatever - same as nslookup). > That's it. > > > Now sniffing runs separately and loads the cache with data from the > responses to other peoples queries. > > > So dnsCache.db becomes a pretty good cache over time. > > However, a negative reply - even a transient one - will stick around for > the > LIFETIME period. > > > All of this is EXPLICITLY counted in the info.html and textinfo.html > reports: > > Address Resolution > > DNS Sniffed: > > DNS Packets sniffed.....0 > less 'requests'.....0 > less 'failed'.....0 > less 'reverse dns' (in-addr.arpa).....0 > DNS Packets processed.....0 > Stored in cache (includes aliases).....0 > > > IP to name - ipaddr2str(): > > Total calls.....48 > ....OK.....0 > ....Total not found.....48 > ........Not found in cache.....44 > ........Too old in cache.....3 > > > Queued - dequeueAddress(): > > Total Queued.....14 > Not queued (duplicate).....34 > Maximum Queued.....7 > Current Queue.....4 > > > Resolved - resolveAddress(): > > Addresses to resolve.....11 > ....less 'Error: No cache database'.....0 > ....less 'Found in ntop cache'.....0 > Gives: # gethost (DNS lookup) calls.....11 > > > DNS Lookup Calls: > > DNS resolution attempts.....11 > ....Success: Resolved.....8 > ....Failed.....2 > ........HOST_NOT_FOUND.....2 > ........NO_DATA.....0 > ........NO_RECOVERY.....0 > ........TRY_AGAIN (don't store).....0 > ........Other error (don't store).....0 > DNS lookups stored in cache.....10 > Host addresses kept numeric.....2 > > > That's the FIRST place you have to start to figure out what's going on. > > > But somehow, everytime I ask anyone for this information, they're never > heard from again... > > > -----Burton > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > > [EMAIL PROTECTED] > > Sent: Wednesday, March 10, 2004 11:42 AM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: [Ntop] Yet another DNS question.... > > > > > > > > OK, I'm ready to take my mailing list beating... > > > > I looked through the old list postings and found similar > > questions and some > > answers, but could not spot the information I was looking for. > > > > In my implementation of NTOP, I am watching all traffic going out of our > > corporate firewall. NTOP seems to capture most DNS requests that > traverse > > the firewall. That is working fine. What I'm having a problem with is > > that I have hundreds of internal machines that generate traffic to the > > external world, but have no cause to have their own IP address resolved > by > > any traffic I can sniff. > > > > I am starting NTOP with the following: > > > > ntop -d -u ntop -i eth0,eth1 -M -o -m 10.0.0.0/8 -p /etc/protocols.ntop > -P > > /tmp > > > > and have all of my subnets broken down into 24 bit masks. i.e > 10.12.54.x, > > 10.12.44.x etc... > > > > I am using today's CVS pull, but have had this "problem" for a very long > > time. > > > > I there a way I can specify what address to aggressively do reverse name > > resolution on or simply to have NTOP actively resolve all IP addresses, > > thus more completely populating my internal machine addresses > with names? > > > > -- > > > > J. Eric Josephson > > Director of Network and System Operations > > 978-720-2159 > > mailto:[EMAIL PROTECTED] > > > > > > > > _______________________________________________ > > Ntop mailing list > > [EMAIL PROTECTED] > > http://listgateway.unipi.it/mailman/listinfo/ntop > > > > _______________________________________________ > Ntop mailing list > [EMAIL PROTECTED] > http://listgateway.unipi.it/mailman/listinfo/ntop > > > > > > _______________________________________________ > Ntop mailing list > [EMAIL PROTECTED] > http://listgateway.unipi.it/mailman/listinfo/ntop > _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
