7.22 How do things get from here to there?

From James Hofmeister of the Hewlett-Packard Expert Center, all about search orders for IP and HP addressing:

Q1: What is the search priority when using RESLVCNF and HOST files and NMMGR configurations?

A1: It depends on what services you are using. NS-SERVICES VT/DSCOPY/NFT/etc. or ARPA-SERVICES FTP/TELNET/ETC.?

Q2: What I have read is that when DNS servers are defined in the RESLVCNF file the HOSTS file is not accessed?

A2: False, sort of. When a RESLFCNF file points to a valid DNS Server and the DNS Server responds, the 3000 will NOT look at the HOSTS file. This is true if the response from the DNS Server is positive or if the response is negative (node name lookup reports unknown host), if any reply comes back from the DNS, the 3000 will NOT look at the HOSTS file. The 3000 will look at the HOSTS in only two cases:

The DNS Server has crashed (or is unreachable) and does not reply at all.

The RESLVCNF.NET.SYS file does not exist.

Warning! Do not configure bogus (99.99.99.99) entries in the RESLVCNF.NET.SYS, this will significantly degrade your name lookup search times. Are your users complaining it takes a long time to get connected to a system? Check to see if your DNS is responding.

Q3: What if I wanted to use a combination of the RESLVCNF and HOSTS files, can we set up the system to look first at the HOSTS file then the RESLVCNV file for domain names similar to a UNIX environment.

A3: No. The HP3000 does not support what is known in the UNIX environment as NSSWITCH (fallback) capabilities. See Enhancement Request SR 5003443176. The operation on the 3000 is similar to HP-UX version 9.x as described in the answer #2 above.

Q4: We want to rid the hard coded addresses assigned in NMMGR and utilize the DNS servers as well as, if possible, use the HOSTS file to override the DNS entries when testing is required.

A4: Many sites have eliminated NMMGR NSDIR entries and rely on the DNS Server pointed to on the HP3000 by RESLVCNF.NET.SYS and only fall back to HOSTS.NET.SYS when the DNS Server is down. We do not have a fall back mode for HOSTS.NET.SYS as I have described in Answer #2 and #3 above.

Q5: Can we have whatever name is found and resolved on the DNS server put in cache memory on the HP3000.

A5: No, this is not done on the 3000. As a mater of fact, the last time I investigated caching of the result of a DNS lookup, a cache was also not present/implemented on HP-UX. See Enhancement Request SR 4701259549.

Q6: The (default) search path is as follows > cache, probe, proxy, nsdir, reslvcnf (DNS), hosts.net, or falls off as "unresolvable"?

A6: Same as answer #1, No, It depends on what services you are using? NS-SERVICES such as VT/DSCOPY/NFT/etc. or ARPA-SERVICES such as FTP/TELNET/ETC.?

Q7: I had also thought that upon using a reslvcnf file, that hosts.net is not searched when a search on the DNS server has failed to produce a result.

A7: HOSTS.NET.SYS file will be used if the DNS Server is DOWN (or not network accessible) and it produces NO reply. Any reply from a DNS server will result in the HOSTS.NET.SYS file not being looked at. Same as answers #2 and #3 above.

Q8: I've heard that on UNIX machines, you can define the path to search in a local hosts file first, before searching DNS. Is this true?

A8: I understand it, HP-UX has NSSWITCH (fallback) which gives them additional flexibility in using the HOSTS file as a backup, but I am not totally aware of the specifics and all the functionality, so I will leave this answer open for input from others.

Q9: Can you change the priority in NMMGR with cache, probe, and proxy?

A9: Yes, the priority can be changed as well as disabling cache, probe and proxy.

To wrap it all up:

A. NS-SERVICES Name Lookup

Cache - configured/enabled in NMMGR, learned as a result of a probe lookup or loaded as a static name from NSDIR.

Probe - configured/enabled in NMMGR, probe packet is sent on the network and the host that matches the request replies. The result is cached.

Proxy - configured/enabled in NMMGR, probe proxy packet is sent on the network and a host configured for probe proxy reply replies. The result is cached.

ARPA-SERVICES Name Lookup

RESLVCNF - Configured in RESLVCNF.NET.SYS, which points (by IP address) to a DNS Server. A DNS request is sent out to the DNS Server and it replies. The result is not cached.

HOSTS - Configured in HOSTS.NET.SYS, which is only accessed if 1. a DNS request is not replied to by a DNS Server or 2. a RESLVCNF files does not exist. The result is not cached.

And now the million-dollar question everyone is asking?

Q1: What is the search priority when using RESLVCNF and HOST files and NMMGR configurations?

A1: It depends on what services you are using. NS-SERVICES such as VT/DSCOPY/NFT/etc. or ARPA-SERVICES such as FTP/TELNET/etc.?

The NS-SERVICES VT/DSCOPY/NFT/etc., as you might guess, use "NS-SERVICES Name Lookup" first and then failing that use "ARPA-SERVICES Name Lookup". One note: if you pass a 4 part or greater node name "james.atl.hp.com" at "NS-SERVICES Name Lookup", it automatically bails out and jumps to the "ARPA-SERVICES Name Lookup".

ARPA-SERVICES FTP/TELNET/etc., as you might guess, use "ARPA-SERVICES Name Lookup" first and then failing that then use "NS-SERVICES Name Lookup".

If you are ever working with our friends at the HP-Response Center and you tell them what is not working, they may start asking you what is working or they may be testing other services or tools. You now know they are trying to identify if the "ARPA-SERVICES Name Lookup" works or if the "NS-SERVICES Name Lookup" works or if none of the above are working. Just another of the tools used to isolate a failure in establishing a connection.