I would like to collect information about how log it took to get a response and a TTL. Could it be done without running tcpdump?

  • Can you elaborate a little more? We need to know about the context. Is this between a client and a server? A caching server and an upstream authoritative server? – Andrew B Jan 26 '13 at 23:53
  • Its between a caching proxy (where I want to run bind9/unbound/dnsmasq) and an ISP' DNS server. – user156233 Jan 29 '13 at 2:47
  • Its between a caching proxy (where I want to run bind9/unbound/dnsmasq) and an ISP' DNS server. A proxy gets HTTP requests from a clients and does DNS requests to the ISP' DNS server (DNS forwarding). I would like to log a TTL value (which is included in a DNS response packet) and a dns.time (speaking in Wireshark' terms) to collect a DNS statistics. I suppose it could be possible to log a TTL with some debug tricks, but for dns.time I need to patch, right? – user156233 Jan 29 '13 at 3:03

I'm going to assume you are talking about servicing recursive queries because you are asking for the TTL, too. Queries that are served from authoritative data (as opposed to served from a recursive server's cache) are always going to have whatever TTL is set for that resource record in the zone data.

Do you want to get this information for every query that your recursive server processes? If so, you're probably out of luck, as the server really has no idea how much time has elapsed before it receives a query so it's not a great place to measure end-to-end query time.

Or perhaps you just want to "ping" your server periodically and see how long the server takes to respond to a query? The latter is easily accomplished from a client machine with tools like "dig", which report the time taken by the query and the TTL of any resource records returned.

You need to explain what you're trying to do more clearly, and I would recommend you explain not just how you are trying to measure whatever you are trying to measure but what problem you are trying to solve by collecting this data, as there may be a better way to go about it.

  • we have a few proxies in our network. Lately there were a couple of support tickets about the surfing performance via the proxy, which have been caused by slow DNS responses and have been resolved by changing the DNS settings. Thereafter I've started to pay attention on DNS and ran namebench (code.google.com/p/namebench). In addition I've ran a "tcpdump -pnns0 port 53 -w dns.pcap" for a few days and analyzed it with Wireshark and exported the data with a tshark to a plain text which was then processed with sort/uniq etc. to get a various "top" reports. (see the other comment to cont.) – user156233 Jan 29 '13 at 2:37
  • the DNS responses came from our ISP DNS server, we cannot do a recursion because of the firewall rule which allow port 53 to one or two DNS servers. Yes, I would like to collect stats for every query. There are about 1-2 mio DNS queries a day. I want to skip tcpdump/tshark step to collect the DNS stats and run a simple cron script periodically (which is an easy part). – user156233 Jan 29 '13 at 3:08
  • Is there a reason why you're running your servers as forwarders rather than just operating them as caching-only recursive servers? – Michael McNally Jan 29 '13 at 3:35
  • good question; originally I was able to configure the company's internal DNS server (which is slow) only. I'm happy that I am can set an ISP DNS as a forwarder now. Actually in my first test with a namebench I've got a pretty quick response from Google public DNS Are there any significant (performance) advantages to do recursive queries instead to use fast forwarders, which were choosed by running a benchmark. In my test many of authoritative NS servers were really slow. The statistics which I plan to collect can lead to opening of 53 port completely, if I can reason it. – user156233 Jan 29 '13 at 3:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.