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:

• A name should be meaningful and easy for its users to remember and type. Give meaning to a name by making it descriptive of the resource it names. For example, .Aero.Dev.Project_disk could be the name of the VAX Distributed File Service (DFS) access point used by a company's aerospace development division, and .Sales.Topdollar could be the name of a node in the company's sales division.
• A name should be as short as is practical without causing it to lose meaning or uniqueness.
• If you create a DECdns directory hierarchy, choose directory names that are stable and are not likely to be affected by reorganizations or changes in product strategy. It is difficult to change existing directory names, especially at high levels in the namespace. Also, a change in a directory name affects all applications that use names in that directory, as well as any users who memorized the full name of a resource or created an abbreviated name for it. See the DECnet-Plus DECdns Management guide for details on how local name substitution works.
• DECdns preserves the case of names as they are entered. Lookups, however, are case sensitive so is not possible to create two names that differ only in their case. For example, requests to look up .MYNODE, .mynode, and .MyNode would all produce the same result. Similarly, if someone attempted to create all three of those names, only the first attempt would succeed.
• A name can be any combination of letters, digits, and certain punctuation characters from the ISO Latin-1 character set.
• A full name, including the namespace nickname, can have as many as 511 characters, as illustrated in Figure 6-1.

  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:

• In networks of fewer than 50 DECdns servers, name all clearinghouses in the root directory (for example, .Bonn_CH). This enables you to automatically comply with two special clearinghouse rules that protect the name service's ability to find names. See the DECnet-Plus DECdns Management guide for details. In networks of 50 servers or more, you should name some clearinghouses at levels below the root. See Section 7.2 for an explanation of the reasons.
• Include a suffix such as _CH at the end of clearinghouse names (for example, .Paris_CH or .Sales_CH) to help you easily identify clearinghouse names and avoid accidentally deleting them. Tightly controlling access to clearinghouse names also can help prevent accidental deletion.
• Avoid naming a clearinghouse based on the name of the server node where it exists. Although using the node name conveniently indicates the exact location of a clearinghouse, it can make things confusing if you later move the clearinghouse to another node. You cannot rename a clearinghouse once it is created, so DIGITAL does not recommend giving it a name based on the node where it currently exists. Instead, consider naming clearinghouses based on the site, city, or region where they are located. Even if you move a clearinghouse, you are not likely to move it far from the site or city where it resides.

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:

• Although nicknames can contain up to 255 characters, you should choose a short and simple namespace nickname. When you refer to a name in your clerk's default namespace, you do not need to specify the namespace nickname. However, because the nickname still appears in command output, it makes sense to keep the nickname short.
• Because a namespace has no relationship to any individual node, you should give the namespace a nickname that is meaningful to users networkwide. You might base the namespace nickname on your company's name. For example, a company called International Air Freight could have a namespace nickname of IAF. Choose the namespace nickname carefully; it is difficult to change. Changing the namespace nickname involves creating a new namespace and copying all the entries.
• You might decide to create a test namespace so you can become familiar with the DECdns software. If you do, 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 namespace. Namespace nicknames are extremely difficult to reuse once they have been established in clerk caches throughout the network.
• The following namespace nicknames have special meaning to DECnet-Plus. The nickname LOCAL for a node full name indicates that DECnet-Plus should look up information for the node in the Local namespace. Similarly, the nickname DOMAIN for a node full name indicates that DECnet-Plus should look up information for the node in the DNS/BIND namespace.

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:

1. Decide whether you should have multiple DECdns namespaces.
2. Choose a namespace nickname and establish a general naming policy.
3. Determine whether you need a directory hierarchy. If so, plan the directory structure.
4. Plan an access control policy.
5. Plan how to replicate directories.
6. Select DECdns server nodes.

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:

• They make name references less convenient.
  In a single-namespace network, you can define a default namespace nickname and then no longer have to use it in name references. In a multiple-namespace network, references to a name outside of the default namespace must include the namespace nickname.
• They increase management complexity and overhead.
  Multiple namespaces involve additional overhead in tracking and maintaining entries in each namespace. In particular, if you store node information in more than one namespace, and you want the nodes in different namespaces to be able to communicate, you greatly increase the complexity of creating and managing node object entries and node soft links. You also increase the complexity of managing access control.
  If there is a need for multiple namespaces in your network, yet you want all of the nodes in each namespace to be able to communicate, you must run decnet_register once for each namespace. If you use a Phase IV node registration script that the tool creates, you must edit the data files that the script uses. You will also need to manually maintain and update some of the node information in each namespace. For details, see Section 2.4.2.

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:

• It is larger than about 100 nodes.
• It is smaller than 100 nodes now but you expect growth over time.
• It includes OpenVMS systems already using DNS Version 1, and you want to plan a unified namespace that contains more than just node entries.

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_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:

• Every user on a node registered in this namespace gets read access to all directories, object entries, and soft links that the tool creates.
• Every user on a node registered in this namespace gets read and write access to the children of the .DNA_BackTranslation directory and their contents. Write access is necessary so a node can automatically keep its own address data up-to-date.
• The .DNA_Registrar group gets complete access to all directories, object entries, and soft links that the tool creates.
• Session Control on each node gets the access rights it needs to maintain that node's DNA$Towers, synonym, and backtranslation data.

The following three suggested policies offer varying degrees of access control over node data in the namespace.

• Secure, centralized: The default policy created by decnet_register grants the highest degree of centralized control over node names and soft links. Under this policy, only members of the .DNA_Registrar group are able to register nodes in the namespace. Only Session Control and members of the .DNA_Registrar group are able to modify node data. To complete implementation of this policy, all you have to do is add the names of designated node-name administrators to the .DNA_Registrar group (the group is created empty).
• Moderately secure: To maintain centralized control over the namespace but allow people other than the .DNA_Registrar group to register and modify node information, you can grant access as needed to specific individuals and remove the access when the task is done. This policy means users still must contact a member of the .DNA_Registrar group when they want access to the namespace. However, it allows the .DNA_Registrar group to temporarily delegate node-name registration and management tasks.
• Accessible: To completely decentralize, you can change the default directory access control to grant read and write access to directories that are to contain node names. This allows nodes to autoregister themselves. It also allows any user to register a node in those directories without intervention by a namespace administrator. The decnet_register tool provides a convenient means for allowing or disallowing node autoregistration.

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:

• Choose stable nodes.
  DECdns servers should be stable systems that experience minimal downtime and restart quickly. It is important that a DECdns server be one of the first systems available in the network, because client applications all over the network are limited to the information in clerk caches until a DECdns server is available.
• Use reliable network connections.
  Reliable connections between DECdns servers are important because, during skulks, DECdns must be able to contact all servers that maintain a replica of the directory involved. Reliable connections between clerks and servers are not essential after a clerk develops a cache of frequently used information. However, they do increase the chances for success on initial lookups and on rare long-distance lookups.
• Estimate disk space, CPU, and memory requirements.
  In small namespaces, the impact of DECdns on timesharing systems should be minimal. The impact depends partly on the number of node object entries and soft links in the namespace, the frequency of use of those names, and the load placed on the system by other applications. If you are concerned with DECdns capacity requirements, see Section 8.3 for additional guidelines.

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.