-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Sven,
Fortunately you already acknowledge that such monitoring functionality
would not make it into the NSD production. That is of course because
we consider there are better monitoring tools, for example dnstop.
There are many more tools, it could be that they already do what you
are trying to achieve. I am not knowledgeable enough with these tools
to know the answer to that.
If you are determined to make your own tool, your final solution
proposal sounds clean to me. Almost like you are trying to create a
nsd-monitor tool:). Personally, as long as the solutions are
standalone, not integrated into the NSD daemon, I would encourage it.
Best regards,
Matthijs
On 02/19/2012 05:16 PM, Sven Ulland wrote:> It could be it's just me, but I've been looking for a way to
> determine which resource records are queried in authoritative
> servers, to 1) see which records are not being used any more and
> can be removed from the zone; and less importantly 2) counting
> questions per RR to determine popularity and/or for graphing
> purposes.
>
> Most zone operators might have 100% control of their RRs, but I
> admit that there are quite a few legacy ones that I have no idea
> whether or not are actually in use. Perhaps if I'm not the only one
> thinking about it, maybe someone has solved this type of challenge
> already?
>
> I implemented a trivial libpcap-based DNS question sniffer that
> you feed a list of RRs, and it will then update a 'lastseen'
> timestamp and a 64-bit hit counter for each RR. A wrapper script
> can send SIGHUP and it would dump the current database to disk for
> further processing (e.g. send data to central collector for entry
> into SQL or similar). It spends quite a bit of cpu time on the pcap
> bit, and also on the internal database handling (where it uses
> uthash), so it's just okay-ish, not really optimal.
>
> I've been thinking of better ways of doing it. A more integrated
> approach would be to add lastseen and hitcount members to the
> domain/rrset struct in namedb.h, make nsd update entries for each
> question, and then have nsdc be able to tell nsd to flush the
> database to disk. This is obviously quite audacious feature creep,
> and I realize the authors' stance on that sort of thing, so it's a
> no go.
>
> An alternative would be to take the database written by zonec, and
> use that with the nsd rbtree implementation in my libpcap
> approach, instead of the simple uthash solution I use currently.
>
> PowerDNS with sql/custom backend.. possibly, but it feels like a
> bit too much.
>
> Please let me hear any ideas or thoughts you might have on this.
> :)
>
> sven _______________________________________________ nsd-users
> mailing list nsd-users at NLnetLabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/nsd-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPS1sDAAoJEA8yVCPsQCW5imwH/2c0hY4AhUSwV42UqJM14BLi
kyYPtG7Kw7uO00BHLiOE7WiJ+DGSeEqyy5Qlz5JqaI969AeAA3exMwUHzxOC0FlM
vCx1N4nFouiLMTR55nMnDb/7HHl22ceB0QQRHugHksOvMn30hw5zxyjY0hYyeXUS
cUI00ZUSPdx7mrvU+KBg4sCQSLYe75zlsptqUKcRXqea0w6cGH2cEiuwfdHr/fbH
cmDKJ5MeJMPf4a+/nuFydGdo5YhZCZbuxBzmZnWHrHb/7d8Rdzmox3c4ppmeIK8B
SlYUwcIG46Ll6V87GiZsYu+uD44Ba3UH3jmGiip0I8xlZS3a+yK89LQPFhQgPe0=czer
-----END PGP SIGNATURE-----