reverse dns lookup issue

[Mel Burslan]

Well, I know my subject is not very clear, but I have the age old login prompt not appearing for 30 seconds problem when I telnet to this host.

My dns resolution is files first dns second

if I add the incoming host to the /etc/hosts file, prompt comes back immediately, so it is a reverse dns issue

when I come from a host, ip of which is not in hosts file, I get the login prompt about 30 seconds later.

funny thing is, when I lookup this hosts-non-existent host by nslookup, dns returns the ip address, in a snap, no delays at all.

I cleared the arp caches on both sides but still the same issue.

Can someone shed any light on this if possible. I am baffled.

[Patrick Wallek]

Do DNS lookups for both name and IP work?

# nslookup host
Should return IP

# nslookup I.P.add.ress
Should return appropriate hostname

If one works but the other doesn't then you are correct.

You need db's on your DNS server for both your domain and the IP addresses.

We have for example:

db.1.2
db.domain1
db.domain2
etc.
etc.

If this is the first machine with this problem, it may be that the name/IP was added in one place, but not another.

[Mel Burslan]

Patrick,

Thanks for the insight but both name and ip address lookups return the other instantaneously. So, the dns server configuration is quite all right.

As more detail to the issue, this all has started when we physically needed to relocate 2 of our 3 dns servers yesterday evening and this morning. We made the necessary modifications to our resolv.conf files to temporarily remove the server which was relocating and not going to be available, during this period, but now again all 3 of our servers up, the reverse lookup is not working right. And this is not on only one or two servers. This is, I am now noticing, anything that uses these dns servers. By the way, the dns servers needed to change IP address while relocating due to anal retentiveness of the network folks to add more spice to it.

My gut feeling is telling me, the ip address of the dns server is somehow chaced somewhere and never let go. We reboot a test server and it immediately start working fine after reboot.

Again, thanks for any help in advance.

[RAC_1]

How many servers you have in resolv.conf?? I think the first does not resolve/or fails and then second one does. That's where delay is from.

nslookup
server "first dns server"
ip_addr

does it work fast??, then do same for second dns server.

[Mel Burslan]

My first server returns the ip address or the server name depending which one you are requesting instantaneously. So do the other two. nslookup command is working fine. Whatever method telnetd and other customer applications are using to resolve the hostname/ip are having the problem with reverse dns lookup. I am under the impression, they are not accessing the dns server with its new ip address and still trying to use the pre-relocation ip address.

If I have a chance of rebooting this server, which I do not for almost another month or so, I know the issue will go away, bacause we tested another one with the same problem and succeded. I know it is clearing some sort of cache upon reboot but don't know exactly what and where.

As I have mentioned in my original post, I tried flushing the arp cache but it did not help.

One thing I am noticing, even after the delayed response by telnetd, the hostname does not get registered in the arp table. The arp table, after clearing it and numerous attempts from other hosts, only registers IP addresses as a result of arp -an command running.

Soemthing is not working right.

[RAC_1]

nsquery hosts "host_ip/name" "dns"

Which dns server resolves it??

[Mel Burslan]

# nsquery hosts admsvr dns

Searching dns for admsvr
Hostname: admsvr.domain.com
Aliases:
Address: w.x.y.z
Switch configuration: Terminates Search

the address returned is the correct address but there is no information which dns server resolved the address. Since the command returned immediately, I am under the impression that it is the first dns server who is responsible for resolution.

[Mel Burslan]

Looks like I found the resolution to this one. Obviously inetd was the responsible party. Even though we tried to run

inetd -c

to re-read the configuration, it did not help.

inetd -k

then

inetd -l

now the server is responding to requests as rapidly as expected.

Thanks to those who tried to help.

[rick jones]

The reason inetd -c did not help is simply that the -c option only has inetd re-read the inetd.conf file, it does not affect the server information cached by the resolver library. When you terminated the inetd and restarted it, it got a fresh copy of the resolv.conf information.

WRT nslookup, since it is a command rather than a daemon, it will always use the current information, although nslookup is somewhat "notorious" for not heeding it completely, hence the trend towards other utilities (dig et al)