2 Answers
2

If you have doubts in Slow response in reverse query then you can try either of the methods below to rectify the same:

If possible then disable reverse lookup in your application and see the difference

You can use Name Service Cache Daemon (nscd) which also caches PTR but there is some security issue as :

The Name Service Cache Daemon (nscd) has a default behavior that
does not allow applications to validate DNS "PTR" records against
"A" records.

In particular, nscd caches a request for a "PTR" record, and when a
request comes later for the "A" record, nscd simply divulges the
information from the cached "PTR" record, instead of querying the
authoritative DNS for the "A" record.

These are the lines from given links Important! If you are running a service that relies on forward/reverse lookup checks, don't do this!.
–
devnullFeb 26 '13 at 5:02

But firstly I want to make a table of time consumed in Reverse DNS Lookup. Tell me how can I do this first. I want to analyse the delay first. Solve my problem. If this is the reason then I can apply your methods.
–
devnullFeb 26 '13 at 5:09

Some of this depends on which stub resolver is in use. You may also be having problems with IPv6, e.g. if IPv6 AAAA records are returned but there is no IPv6 connectivity.

Assuming the software (erm, rsh? really? this answer isn't rsh specific) is using the system resolver (like ping), and not its own implementation (like dig or host), then you can use getent to see what might be happening:

If you have wireshark and root access, you can watch DNS requests on the wire:

# tshark -w dns.cap "port 53"
# tshark -V -ta -n -r dns.cap

(The -V option is overly verbose, however it hasn't occurred to the developers to put timestamps in the protocol dissection output with -O dns. Maybe that's fixed in a newer version.)

Even if you're not using nscd right now, you can easily see some of what's happening if you start it interactively with the option -dd or -ddd. Note that nscd only caches host (A/AAAA) records, so PTR records will end up negatively cached with a short (default 20s) lifetime.

The glibc resolver (and others) supports "options debug" in /etc/resolv.conf as well as the environment variable RES_OPTIONS which can be used to enable debug. Sadly, this useful functionality requires that DEBUG is enabled when glibc is built, so it's rather unlikely you'll be able to use it...

For heavy lifting, the best candidate is ltrace, this lets you trace and timestamp library calls, just like the way strace can trace system calls, e.g. gethostbyname() or gethostbyaddr(). The downside: with the many layers of indirection offered by nsswitch, you'll probably get lost in the voluminous output. A simple run on telnet got me 3000+ lines of output, within which is buried two calls to gethostbyname().

It's a little harder to understand what's going on because it doesn't output human readable IP addresses (0x69187d4a = 105,24,125,74 -> 74.125.24.105). It is probably the best method to track down local problems though, as you can see all the calls through NSS.

I used these amendments in my ~/.ltrace.conf for the above, it may require some further hacking: