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

[serfsmith at gmail.com]

On Thursday, February 18, 2016 at 5:18:32 PM UTC+2, Stephen Hoffman wrote:

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

Nope, won't work; once again, TELNET insists on trying to connect to the same server (i.e., to the IP address assigned to IE0 in this case) to do reverse lookups; here's the TCPDUMP when trying to connect:

$ tcpdump port 53
tcpdump: Filtering in user process
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on IE0, link-type EN10MB (Ethernet), capture size 96 bytes
19:17:02.828522 IP ALEX04.58760 > ALEX04.53:  23289+ PTR? 170.141.6.196.in-addr.
arpa. (44)
19:17:07.830432 IP ALEX04.58761 > ALEX04.53:  23289+ PTR? 170.141.6.196.in-addr.
arpa. (44)
19:17:12.831342 IP ALEX04.58760 > ALEX04.53:  23289+ PTR? 170.141.6.196.in-addr.
arpa. (44)
19:17:17.832252 IP ALEX04.58761 > ALEX04.53:  23289+ PTR? 170.141.6.196.in-addr.
arpa. (44)

As you can see, I've given up on obfuscating things.

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

I've considered that - horrible kludge though.

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

Nope, as above ... that's the problem.  Humm... could do a UDP NAT on port 53 though ... not sure if VMS supports that; once again, horrible kludge.

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

An entirely reasonable expectation, yes.

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

I'm beginning to suspect that the TCPIP installation didn't go quite correctly.