Telnet connections are slow

[Trace Trembath]

I am running OpenVMS 7.2-1 and TCP/IP Services V5.1 ECO3. My VMS machine is running as a secondary DNS. DNS database transfers from the master are okay. However, when I set the system to use itself as the DNS resolver, then telnets to the system from other systems are very slow.

When I change the resolver to be the primary/master DNS system then telnets work perfectly and there is no delay.

The command I'm using to switch between resolvers is:

$tcpip set name/noserver=127.0.0.1/system
$tcpip set name/server=192.70.176.91/system

I would think having the resolver look at a local copy of the DNS data would be faster.

Thanks for any and all thoughts.

Regards,
Trace

[Martin P.J. Zinser]

Hello Trace,

the delay with telnet you describe typically happens when a name actually can not be resolved. How does tcpip show name look like after you issued the commands given? Are you able to resolve the names/ip-addresses of the systems connecting via telnet.

Also the help states pretty clearly not to use /noserver and /system together, maybe you need to adjust your commands.

Greetings, Martin

[Mobeen_1]

Hello Trace,
Could you provide some additional information on the following

1. When you set your sec DNS server to resolve itself, is it only the INCOMING telnet sessions that are slow or also outgoing?

2. Try adding the host name in the local host file (name file) and see how the system behaves.

Item#2 above will help us to determine where the problem is.

I am a TCPware man, but i am sure its not very different from DEC TCP/IP.

regards
Mobeen

[Trace Trembath]

I didn't notice that help says not to use /noserver with /system under the set name command. However, I don't see how I'm going to switch from one resolver to the other with out using that combination.

Telnets to external systems from the "bad" one work find. It's just telnets TO the "bad" system that are slow.

I added an external host to the "bad" systems local host table, but telnets from that external host back to the "bad" host were still slow.

I ripped out the DB files from the sys$specific:[tcpip$bind] directory on the bad host and restarted the BIND process. It correctly downloaded new files from the master. My problem still did not go away.

$tcpip show host/external_host_name
and
$tcpip show host/external_host_ip_address

commands work perfectly fine on the "bad" host.

Thanks again for any and all responses and thoughts.

Regards,
Trace

[Trace Trembath]

Problem resolved! :-)

There was a typo in the BIND configuration file on the "bad" system. We comment out the reference to the "." zone in our configuration because we don't want the resolver to go to the internet for name resolutions. I copied a configuration file from a good system to the bad system and everything is working fine now.

Thanks everyone for your help!

Regards,
Trace