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

serfsmith at gmail.com serfsmith at gmail.com
Wed Feb 17 06:52:43 EST 2016


On Monday, February 15, 2016 at 11:20:12 AM UTC+2, serf... at gmail.com wrote:
> 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?

An update:

I have confirmed that:

(1) The following steps don't make the problem go away:

1.1 Stop BIND resolver (TCPIP NAME_SERVICE/SYSTEM/DISABLE);
1.2 Disable TELNET (TCPIP DISABLE SERVICE TELNET);
1.3 Start BIND resolver (TCPIP NAME_SERVICE/SYSTEM/ENABLE);
1.4 Enable TELNET (TCPIP ENABLE SERVICE TELNET).

(2) The following steps don't make the problem go away:

1.1 Stop BIND resolver (TCPIP NAME_SERVICE/SYSTEM/DISABLE);
1.2 Shut TELNET down: SYS$STARTUP:TCPIP$TELNET_SHUTDOWN;
1.3 Start BIND resolver (TCPIP NAME_SERVICE/SYSTEM/ENABLE);
1.4 Start TELNET up: SYS$STARTUP:TCPIP$TELNET_STARTUP.





More information about the Info-vax mailing list