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

[Stephen Hoffman]

On 2016-02-18 06:49:59 +0000, serfsmith at gmail.com said:

> 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:

Forward ain't the direction that matters here, of course.


>> 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.

Would take a few minutes to fire up a private DNS server on a plug or 
some old x86 box or on a Mac with Server.app loaded, aim OpenVMS at 
that, and that won't effect the rest of the environment at all.

Probably also brute-force it by entering your entire DHCP range into 
TCPIP> SET HOST, too.   OpenVMS won't ask the DNS server, if it has the 
equivalent in the OpenVMS version of an /etc/hosts entry.


> 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.

http://nukeitfromorbit.com

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

You're working around a bug in your local infrastructure, via HPE.

> 
>> 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.

Or some other local box that can be made authoritative, and used by 
just the VMS server.

> 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.

We've generally gotten by with competently configured DNS.

I'm surprised connections aren't tossing errors all over the place, but 
then that's probably also why you're still using telnet.



-- 
Pure Personal Opinion | HoffmanLabs LLC