[OT] Monitoring RR use/popularity

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. :slight_smile:

sven

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