HP OpenVMS Systems Documentation
This chapter provides general guidelines for all DECnet-Plus names as
well as specific guidelines for naming clearinghouses and namespaces.
6.1 General Naming Guidelines
As you choose all DECnet-Plus names, consider the following guidelines:
Figure 6-1 Full Name Example
If you configure your node as a DECdns server, you must supply a DECdns name for the clearinghouse that the server will manage. Use the following guidelines for naming clearinghouses:
When you create a new namespace, you must supply both a namespace nickname and a clearinghouse name (the first node in a new DECdns namespace must configure as a DECdns server). Use the following guidelines for choosing a namespace nickname:
Note that the use of the underbar (or underscore) character (_), may be restricted by certain sendmail implementations. As DECnet MAIL-11 addresses may be processed by sendmail on some systems (for example, DIGITAL UNIX), you should take this restriction into consideration.
This chapter contains basic DECdns planning guidelines if you choose to plan and implement a DECdns distributed namespace now. See Section 3.2.2 if you plan to use a Local namespace.
If you plan to use a DECdns distributed namespace, DECdns is a networkwide service that allows users and applications to assign unique names to such resources as nodes, disks, and files, and then use these resources without knowing their physical location. If your network consists of about 100 nodes and you do not expect it to grow much over its lifetime, this chapter is all you need to read to plan for DECdns.
The basic DECdns planning steps are as follows:
DIGITAL recommends using a single namespace for your entire network. However, if your organization has special requirements that justify the use of multiple namespaces, there is nothing to prevent you from creating them. They can coexist without harm to each other.
If multiple namespaces do exist, they are separate and do not share information. You cannot replicate data across namespaces. Users can refer to a name in a namespace other than their own by including the namespace nickname in the full name reference.
Using multiple namespaces might be justified if you have two or more unconnected networks that you plan to always keep separate, or if your organization plans to acquire or connect with separate networks that have existing namespaces. Multiple namespaces might also be a solution for a company with a strong tradition of separate, autonomous departments that would find it difficult to plan a single, companywide namespace.
Another valid reason for multiple namespaces is if you decide to create a test namespace for the purpose of becoming familiar with the DECdns software. In that case, give the namespace a nickname like Test to clearly indicate its purpose. Do not give a test namespace a nickname that you eventually want to use for a networkwide production namespace. Namespace nicknames are difficult to reuse once they have been established in clerk caches throughout the network.
Creating multiple namespaces is not a way to separate names for security purposes. The access control capabilities of DECdns are sufficient to protect names from people and applications that should not see or use them. The following are some additional arguments against using multiple namespaces:
What To Do If a Namespace Already Exists
One or more namespaces might already exist in your network as a result of client applications that use an earlier version of DECdns, called VAX Distributed Name Service (DNS) Version 1. DNS Version 1 and DECdns can interoperate in the same namespace, with a few restrictions and considerations. An appendix in the DECnet-Plus DECdns Management guide contains details on interoperability.
If you have one or more existing Version 1 namespaces, plan to
configure the first DECnet-Plus node in one of them. Eventually you
should create a Version 2 namespace and merge the other namespaces into
it. See the DECnet-Plus DECdns Management guide for details on
how to merge namespaces.
7.2 Step 2: Plan a Naming Policy
Before you configure the first DECnet-Plus node, choose a namespace nickname and establish a naming convention for clearinghouses, directories, and object entries. Chapter 6 contains naming rules and guidelines.
If you decide to create a directory hierarchy, your naming policy can
be influenced by the directory structure that you plan and by the way
in which names will be used and managed. Your directory structure and
naming policy might therefore evolve at the same time.
7.3 Step 3: Should You Create a Directory Hierarchy?
Small networks should not need to create a hierarchy of directories other than those required for use by Session Control and DECdts. As long as you do not anticipate major growth beyond your network's current size, you can name all of your clearinghouses and DECnet-Plus nodes in the root directory.
Naming everything in the root keeps names short and simple, and it eliminates the planning and management tasks associated with multiple directories. However, it means every node name in your namespace will be in one directory. If you want to protect some names from general access, you need to grant access to individual names rather than granting access to the entire contents of the root directory. See the DECnet-Plus DECdns Management guide for a detailed description of access control.
If your network meets any of the following conditions, read Chapter 8 for guidelines on planning a directory structure:
Before you configure your first DECnet-Plus node, you should plan an overall node-name administration policy. This section presents guidelines for controlling access to the directories containing node object entries, node synonym soft links, and backtranslation soft links. If your namespace will contain entries other than node names, you should plan and implement an access control policy that includes those entries as well.
The DECnet-Plus DECdns Management guide has details on how access control works and shows sample commands for implementing varying degrees of security in your namespace. Read the access control chapter before you configure the first DECnet-Plus node. DIGITAL recommends that you implement an access control policy immediately after you create a new namespace.
The decnet_register tool automatically grants certain access rights for directories, object entries, and soft links that it creates. Depending on the degree of security and centralization you want for node-name management, you can modify the default access control scheme. By default, the tool assigns the following access:
The following three suggested policies offer varying degrees of access control over node data in the namespace.
The default access control policy established by decnet_register applies only to directories created with that tool. The tool always creates the .DNA_NodeSynonym and .DNA_BackTranslation directories. Directories to contain DECnet-Plus node object entries can be created with either the tool or the DECdns Control Program. By default, the control program grants full access for the creator of a directory. Therefore, on directories created with the control program, you must add or modify access if you want it to parallel the access granted by decnet_register.
A basic DECdns guideline is to create at least two replicas of every directory (including the original, or master replica). Replication ensures an alternate source of information in the event that one of the replicas is temporarily unavailable. Replication also creates a live backup of DECdns data in the event that a clearinghouse becomes permanently unavailable.
Replicating data requires at least two clearinghouses, and thus two servers. In very small namespaces, you can configure only one server and rely on traditional operating system backups to preserve DECdns information. However, backups are not a good way to preserve data in namespaces with more than one clearinghouse. If you restore a clearinghouse whose data is replicated elsewhere in the namespace, unexpected and confusing results may occur. For example, recently created names can disappear, recently deleted names can reappear, and recent modifications can be reversed. Replication provides reliable, real-time backup of information and protects you against disk failures and common problems that may occur. Backups of the master replica protect you against deleting object entries. Therefore, the best way to back up DECdns data is to create at least two replicas of every directory.
DECdns creates the root directory automatically when you configure the first server and clearinghouse in the namespace. The root also is replicated automatically at any subsequent server whose clearinghouse you name in the root.
After decnet_register creates and populates the node
directories, you should replicate them for availability and backup.
Because DECnet-Plus systems are the only ones that use the directories
created by the tool, you can replicate them at the same pace at which
you migrate nodes to DECnet-Plus. In fact, if you do not have an
existing DNS Version 1 namespace, replication must wait until you
configure at least one other DECdns server. In small networks, two
replicas of every directory should be sufficient. See Chapter 8 for
additional replication guidelines for large networks.
7.6 Step 6: Select DECdns Servers
Server nodes are the systems that store and maintain the clearinghouses in your namespace. Your main goals in choosing DECdns servers should be to achieve availability of data, reliability, and optimum performance. Study your network and keep in mind the following guidelines to help you achieve those goals:
Unless you already have a DNS Version 1 namespace, the first system in
your network to make the transition to DECnet-Plus must be a DECdns
server. Many additional factors can influence the choice of the first
DECnet-Plus system (see Chapter 2 for details).
7.6.1 Server Placement Guidelines for LANs and Extended LANs
To ensure access to data in the event a server becomes unavailable and to distribute lookup load, consider using at least two servers for every thousand nodes. If a server is connected to other servers through high-speed, reliable links, you might be able to use just one server on a LAN. Factors influencing your decision can include the expected lookup load and how you want to distribute it, and the capacity of the systems that you plan to use as DECdns servers.
On extended LANs, consider the reliability of the bridge connecting LANs. If the bridge is frequently unavailable, or if it filters DECdns multicasts, you might want two servers on each side of the bridge. (DECdns servers use multicasts to advertise their existence to clerks and other servers, so LAN bridges that filter multicasts prevent the automatic passage of this information from one LAN to another.) However, if the bridge is reliable and does not filter multicasts, then one server on each side of the bridge is adequate.
Note that with the LAN Bridge 200 product and Remote Bridge Management Software, you can control filtering to allow DECdns multicast IDs to traverse the bridge. The following are the DECdns multicast IDs:
When planning the placement of DECdns servers in a wide area network (WAN) environment, try to avoid connections through WAN links that are not usually stable. Place DECdns servers so that most systems can access at least one server even if a WAN connection is unavailable.
At small sites connected to the rest of the network through a WAN, a DECdns server is not necessary if the small site only occasionally uses resources on the other side of the WAN link. For example, if users at a small site sometimes contact nodes at the company's headquarters, it is probably sufficient to store the node names at headquarters, and it is not necessary to configure a DECdns server at the small site. Remember that once clerks at the small site cache frequently used names, they will rarely need to cross a WAN link for lookups anyway.
On the other hand, if the small site has many DECdns names referring to object entries at the site, it might make sense to configure a server there. Consider storing the master replica at the small site's server if you expect users there to make frequent changes to the names. Doing so further reduces WAN traffic and improves performance.
Consider that when you configure clerks at sites connected by a WAN link, you must manually enter the address of a server that the clerk can contact. This is less convenient than configuring clerks on a LAN, where the clerk automatically receives advertisements from servers on the LAN and caches their addresses.