Global name services have worldwide scope. This section describes the policies for naming objects that use global naming systems.
In regard to naming, an enterprise links to the federated global namespace by binding the root of the enterprise in the global namespace. This enables applications and users outside the enterprise to name objects within that enterprise. For example, a user within an enterprise can give out the global name of a file to a colleague in another enterprise to use.
DNS and X.500 contexts provide global-level name service for naming enterprises. FNS provides support for both DNS and X.500 contexts. Without FNS, DNS and X.500 allow outside access to only limited portions of the enterprise namespace. FNS enables outside access to the entire enterprise namespace including services such as calendar manager.
The atomic name ”...” (three dots) appears in the initial context of every FNS client. The atomic name “...” is bound to a context from which global names can be resolved.
Table 25–29 Initial Context Bindings for Global Naming
Atomic Name |
Binding |
---|---|
. .. |
Global context for resolving DNS or X.500 names |
/ ... |
Synonym for three dots |
Global names can be either fully qualified Internet domain names, or X.500 distinguished names.
Internet domain names appear in the syntax specified by Internet RFC 1035. For example, .../doc.com. (See Federating DNS.)
X.500 names appear in the syntax determined by the X/Open DCE Directory. For example, .../c=us/o=doc. (See Federating X.500/LDAP.)
The names “...” and “/...” are equivalent when resolved in the initial context. For example, the names /.../c=us/o=doc and.../c=us/o=doc resolve in the initial context to the same object.
Any fully qualified DNS name can be used in the global context. When a DNS name is encountered in the global namespace, it is resolved using the resolver library. The resolver library is the DNS name-resolution mechanism. A DNS name typically resolves to an Internet host address or to DNS domain records. When the global context detects a DNS name, the name is passed to the DNS resolver for resolution. The result is converted into an XFN reference structure and returned to the requester.
The contents of DNS domains can be listed. However, the listing operations might be limited by practical considerations such as connectivity and security on the Internet. For example, listing the global root of the DNS domain is generally not supported by the root DNS servers. Most entities below the root, however, do support the list operation.
DNS hosts and domains are distinguished from each other by the presence or absence of name service (NS) resource records associated with DNS resource names.
DNS domain names. If an NS record exists for a resource name, then that name is considered to be the name of a domain, and the returned reference is of type inet_domain.
DNS host names. If no NS record exists for a resource name, then that name is considered to be the name of a host, and the returned reference is of type inet_host.
DNS can be used to federate other naming systems by functioning as a non-terminal naming system.
For example, an enterprise naming system can be bound to doc.com in DNS such that the FNS name .../doc.com/ refers to the root of that enterprise's FNS namespace.
The enterprise naming system is bound to a DNS domain by adding the appropriate text (TXT) records to the DNS map for that domain. When the FNS name for that domain includes a trailing slash (/), the TXT resource records are used to construct a reference to the enterprise naming system.
For general information about DNS, see the in.named man page or the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
X.500 is a global directory service. It stores information and provides the capability to look up information by name as well as to browse and search for information.
X.500 information is held in a directory information base (DIB). Entries in the DIB are arranged in a tree structure. Each entry is a named object and comprises a defined set of attributes. Each attribute has a defined attribute type and one or more values.
An entry is unambiguously identified by a distinguished name that is the concatenation of selected attributes from each entry in the tree along a path leading from the root down to the named entry. For example, using the DIB shown in Figure 25–5, c=us/o=doc is a distinguished name of the doc organization in the U.S. Users of the X.500 directory can interrogate and modify the entries and attributes in the DIB.
FNS federates X.500 by supplying the necessary support to permit namespaces to appear to be seamlessly attached below the global X.500 namespace.
For example, FNS facilitates linking the enterprise naming system for the doc organization below X.500. Starting from the initial context, an FNS name to identify the sales organizational unit of the doc organization might be
.../c=us/o=doc/orgunit/sales
The name within the enterprise is simply concatenated onto the global X.500 name. (Note that FNS names use the name ”...” in the initial context to indicate that a global name follows.)
Name resolution of FNS names takes place as follows. When an X.500 name is encountered in the global namespace, it is resolved using the X.500 name- resolution mechanism. One of three outcomes is possible:
The full name resolves to an X.500 entry. This indicates that the entry is held in X.500. The requested FNS operation is then performed on that entry.
A prefix of the full name resolves to an X.500 entry. This indicates that the remainder of the name belongs to a subordinate naming system.
The next naming system pointer (NNSP) to the subordinate naming system is examined to return the XFN reference. Name resolution then continues in the subordinate naming system.
An error is reported.
X.500 entries can be examined and modified using FNS operations (subject to access controls). However, it is not currently possible to list the subordinate entries under the root of the X.500 namespace by using FNS.