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

[serfsmith at gmail.com]

On Wednesday, February 17, 2016 at 3:11:06 PM UTC+2, Stephen Hoffman wrote:
> On 2016-02-17 11:35:26 +0000, serfsmith at gmail.com said:
> 
> > The problem being that these are dynamic DNS entries, updated by the 
> > local DHCP facility.
> 
> $GENERATE entries for the entire DHCP pool(s).   ISPs don't enter a 
> gazillion reverse DNS entries by hand, after all.
> 
> > I have confirmed that putting an entry for my workstation IP in the 
> > local database (ala SET HOST) makes the delay go away.  All works until 
> > my IP changes, of course.
> 
> So either your DHCP server is not updating your DNS server with (at 
> least) the reverse entries (and possibly not the forward entries), or 
> your DNS server is not responding appropriately with the DHCP update or 
> to the queries, or your DNS server is not authoritative with the 
> reverse zone.   Given that adding one entry manually works, then the 
> latter two cases are probably not in play here, which means your DHCP 
> and DNS servers aren't quite chatting in the way that was intended.

Well no ... it *is* true that the DNS/DHCP servers are not correctly configured at present to provide a correct answer to PTR queries (as shown below from my workstation):

C:\Users\smithe>hostname
2744-b46c

C:\Users\smithe>ping -4 2744-b46c

Pinging 2744-b46c.acme.org [192.168.55.2] with 32 bytes of data:
Reply from 192.168.55.2: bytes=32 time<1ms TTL=128
Reply from 192.168.55.2: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.55.2:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
Control-C
^C
C:\Users\smithe>nslookup
Default Server:  dns.acme.org
Address:  172.19.10.148

> set type=ptr
> 192.168.55.2
Server:  dns.svc.alexanderforbes.co.za
Address:  172.19.10.148

*** dns.svc.alexanderforbes.co.za can't find 2.55.168.192.in-addr.arpa.: Non-exi
stent domain

*However*, I have confirmed that our org DNS/DHCP isn't at fault here, this by doing a "TCPDUMP port 53" when trying to connect to the VMS server:

$ tcpip set name_service/system/enable
$ tcpdump -n 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

< ... then I PuTTY to the server again ... >

16:27:41.858961 IP 172.18.1.39.58755 > 172.18.1.39.53:  38441+ PTR? 209.132.28.1
72.in-addr.arpa. (45)
16:27:46.859856 IP 172.18.1.39.58756 > 172.18.1.39.53:  38441+ PTR? 209.132.28.1
72.in-addr.arpa. (45)
16:27:51.860752 IP 172.18.1.39.58755 > 172.18.1.39.53:  38441+ PTR? 209.132.28.1
72.in-addr.arpa. (45)
16:27:56.861648 IP 172.18.1.39.58756 > 172.18.1.39.53:  38441+ PTR? 209.132.28.1
72.in-addr.arpa. (45)

So clearly, despite NAME_SERVICE settings pointing to something else, the telnet service insists on pointing to itself to do the lookup - no fixing of the org DNS/DHCP is going to help here.
 
> 
> If you have support, ring up HPE.  Post some information on whatever 
> configuration fix or patch name that you get from them.

Yeah, we do, so good idea.

> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC