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

[Stephen Hoffman]

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?  Where?  With WHAT commands?

> 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?  (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.)

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

I am well aware of the advantages of DHCP.

I would NOT use DHCP on VMS.

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.

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

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

>> $ @sys$manager:tcpip$config
>> 
>> Checking TCP/IP Services for OpenVMS configuration database files.
>> 
>> ...
>> 
>> HP TCP/IP Services for OpenVMS Configuration Menu
>> 
>> Configuration options:
>> 
>> 1  -  Core environment
>> 2  -  Client components
>> 3  -  Server components
>> 4  -  Optional components
>> 
>> 5  -  Shutdown HP TCP/IP Services for OpenVMS
>> 6  -  Startup HP TCP/IP Services for OpenVMS
>> 7  -  Run tests
>> 
>> A  -  Configure options 1 - 4
>> [E] -  Exit configuration procedure
>> 
>> Enter configuration option:
>> 
>> 
>>>> 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.
>> 
>> Re-invoke the core services configuration sequence within the 
>> TCPIP$CONFIG tool.
>> 
>>>> SHOW HOST /LOCAL will show any locally-added host names.
>>> 
>>> $ SHOW HOST /LOCAL
>>> 
>>> %DCL-W-IVKEYW, unrecognized keyword - check validity and spelling
>> 
>> TCPIP> SHOW HOST /LOCAL
> 
>   LOCAL database
> 
> Host address     Hostname
> 127.0.0.1        LOCALHOST, localhost
> aa.bb.cc.dd      MYNODE.EXAMPLE.COM

That's an expected minimal configuration for TCP/IP Services.

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

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

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.

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

The developers tend to spend a whole lot of time on the emulator and 
the emulation and the testing, and the virtual networking and the UI 
and the host OS integration tend to get short shrift.  Some are better 
than others here.  The simh emulation can and does work, preferably 
with the latest bits from github and one of the expected configurations.

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

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.

> 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?  (Um, that's not a very promising statement when we're trying 
to troubleshoot errors.)  Try turning DHCP off within OpenVMS and 
assigning a static address to the OpenVMS box, with a static DNS server 
address (8.8.8.8 and 8.8.4.4 will work, for non-local stuff), and the 
address of your gateway.   Sure, add an entry in the DHCP server for 
the VMS box, but don't configure OpenVMS to ask for a DHCP address.  
Various servers don't like DHCP addresses, and OpenVMS is among these.

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

-- 
Pure Personal Opinion | HoffmanLabs LLC