Listing all RRs from a named process..
Kevin Darcy
kcd at daimlerchrysler.com
Thu Aug 25 23:25:22 UTC 2005
blrmaani wrote:
>Dear all,
>
>I would like to get list of resource records from named process.
>I tried 3 approaches mentioned below and I am not sure what is the
>correct approach to list resource records from a named process?
>
>
>Approach#1: rndc dumpdb
>
>rndc dumpdb command dumps the contents
>of the cache. Is this not same as the contents of the
>named process? I noticed that this command is *not* dumping
>any new resource records I add using nsupdate. Is something
>wrong with this command?
>
>Approach#2: dig
>
>I tried "dig @mynamesever myzone.xxx AXFR" command. From syslog
>output, I noticed that this command initiates a ZONE TRANSFER.
>Does it mean that this will cause some overhead on the master
>and the slaves listening on that master?
>
>Approach#3: nslookup
>
>I also tried the following:
># nslookup
>
>
>>server mynameserver
>>set domain=myzone.xxx
>>ls -t ANY myzone.xxx
>>
>>
>
>I did notice that this lists all the resource records in
>specified zone but it initiates a ZONE Transfer ( syslog output
>says that ). Does the zone transfer cause any overhead on
>the master and all listening slaves?
>
>What is the correct approach to list RRs from a named
>process for a given zone?
>
What exactly are you trying to accomplish here? Authoritative data is
different from the cache. "rndc dumpdb" gives you cache information; you
shouldn't expect to see nsupdate results there, since nsupdates are only
done to authoritative data. A zone transfer will give you the
authoritative data for a particular zone. But you seem to be worried
about overhead. Why? Is this something you'd only run once in a while to
get a snapshot for troubleshooting, or something you'd run continuously?
If you care about the memory usage of your nameserver process, then look
at the memory usage of your nameserver process directly; looking at the
RRs the nameserver is managing is kind of a perverse and warped way of
looking at memory usage. Instead, try using a process monitoring tool,
or just plain old "ps" (assuming you are running on a Unix or Linux-type
system).
- Kevin
More information about the bind-users
mailing list