[Info-vax] Telnet DNS Problem (OpenVMS 8.4, Itanium)

[Jan-Erik Soderholm]

Den 2016-02-15 kl. 10:20, skrev serfsmith at gmail.com:
> We are experiencing a strange problem with our Telnet server.  Despite updating the system DNS resolver settings, when connecting to the Telnet server, it tries to do a reverse lookup on the client's source IP.
>
> For the sake of clarity, I'll set the scene by describing a series of observations and corrective actions:
>
> OBSERVATION: An existing VMS server did not have DNS resolution enabled (everyone had been working with IP's, presumably for the last couple of decades);
>
> CORRECTIVE ACTION: The BIND resolver was configured to point at the organisation DNS server and BIND resolution enabled:
>
> TCPIP SET HOST dns.acme.org /ADDRESS=192.168.0.99
> TCPIP SET NAME_SERVICE/SYSTEM/SERVER=(dns.acme.org)
> TCPIP SET NAME_SERVICE/ENABLE
>
> OBSERVATION: Telnet'ing to the server now resulted in a delay lasting over 15 seconds (compared to no delay before the resolver service was enabled)
>
> SUSPICION: Something related to a reverse lookup of the client IP was causing the delay;
>
> OBSERVATION: Upon dumping network traffic (TCPDUMP port 53) on the server whilst attempting to connect via Telnet from a workstation revealed that the server was indeed trying to look up a PTR record, but was trying to query *itself* in order to do so.  All we're trying to do here is enable DNS resolution, that is, a BIND server is *not* running on the OpenVMS server; hence the delay due to not being able to connect.  Multiple lookup retries were observed.  Apparently the Telnet server had not picked up the changes made to the system-wide DNS resolution configuration.
>
> NOTE: Restarting the Telnet server is difficult since it's off-site.  In any case, a reasonable expectation would be that one does not need to restart the Telnet service in order for changes in resolver settings to be picked up.
>
> OBSERVATION: RESOLV.CONF has not been set up:
>
> $ dir tcpip$etc
>
> Directory SYS$SPECIFIC:[TCPIP$ETC]
>
> IPNODES.DAT;1       RESOLV_CONF.TEMPLATE;1                  SERVICES.DAT;1
> SYSCONFIGTAB.DAT;1  TCPIP$RNDC_CONF.TEMPLATE;1
>
> CORRECTIVE ACTION: Address logging was disabled on the Telnet service (TCPIP SET TELNET /LOG_OPTIONS=(NOADDR)) in an attempt to prevent PTR lookups - this did not help.
>
> OBSERVATION: DNS resolution is, in fact working with other applications since the same network traffic test was performed when connecting to the SSH server on the same box -- in this case a reverse lookup was performed to the correct DNS server.
>
> PRODUCT INFORMATION:
>
> $ product show prod *vms*
> ------------------------------------ ----------- ---------
> PRODUCT                              KIT TYPE    STATE
> ------------------------------------ ----------- ---------
> HP I64VMS OPENVMS V8.4               Platform    Installed
> HP I64VMS VMS V8.4                   Oper System Installed
> HP I64VMS VMSI18N V8.3               Full LP     Installed
> ------------------------------------ ----------- ---------
>
> $ product show prod *tcp*
> ------------------------------------ ----------- ---------
> PRODUCT                              KIT TYPE    STATE
> ------------------------------------ ----------- ---------
> HP I64VMS TCPIP V5.7-13ECO4          Full LP     Installed
> ------------------------------------ ----------- ---------
>
> The only test remaining then is to restart the Telnet server, but my gut feeling is this shouldn't be necessary.  So:
>
> 1. Is there somewhere else that Telnet can be configured to not attempt reverse lookups?
> 2. Why do changes to DNS resolution not get picked up by the Telnet service?
>
>

Does TCPIP SHOW NAME give reasonable display?

Does any name lookup work as expected?
Does "$ tcpip ping www.google.com" resolve to an IP address?
Does "$ tcpip sho host www.google.com" list the IPs?


Rearding restarting telnet, you can always put

@SYS$STARTUP:TCPIP$TELNET_SHUTDOWN
@SYS$STARTUP:TCPIP$TELNET_STARTUP

in a command file and submit it (and hold your breath... :-) ).

 > > OBSERVATION: RESOLV.CONF has not been set up:

I don't have that one either. Alpha 8.4 TCP 5.7 ECO3. Telnet
works fine with no delays.