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

[serfsmith at gmail.com]

On Wednesday, February 17, 2016 at 9:19:21 PM UTC+2, Stephen Hoffman wrote:
> On 2016-02-17 18:40:23 +0000, serfsmith at gmail.com said:
> 
> > Yes Stephen, I included the ping -4 bit merely for context (to show my 
> > workstation IP address), I wanted to illustrate the fact that our 
> > DNS/DHCP setup presently doesn't resolve reverse queries.  The bit that 
> > actually shows this is the nslookup invocation with contextual DNS 
> > record type selection (PTR) and query with my IP address.
> 
> Based on what's shown, your DNS doesn't resolve forward names quite 
> right, either.     Or there's been a poor obfuscation.    example.org, 
> example.net and example.com are available for that use.

The obfuscation for the purposes of privacy has confused the whole issue (and was bound to fail in any case) - all of this is internal to the organisation, so external addresses aren't relevant.  In any case, forward lookups are working just fine:

C:\Users\smithe>ping -4 example.net

Pinging example.net [93.184.216.34] with 32 bytes of data:

> 
> Once DNS is hosed, pretty much everything else is hosed on a modern 
> server, too.

Yes - be that as it may; in certain cases, on our internal network, reverse lookups do not work correctly.  The relevant people have been notified, and work is in progress to correct the situation.

> 
> OpenVMS isn't particularly modern, so it'll tend to work where newer 
> systems will throw (usually) security-related errors.
> 
> > The point is: the fact that dns.acme.org (if you look at the output 
> > you'll see that my attempt to obfuscate all *real* server names 
> > throughout this thread was foiled there) doesn't resolve reverse 
> > queries properly is a red herring; I've isolated the problem to TELNET 
> > (apparently) not invoking the official means of resolving DNS records, 
> > that is: NAME_SERVICE.
> 
> So either add the reverse translations via $GENERATE or otherwise, or 
> ask HPE for a way to shut off reverse translations within the telnet 
> server.   Or switch to ssh, as PuTTY can deal with that.

The $GENERATE option is out of my control (I don't admin the DNS server); as I said further up, the relevant people have been notified and are "working on it" (estimated time of completion - next month).  Also, I specifically *don't* want to complicate the issue by running BIND on the OpenVMS server just to get around this problem.

In respect of SSH: the problem is that the bespoke application that runs on OpenVMS emits "custom" terminal escape codes, for-which (hold your breath) a terminal emulator has been customised to understand.  Said customised terminal emulator does not support SSH.

Which leaves ... contact HPE.  I was hoping that I wouldn't have to resort to that.

> 
> Given the inherent latency through HPE Support, establishing 
> authoritative reverse translations will probably be more expedient.

Only if I'm willing to run the BIND server on the OpenVMS server, which I'm not.

The most expedient option seems to be: switch off the BIND resolver and just use IP addresses, which is what everyone apparently has gotten by with for the last three decades.