HP OpenVMS Systems Documentation

Refer to your BIND server documentation for specific installation and configuration instructions. For a list of supported vendors, refer to the DECnet-Plus for OpenVMS Installation and Basic Configuration guide. Any properly constructed DNS/BIND nodename is supported by DECnet-Plus.

2.1.4 Namespace Management

DECnet-Plus includes an in-memory naming cache to improve performance of name and address resolution for all supported name services. Refer to the DECnet-Plus for OpenVMS Network Management guide for more information.

DECnet-Plus includes several features to ease namespace management including decnet_register (a namespace management tool), several Network Control Language (NCL) commands, and Common Trace Facility (CTF) support for monitoring node name and address resolution.

The decnet_register tool, an executable image located in SYS$SYSTEM:, centralizes and simplifies namespace management tasks by replacing functionality previously provided by both the decnet_dns_register and decnet_loc_register command procedures, which were located in SYS$MANAGER:. The decnet_register tool manages information in both the DECdns distributed name service and the Local namespace. The decnet_register manage command assists with setting up tasks for the DECdns Name Service. For example, it creates namespace directories and access groups, and enables autoregistration. Refer to the section on decnet_register in the DECnet-Plus for OpenVMS Network Management guide for more information.

2.2 Name Service Search Path

The name service search path applies systemwide and allows DECnet-Plus to search a list of name services in a predetermined order when looking up names or addressing information. The search path includes naming templates that tell DECnet-Plus how to interpret any abbreviated node names entered by users.

The ordering of the name services is very important. The first name service listed is the primary name service to use on the system. The primary name service is the first choice used when looking up names and addressing information. The remaining name services listed are the secondary name services used on the system.

The search path contains a list of name service keywords, each followed by a naming template that specifies a "defaulting rule" so users can enter shorter node names.

2.2.1 Configuring the Search Path Information

During DECnet-Plus configuration, the system administrator uses net$configure.com to set up one, two, or three name services on each node.

From the information provided by the system administrator, net$configure creates NET$SEARCHPATH_STARTUP.NCL, the standard search path NCL startup script which contains the name service search path information for the node.

The system administrator supplies one or two properly formatted DECnet-Plus node full names (in the case of the Local namespace and the DECdns distributed name service) and one fully qualified host name for DNS/BIND (if DNS/BIND is to be used on the node).

The first full name is specified in the proper format for the name service to be searched first. The second and third node names are properly formatted for the name services to be searched second and last.

If more than one name service is to be used on the node, the name services are searched in the order specified by the system administrator. For example, if the system administrator specifies Local, DECdns and Domain for the name services to use on the system, the Local namespace is searched before the DECdns namespace and DNS/BIND.

The following configuration example illustrates how to upgrade to DECnet-Plus Version 7.1 and use the new name service access features. Invoke net$configure.com and select Option 2 ("Change node name/namespace name"). The following prompt is displayed:

* Enter the directory services to use on the system [LOCAL,DECDNS,DOMAIN]:

At the prompt, you can choose the following name services for the system: LOCAL, DECDNS, and DOMAIN. If you enter more than one name service, separate each name with a comma.

For example, entering DECDNS,LOCAL,DOMAIN at the prompt, means the following:

• You want to use the name services DECdns, Local, and DNS/BIND.
• The primary name service is DECdns.
• The secondary name services are Local and DNS/BIND.

All members in a cluster should have identical naming search paths configured. This will help to ensure that nodes are recognized in the various services you have identified.

For example, if you receive mail on one node in the cluster, the "from" node name would be LOCAL:.NODE::SMITH. If you attempt to reply to this node from a node in the cluster that does not have Local configured, the system would indicate that there is no such node.

2.2.2 Displaying the Search Path Information

The system maintains two separate search paths:

• One search path supports forward translation or naming (node-name-to-address translation).

  $ mcr ncl show session control naming search path

• Another separate search path supports backtranslation (address-to-node-name translation).

  $ mcr ncl show session control backtranslation search path

DIGITAL recommends that you rerun net$configure.com to revise the standard search path NCL script (NET$SEARCHPATH_STARTUP.NCL) whenever it is necessary to reorder access to the name services on the node. To modify the standard search path startup script, run net$configure.com and use Option 2 ("Change node name/namespace name").

