Home / server / Questions / 195326
Accepted
Daniel C. Sobral
Asked: 2010-10-28 05:27:21 +0800 CST

Reverse DNS lookup takes 5 seconds to give up

  • 772

I have a Debian 2.6.26-2-xen-amd64 system which takes 5 seconds between the second and third failed reverse DNS lookup. All (most?) other similar systems here do the three lookups with little wait between them.

I have tried to figure out what might be causing the difference, but, so far, I have been unable to do so. What might it be?

EDIT

Though I have observed the problem when logging to the machine with sshd, knowing slowness there is usually a problem with reverse dns, I have tested it using host. This is being provided by the package host, version 20000331-9.

Here's the tcpdump output of the test on two machines.

Host with delay:

11:47:58.883885 IP 192.168.20.127.48797 > 172.16.1.1.53: 13275+ PTR? 30.4.16.172.in-addr.arpa. (42)
11:47:58.884258 IP 172.16.1.1.53 > 192.168.20.127.48797: 13275 ServFail 0/0/0 (42)
11:47:58.884326 IP 192.168.20.127.34876 > 172.16.1.1.53: 13275+ PTR? 30.4.16.172.in-addr.arpa. (42)
11:47:58.884804 IP 172.16.1.1.53 > 192.168.20.127.34876: 13275 ServFail 0/0/0 (42)
11:48:03.892639 IP 192.168.20.127.43032 > 172.16.1.1.53: 21337+ PTR? 30.4.16.172.in-addr.arpa. (42)
11:48:03.893282 IP 172.16.1.1.53 > 192.168.20.127.43032: 21337 ServFail 0/0/0 (42)

Host without delay:

11:15:58.222147 IP 192.168.21.26.50046 > 172.16.1.1.53: 2040+ PTR? 30.4.16.172.in-addr.arpa. (42)
11:15:58.222611 IP 172.16.1.1.53 > 192.168.21.26.50046: 2040 ServFail 0/0/0 (42)
11:15:58.222718 IP 192.168.21.26.51288 > 172.16.1.1.53: 2040+ PTR? 30.4.16.172.in-addr.arpa. (42)
11:15:58.223102 IP 172.16.1.1.53 > 192.168.21.26.51288: 2040 ServFail 0/0/0 (42)
11:15:58.223197 IP 192.168.21.26.36545 > 172.16.1.1.53: 20425+ PTR? 30.4.16.172.in-addr.arpa. (42)
11:15:58.223550 IP 172.16.1.1.53 > 192.168.21.26.36545: 20425 ServFail 0/0/0 (42)
linux domain-name-system debian reverse-dns

2 Answers

  1. Best Answer

    Ok, the problem was the libnss-mdns package, which got installed as a recommended package with Java.

    • 1

  2. ServFail is an abnormal situation. Maybe later versions of BIND or the resolver library implement a more aggressive congestion avoidance strategy for ServFail? Are the two servers running different versions of BIND or the resolver library?

    Since ServFail is unusual, indicating some DNS servers are not responding, a delay sending the third attempt shouldn't normally be causing you any additional issues. In my experience, loss of DNS service usually results in multi-second delays.

    I suspect if you were getting, say, NXDOMAIN responses, you probably wouldn't see delays of many seconds.

    If the DNS servers for the reverse-domain of the address in question were contactable and responsive, this wouldn't be an issue?

    • 0