[Info-vax] duplicated DNS domain name (was: Re: stupid network tricks)

[lists at openmailbox.org]

On Mon, 9 Mar 2015 12:35:37 -0400
Stephen Hoffman via Info-vax <info-vax at rbnsn.com> wrote:

> On 2015-03-09 15:58:47 +0000, <lists at openmailbox.org> said:
> 
> 
> > 
> >> 
> >>> 
> >>>>> My SHOW NET display seems to indicate a problem with the TCP/IP node
> >>>>> name on my system.
> >>> 
> >>> $ SHOW NET
> >>> 
> >>> Product:  DECNET      Node:  MYNODE         Address(es): 1.1
> >>> Product:  TCP/IP      Node:  MYNODE.EXAMPLE.COM.example.com
> >>> Address(es): aa.bb.cc.dd
> >> 
> >> Again, that's usually a not-FQDN entry somewhere in the configuration.
> > 
> > I'll try reentering it with a trailing .
> 
> Re-entering WHAT?

The fqdn

> Where?

in TCPIP$CONFIG, in option 1 where you specify the domain

> 
> > Ok, shutdown/restarted TCP/IP...that did nothing. No change in SHOW NET
> > output.
> 
> OK.  So SHOW NETWORK doesn't work.  Are there other problems?

No, it doesn't seem there are.

> (Welcome to fossil-grade software on fossil-grade hardware, and probably
> also without various patches.  Patch access was withdrawn some years ago, 
> which means hobbyists get to see all sorts of long-fixed problems, 
> particularly when working with configurations that are a dozen years 
> old, and variously older.   Since this is not a fatal error, the 
> easiest approach is to ignore this, and move on.)

I know but it looks stupid and other VMS systems have a nice looking node
name so why can't I ;-) 

> 
> >> That's not an expected configuration.  Looks like the baseline 
> >> configuration was skipped, or maybe — and I don't recommend using
> >> DHCP — DHCP went sideways somewhere.
> > 
> > I'm using DHCP because that's what I do with all the boxes on my LAN. 
> > It's easier to keep track of things by their MAC and assign them an 
> > orderly address on my lan. Going to direct config instead doesn't fix 
> > the problem.
> 
> I'd reconfigure with static IP and a correct configuration, and would 
> NOT use DHCP with VMS.

Ok, but I did that more than once and it doesn't help with this issue.

> I am well aware of the advantages of DHCP.
> 
> I would NOT use DHCP on VMS.

Noted.

> 
> Feel free to continue with your current approach, of course.  You're 
> here to learn what does not work, and so far that includes the 
> tutorial, the SHOW NETWORK command, the local IP configuration 
> displays, and probably DHCP.

Did somebody get up on the wrong side of the bed this morning?

> 
> >> You shuld see the domain and the servers listed.  Newer operating 
> >> systems can tend to adapt better to the network, or to configuration 
> >> details. With VMS, you get to tell it more of the details, and DHCP 
> >> isn't something that various folks have had the best outcome with.  
> >> That means performing at least the entire core network configuration 
> >> sequence in TCPIP$CONFIG tool, if that's not already been completed.  
> >> (I'd expect this is an issue, if not the issue — I'd expect to see a 
> >> domain listed in the above.)
> > 
> > I did go through TCPIP$CONFIG several times. I don't know if I did it 
> > correctly since I was following a tutorial I found on the net.
> 
> Did you go through this with a static configuration?

Yes.

> 
> >> If you have not already done so, minimally complete option 1 and the  
> >> core configuration, and it's generally better to use the A option and  
> >> get most of the stuff you'll immediately need sort-of working:
> > 
> > I have several times already so another time won't hurt. I just did and 
> > nothing changed in SHOW NET output.
> 
> So you've completed option 1 with a static (non-DHCP) configuration and 
> SHOW NETWORK is broken?

Yes.

>  Ah, well.  Probably broken command.  See if  SET NETWORK /REGISTER can
> dig you out of this.  But then again, OpenVMS VAX V7.3 is a fossil, and
> yours — like many folks running V7.3 now — probably under-patched.  I've
> hit something similar a long time ago
> <http://labs.hoffmanlabs.com/node/489>, and V7.3 is well older than that
> problem...

Thanks will try/take a look.

> >>>> TCPIP> sho config name
> >>> 
> >>> %TCPIP-E-CONFIGERROR, error processing configuration request
> >>> -TCPIP-E-NAMERROR, error processing name service request
> >>> -RMS-E-RNF, record not found
> >> 
> >> The baseline configuration with TCP/IP Services should have created a
> >> resolver.

I'm sure this is documented somewhere and when I find it I can see if the
tutorial screenshots were wrong or whatever.