DIGITAL recommends that you allow net$configure.com (and in some cases net$startup.com) to create and use the standard NCL search path script (NET$SEARCHPATH_STARTUP.NCL).

However, if you need to make site-specific changes to your search path NCL script and do not want net$configure to overwrite these changes, you can create a site-specific search path NCL script by renaming the standard search path script (NET$SEARCHPATH_STARTUP.NCL) to NET$SEARCHPATH_LOCAL.NCL and making your changes to the new file.

For example, you might want to use the NCL set command described in Section 2.2.6 to create site-specific naming templates in NET$SEARCHPATH_LOCAL.NCL.

The net$configure.com and net$startup.com procedures check for the presence of a site-specific search path script (NET$SEARCHPATH_LOCAL.NCL) on the node. If NET$SEARCHPATH_LOCAL.NCL is present on the node, it is invoked instead of the standard script. A message similar to the following is displayed:

   **************************************************************
   A site-specific searchpath NCL script has been found on the
   system (SYS$SYSROOT:[SYSMGR]NET$SEARCHPATH_LOCAL.NCL;). The
   configuration procedure will use this script to set the
   searchpath instead of using the standard searchpath script
   that is created by NET$CONFIGURE (NET$SEARCHPATH_STARTUP.NCL).
   **************************************************************
%NET$CONFIGURE-I-SITESEARCHPATH, invoking site-specific searchpath
   NCL script found on system

The net$configure.com and net$startup.com procedures do not modify the site-specific search path NCL script; rather, they invoke the site-specific search path script as it currently exists. Therefore, when using a site-specific search path NCL script, you must modify it prior to invoking net$configure.com whenever you change any of the following name service information:

• The number of name services used on the node
• The order of the name services used on the node
• The specific name services used on the node

A search path can be used to simplify migration from one name service to another. The system administrator can create a search path designating the currently used name service as the primary name service (to be searched first) and the new name service as the secondary name service (to be searched second after the primary name service is searched).

As the secondary name service becomes populated with node and addressing information, the system administrator can rerun net$configure.com and select Option 2 to reverse the positions of the name services in the search path. This causes the current secondary service to become primary, to be searched first for node and addressing information.

2.2.6 Setting Up Naming Templates

