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

[Craig A. Berry]

On Monday, February 15, 2016 at 6:11:04 AM UTC-6, serf... at gmail.com wrote:
> On Monday, February 15, 2016 at 12:23:29 PM UTC+2, Jan-Erik Soderholm wrote:
> > Den 2016-02-15 kl. 10:20, skrev :
> > > 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?
> 
> Yes:
> 
> $ tcpip show name

What about TCPIP SHOW CONFIGURATION NAME, and did you use TCPIP SET CONFIGURATION NAME so that your database also reflects your volatile changes?  I wouldn't expect the omission to produce the symptoms you are seeing (which sound more like permanent changes that haven't taken effect yet than vice versa) but with TCP/IP Services superstition is sometimes in order.