> >>>> If you don't have local DNS (BIND server or otherwise), then the
> >>>> BIND resolver configuration — above — might be the source of the
> >>>> error.
> >>> 
> >>> There should be no BIND services.
> >> 
> >> Arguably, there should be DNS servers, but then OpenVMS is much more  
> >> willing to run insecurely than other servers, and unfortunately less  
> >> likely to notice the usual sorts of attacks.  Your call.
> > 
> > This system is behind a router/firewall. Right now it is not on the 
> > air. I can port forward if I want to let people telnet in, etc.
> > 
> > I am not sure how things should look on VMS but as far as the other OS 
> > I have they use /etc/resolv.conf which uses my router as a nameserver. 
> > Now that I think of it this seems suboptimal.
> 
> The resolver configuration is host-specific — I can't tell if you're 
> even running one, here — and /etc/hosts was a mess back in the early 
> 1980s, hence the use of DNS servers.  For your case — you like the 
> simplicity of DHCP, so you'll like what DNS brings, too — I'd again 
> recommend gettings local DNS services configured and going.

Ok, how do I do that?

> 
> > TCPIP> show host *
> > 
> > Host address     Hostname
> > 127.0.0.1        LOCALHOST, localhost
> > aa.bb.cc.dd      MYNODE.EXAMPLE.COM
> > %TCPIP-E-BIND_NOSERVERS, default servers are not available
> > %TCPIP-W-NORECORD, information not found
> > -TCPIP-E-BIND_NOSERVERS, default servers are not available
> > 
> > Is this normal when all you have is name resolution but are not serving 
> > services or did I just break something else by trying this?
> 
> You have no resolvers.  You've had no resolvers.  Which is part of why 
> I keep pointing you back at the configuration tool.  Or you can't reach 
> the servers — but the last resolver configuration you posted had 
> indicated no resolvers were configured, which means that was skipped, 
> or that there was a configuration corruption or odd network problem 
> somewhere in the local configuration.

I don't see any place to enter this or if I did see it I didn't recognize
it possibly from the terminology.

> This configuration is probably hosed — what was in that tutorial, I 
> don't know — and I'd likely nuke and pave this thing and start over.

All because of a bad SHOW NET display? And I thought I was a perfectionist.

> 
> > 
> >> It's also possible that the emulator is getting in the way.  The  
> >> virtual (emulated) networking implementation has been a longstanding  
> >> source of weird problems with OpenVMS, and the documentation
> >> associated with various of the emulators has had large gaps, or wasn't
> >> entirely current for the version of the emulator in use.
> > 
> > I really don't know.
> 
> That wasn't a question.   It's been my experience that various emulator 
> network documentation stinks, and that the virtual networking has been 
> a troublespot for folks.

I understood that but OpenVMS is more of an unknown to me than emulator
networking so I'm not ready to point the finger outside my very likely
incorrect setup of OpenVMS yet.

> > I was using a bridged network to run SIMH in user mode and it works 
> > fine. I wondered if that was causing wierd name resolution 
> > (duplication) because of the bridge so I brought it up again running as 
> > root and no network bridging and the SHOW NET output is unchanged. So 
> > that wasn't it.
> 
> OK.  I'd still check with the simh documentation and then with the simh 
> mailing list folks for the latest way to get simh configured and 
> working with whatever host system you're using here.

It works as far as I can tell. I can telnet from OpenVMS to the world
(after point BIND at my router) and ftp to the world, and I can ftp and
telnet into the box from my network. Haven't tried port forwarding from my
router but there is no reason it shouldn't work if it works locally. I
don't think this issue has to do with SIMH or host networking or anything
like that.

> Unfortunately, any simh docs that point to old simh resources and 
> locations and to a canonical simh source that predates the 
> <https://github.com/simh/simh> site is probably stale — Phil Wherry's 
> site is very old, for instance.  Mine's a few years out of date, and 
> has not been re-run to reflect the lastest simh, either.

Darn you guys! Imagine the cheek of leaving stale tutorials on the web for
unsuspecting VMS wanna-users to stumble over...

Wherry's tutorial is the one I have been using and other than this niggling
SHOW NET issue everything else seems to work.

> 
> > I believe I tried turning DHCP off before and it didn't change the SHOW 
> > NET display either. Just tried it now and doesn't help.
> 
> Believe?

Please see next sentence (and you quoted it above): "Just tried it now and
doesn't help." 

Confirming my belief for your reading pleasure. Bad day to give up caffeine?

> (Um, that's not a very promising statement when we're trying to
> troubleshoot errors.)  Try turning DHCP off within OpenVMS 

I can do that

> and assigning a static address to the OpenVMS box

From with the TCPIP$CONFIG or somewhere else?

>, with a static DNS server address (8.8.8.8 and 8.8.4.4 will work, for
>non-local stuff), 

Where is (are) the DNS server address(es) specified in OpenVMS?

> 
> > Again, the "problem" is not a functional issue, it's just that SHOW NET
> > doesn't look reasonable. Otherwise the actual network functionality,
> > given the box is not on the air and not in a DMZ, is fine i.e. telnet
> > and ftp in and out work.
> 
> Your resolver is also messed up.

How do I resolve it? No pun intended..

Thank you.

-- 
Please DO NOT COPY ME on mailing list replies. I read the mailing list.
RSA 4096 fingerprint 7940 3F02 16D3 AFEE F2F8  ACAA 557C 4B36 98E4 4D49