DNS change makes netstat hang

[dom kris]

Helo

we have to change our config on all our Tru64 servers since the DNS in our company has changed.
The config of /etc/resolv.conf was:
"
domain zzz.zzz.zzz
nameserver xxx.xxx.xxx.xxx
nameserver yyy.yyy.yyy.yyy
"

We have to put (config provided by DNS team):
"
nameserver xxx.xxx.xxx.xxx
search zzz.zzz.zz aaa.aaa.aa bbb.bb.bb ccc.ccc.cc
options allow special { \_ }
"

when we make this change then the command "nestat -ai" takes a long time to complete (it does not hang). Netstat -ain does not.
Note that the IP address from the old and the new DNS have changed.

Also, I have seen post in this group that their seems to be bug with the netstat -ia cmd but I don't think it's the same thing since with the old dns config it still works.
(the old DNS will be out of service soon so the new config must work)

This is most annoying problem since some of our apps now also show a long connection time for some operations.

I am not very familiar with the 'resolv.conf' file but when I look at the contents I cannot find an error and I don't see why it does not work.

Any ideas or suggestion that might me help to narrow down the problem (or solve it) would be greatly appreciated.

Kris

[Matt Palmer_2]

Hi Kris,

I had this issue and it turned out to be because the DNS was also put on a different subnet. I assume that you have checked stuff like this, but the way I had to get around was to change netmask on tu0,etc to compensate.

HTH

regards

Matt

[dom kris]

Thanks for the reply.
The DNS is indeed on a different subnet but I cannot change the subnet of my hosts.
However, it might give me an idea to narrow down the problem

[dom kris]

I am suspecting that since our DNS and the Tru64 hosts are not on the same subnet, the "netstat -ai" cmd is sending it's query to the DNS using the TCP protocol.
I did a tcpdump and saw that when I did a netstat -ai, 4 SYN packets were send to the DNS (on port 53). Our firewall however blocks TCP for DNS.
The previous DNS servers were on the same subnet as the Tru64 hosts.

I looked in the specs for the DNS proto and it seems that in normal operations the UDP protocol is used. When there are network errors, the DNS switches to TCP.

Can anybody confirm that the netstat cmd on Tru64 sometimes uses TCP? If so, is this a bug or a works-as-designed feature?

Kris

[dom kris]

Some more info, the "nestat -ai" cmd seems to work perfectly on Solaris and HP-UX with the same DNS config so this might indeed point to a bug in the "nestat" cmd on Tru64

[Ralf Puchner]

Please open a call within the HP support center - a forum is not the right place to solve such problems.

Maybe the reason could also a new RFC, Tru64 have more RFC implemented than other systems. But without an escalation there is no chance to get a suitable answer (and problem will not be solved).

[dom kris]

Hi Ralf,

I don't consider this a bug.
In fact the very first answer to my original post provided me with enough info to find the problem.
It is up our FW team to open the correct ports for DNS. Apparently they have only opened UDP.
And the RFC for DNS indeed also supports TCP.

Kd

[Ralf Puchner]

Kris,

why have you posted: "the netstat cmd seems to work perfectly on Solaris and HP-UX with the same DNS config so this might indeed point to a bug in the netstat cmd on Tru64"?

So if there are any doubts open a call, if not please update the thread...

[dom kris]

Afterwards, I did some more investigations and clearly showed that the netstat cmd was not bugged on Tru64. It just behaves differently then on Solaris and HP-UX.