Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am working on a project in which one master communicates with numbers of slaves. For that it has to make connection with hosts in network. But sometimes it hangs.

I think that the reason behind is extra time consumption during Reverse DNS Lookup. So please tell me any command or script which checks or makes the list for the Reverse DNS Lookup time.

EDIT no. 1

Tell also that where can I add that command in rsh source code so that I got a list of time consumed by every request, whenever it connects to other hosts.

So that I can find the reason behind the hanging of server.

share|improve this question
Yes it does a reverse dns lookup. – devsda Feb 22 '13 at 13:42
Can you tell where can I add this command in rsh source code, so that I can check, Reverse DNS lookup time, or, if I am wrong then correct me. Please. – devsda Feb 24 '13 at 7:07
question edited... – devsda Feb 25 '13 at 4:18
Actually my task is the same that I Edited. But my question is the approach that I thought. – devsda Feb 25 '13 at 12:42

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:

$ time getent ahostsv4 www.google.com
$ time getent ahostsv6 www.google.com

The above will perform a forward and reverse lookup (though you cannot force getent to look up a reverse PTR or other types, it only cares about A/AAAA records).

There are a couple of handy scripts in this answer to http://serverfault.com/questions/7056/whats-the-reverse-dns-command-line-utility , these allow you to do forward a reverse lookups (IPv4 only) like getent hosts, but in perl so you can tinker with them.

The above two possibilities use your system resolver, including all the swings and roundabouts involved in nsswitch, so they should behave the way most applications do.

Don't forget to test on the client and the server, either or both will do reverse look ups.

You can also check your local resolvers one by one:

$ while read opt p1 ;  do 
    [ "$opt" = "nameserver" ] && dig @$p1 www.google.com +short +identify; 
done < /etc/resolv.conf

and to check reverse DNS:

$ dig www.google.com +short | xargs -n1 -i dig -x {} PTR +short +identify

To further debug this, you will need to check:

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().

$ ltrace -ttT -e "getaddr*+gethost*+getname*" getent ahosts www.google.com

13:42:06.118718 getent->getaddrinfo("www.google.com", nil, { 0x2a, 0, 0, 0, 0, nil, 
nil, nil }, { 0x2a, 0x2, 0x3, 0, 16, { 2, 0, { 0x69187d4a } }, "www.google.com", { 
0x2a, 0x2, 0x2, 0x11, 16, { 2, 0, { 0x93187d4a } }, nil, { 0x2a, 0x2, 0x3, 0, 16, {
2, 0, { 0x67187d4a } }, nil, { 0x2a, 0x2, 0x2, 0x11, 16, { 2, 0, { 0x68187d4a } }, 
nil, ... } } } }) = 0 <0.042561>

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

typedef size_t = int;
typedef sockaddr = struct(short, short, in_addr);
typedef addrinfo = struct;
typedef addrinfo = struct(hex(int), hex(int), hex(int), hex(int), size_t, sockaddr*, string, addrinfo *);

int getaddrinfo(string, string, addrinfo *, +addrinfo**);
int getnameinfo(sockaddr*, uint, +string, +uint, +string, +uint, uint);
share|improve this answer

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

  1. If possible then disable reverse lookup in your application and see the difference
  2. 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.

Reference Link

share|improve this answer
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!. – devsda Feb 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. – devsda Feb 26 '13 at 5:09
The nscd/PTR issue is a very old bug, fixed very a long time ago... – mr.spuratic Oct 7 '14 at 14:07

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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