In each template, the user-supplied portion of the name (usually the node's terminating name or rightmost simple name) is indicated with an asterisk (*). For example, if the DECdns template is: "ABCDE:.xyz.*" and a user supplies the name fin, then the full name ABCDE:.xyz.fin is looked up in DECdns namespace ABCDE.

You should specify only one asterisk per template. Only the first occurrence of an asterisk (*) in the template is substituted with the user-supplied name. Any additional asterisks are passed to the name service as part of the full name. When you specify a template without an asterisk, the template string is passed to the name service unchanged.

If the user-supplied name should be passed to the name service as entered by the user, the template should be specified as follows: "*".

DECnet-Plus provides an NCL set command for modifying the naming templates associated with the naming and backtranslation search paths. Do not use the NCL set command to modify aspects of the search path other than the naming templates. The following NET$SEARCHPATH_LOCAL.NCL script creates typical naming and backtranslation search paths. In this script ABCDE represents the DECdns namespace nickname. Your namespace nickname will appear in your NCL script:

SET NODE 0 SESSION CONTROL NAMING SEARCH PATH -
        ([DIRECTORY SERVICE = LOCAL, TEMPLATE = "*"], -
        [DIRECTORY SERVICE = LOCAL, TEMPLATE = "local:*"], -
        [DIRECTORY SERVICE = LOCAL, TEMPLATE = "LOCAL:.*"], -
        [DIRECTORY SERVICE = DECDNS, TEMPLATE = "*"], -
        [DIRECTORY SERVICE = DECDNS, TEMPLATE = "ABCDE:*"], -
        [DIRECTORY SERVICE = DECDNS, TEMPLATE = "ABCDE:.xyz.*"], -
        [DIRECTORY SERVICE = DECDNS_SYNONYM, TEMPLATE = "ABCDE:.DNA_NodeSynonym.*"
        ], -
        [DIRECTORY SERVICE = DOMAIN, TEMPLATE = "*"], -
        [DIRECTORY SERVICE = DOMAIN, TEMPLATE = "*.xyz.ABCDE.com"])
        SET NODE 0 SESSION CONTROL BACK SEARCH PATH -
        ([DIRECTORY SERVICE = LOCAL, TEMPLATE = ""], -
        [DIRECTORY SERVICE = DECDNS, TEMPLATE = "ABCDE:.DNA_BackTranslation"], -
        [DIRECTORY SERVICE = DOMAIN, TEMPLATE = ""])

Support for the Domain Name System (DNS/BIND) provides for the use of node synonyms. This allows for backward compatibility with older applications that cannot use long domain names.

There are two ways to configure node synonyms for use with DNS/BIND:

• By constructing an appropriate set of naming search path templates
• By defining local aliases

You can provide synonym support for entire domains by constructing an appropriate set of search path templates. Note that excessively long search paths (search paths with many entries) can increase the time it takes to look up node addresses. See Section 2.2 for general information on name service search paths.

Entering the following NCL command sets up a search path for a system using DNS/BIND:

 $ mcr ncl set session control naming search path =                 -
     { [Directory Service = Domain, Template = "*"],                -
       [Directory Service = Domain, Template = "*.finbar.com"],     -
       [Directory Service = Domain, Template = "*.abc.finbar.com"], -
       [Directory Service = Domain, Template = "*.xyz.finbar.com"]}

This NCL command results in the following DNS/BIND naming templates:

  *
  *.finbar.com
  *.abc.finbar.com
  *.xyz.finbar.com

When DECnet-Plus receives a connection from node koi.abc.finbar.com, it determines that koi is a usable synonym for this node, and DECnet-Plus will return the name koi to applications that require Phase IV style node names.

Using search path naming templates for synonym support allows the user to enter any of the following node names: koi, koi.abc, or koi.abc.finbar.com for node koi.

2.3.2 Local Aliases

Another way to define a node synonym for a particular node is by adding DNS/BIND alias names to the local host's database. The following is an example using DIGITAL TCP/IP Services for OpenVMS:

$ ucx set host koi.abc.finbar.com/address=aa.bb.cc.dd/alias=koi

DECnet-Plus will now return the node synonym koi to applications that require Phase IV-style node names.

2.4 Node Synonym Directories

The default node synonym directory is .DNA_NodeSynonym. If you plan to use a node synonym directory other than this default directory, you must define the logical name DECNET_MIGRATE_DIR_SYNONYM to the synonym directory name you want to use in sys$manager:net$logicals.com. (If you do not have a sys$manager:net$logicals.com procedure on your system, you can create one using sys$manager:net$logicals.template.) This makes the definition permanent (that is, it will not be deleted when you reboot the system).

2.4.1 Defining an Alternate Node Synonym Directory

Use the following format to define an alternate node synonym directory:

$ define decnet_migrate_dir_synonym "alt-directory-name"

If you use a synonym directory name that includes special characters or three or more dots, the system might produce an error. To avoid this, enclose the synonym directory name in quotes. For example:

$ define/system decnet_migrate_dir_synonym ".ch.noun.synonym"

The net$configure procedure needs this logical name to be defined at all times if you wish to use a synonym directory other than .DNA_NodeSynonym. Be sure to add this definition to net$logicals.com to ensure that the definition of the synonym directory will be permanent.

2.4.2 When to Use the Logical Name

You can use the logical name as described in Section 2.4.1 for either the BASIC or the ADVANCED configuration option.

You must define this logical name before you use any of following procedures:

• net$configure.com
• decnet_register.exe
• decnet_migrate.exe

If synonym lookup fails in the namespace, the software does one of the following:

• The startup procedure defines SYS$NODE, SYS$CLUSTER_NODE, or both to be the first six characters of the last simple name of the respective node full name or cluster full name.
• The configuration procedure defines SYS$NODE to be the node synonym name that was entered during configuration.

The system displays a message that it has redefined the logical names.

2.5 Using a DNS Version 1 Namespace with DECdns Version 2

If you are already using a namespace created with Version 1 of the VAX Distributed Name Service (DNS) (running on DECnet Phase IV), you can continue to use the namespace when you upgrade your networking software to DECnet-Plus for OpenVMS. However, because of differences in the way that DNS Version 1 and DECdns Version 2 handle access control, you must prepare your DNS Version 1 namespace for use by DECnet-Plus. DNS Version 1 and DECdns Version 2 interpret principal specifications in access control entries (ACEs) differently.

In DNS Version 1, servers recognize principals only in the form nodename::username. In DECdns Version 2, servers recognize principals primarily in the form nodename.username. For DECdns Version 2 clerks and servers to interpret and process existing DNS Version 1-style access control entries in the namespace, you need to create a backtranslation directory (.DNA_BackTranslation) and a node synonym directory (.DNA_NodeSynonym) in the root directory of the namespace. You must then populate these directories by registering all the nodes participating in the Version 1 namespace.

2.5.1 Preparing a DNS Version 1 Namespace for Use by DECdns Version 2

To prepare a namespace created with DNS Version 1 for use by DECnet-Plus, follow these steps:

1. Install and configure DECnet-Plus for OpenVMS on any node in your namespace that is not currently functioning as a DNS Version 1 server. Configure the node as a DECdns Version 2 clerk. Refer to the DECnet-Plus for OpenVMS Installation and Basic Configuration guide if you plan to use the BASIC configuration option. If you plan to use the ADVANCED configuration option, see Section 1.1.
2. From any node running DNS Version 1 server software, use the DNS Version 1 control program (DNS$CONTROL) add access command to grant the following DNS Version 1-style access on behalf of the SYSTEM account on the new Version 2 clerk node that you configured in Step 1:
   • Read, write, delete, test, and control access to the root directory of the namespace
   • Read, write, delete, test, and control access to the clearinghouse that stores the master replica of the root directory
   
   For example, if the DECnet-Plus full name of the new clerk is .pastry, and the master replica of the Version 1 namespace is stored in the .paris_ch clearinghouse, enter the following two commands:

   DNS> add access pastry::system directory . /rights=(r,w,d,t,c)

   DNS> add access pastry::system clearinghouse .paris_ch /rights=(r,w,d,t,c)

   
   You need to grant this access to ensure that the SYSTEM account on the new Version 2 clerk has sufficient access to run the decnet_register utility. The Version 2 clerk must also have permission to create and populate a backtranslation directory (.DNA_BackTranslation) and node synonym directory (.DNA_NodeSynonym) in the root directory of the namespace during the next step of this procedure.

   Note If the node you configured as a Version 2 clerk in Step 1 is a new node, or is being assigned a new DECnet Phase IV-compatible address, you should update the DECnet node databases on all Version 1 servers in the namespace to include the new address before you proceed.

3. Log in to the new Version 2 clerk node under the SYSTEM account and invoke the sys$manager:decnet_register_decdns.com utility. Do the following:
   1. Choose Option 3 on the decnet_register_decdns.com menu to create and populate a backtranslation directory (.DNA_BackTranslation). Choose Option 2 to create a node synonym directory (.DNA_NodeSynonym).
   2. Choose Option 2 on the decnet_register menu to register the new Version 2 clerk node (the node you are logged in to) and to register all other DECnet Phase IV nodes in the namespace including all nodes that are currently functioning as DNS Version 1 servers.

Refer to the DECnet-Plus for OpenVMS Network Management guide for complete information on how to use the decnet_register utility and the decnet_register_decdns.com utility to perform these steps.

2.5.2 Using the DNS Version 1 Namespace

When you have completed this step, the DNS Version 1 namespace is ready for use by other nodes running DECdns Version 2 on DECnet-Plus for OpenVMS software.

Perform this procedure only once to prepare a DNS Version 1 namespace for use with DECnet-Plus. After the node synonym and backtranslation directories are populated, you can configure new DECdns clerks, new DECdns servers (for VAX only) into an existing namespace (see Section 3.4.5), or convert existing DNS Version 1 servers to DECdns Version 2 format in the normal manner. Refer to the DECnet-Plus DECdns Management guide for information on how to convert a DNS Version 1 clearinghouse to DECdns Version 2 format.