Chapter 26 FNS and Global Naming Systems

This chapter describes two global naming systems (DNS and X.500/LDAP) and how to federate them under FNS.

• "FNS and Global Naming Systems"

• "Obtaining the Root Reference"

• "Federating Under DNS"

• "Federating Under X.500/LDAP"

FNS and Global Naming Systems

See "Global Naming Services" for overview and background information on the relationship between FNS and global naming services.

FNS supports federation of enterprise naming systems into the global naming systems, DNS and X.500/LDAP. This chapter describes the procedures for federating NIS+ with DNS and X.500. In general, the procedures involve

• Determining the NIS+ root reference for your NIS+ hierarchy

• Adding this information in the format required by the global naming system

You can only federate a global naming service if your enterprise-level name service is NIS+ or NIS. If you are using a files-based name service for your enterprise, you cannot federate either DNS or X.500/LDAP.

Obtaining the Root Reference

To federate an enterprise naming service under DNS or X.500/LDAP, information must be added to these respective naming systems to enable access to and from the enterprise and the global Internet outside of the enterprise. This information is the root reference, which consists of network address information describing how to reach the top of a particular enterprise namespace.

The root reference consists of a single address which contains a single, XDR-encoded string. The address type and content varies according to the enterprise level name service you are using: NIS+ or NIS.

NIS+ Root Reference

When your enterprise level name service is NIS+, the root reference address type is: onc_fn_nisplus_root. There are two required, and one optional, elements in a root reference network address. The elements are separated by white spaces:

root-domain server [server_IP_address]

For example, suppose that the NIS+ root domain is doc.com. (notice the trailing dot), and that it can be reached using the host nismaster.doc.com. The root reference would be:

doc.com. nismaster.doc.com

The IP address of the server is not given in the example above because it is expected to be available through other means. If for some reason that IP address was not available through other means, the root reference would look like:

doc.com. nismaster.doc.com 123.123.123.33

NIS Root Reference

When your enterprise level name service is NIS, the root reference address type is: onc_fn_nis_root. There are two required, and one optional, elements in a root reference network address. The elements are separated by white spaces:

root_domain server [server_IP_address]

For example, suppose that the NIS domain is doc.com, and that it can be reached using the host ypmaster.doc.com. The root reference would be:

doc.com/ ypmaster.doc.com

The IP address of the server is not given in the example above because it is expected to be available through other means. If for some reason that IP address was not available through other means, the root reference would look like:

doc.com/ ypmaster.doc.com 123.123.123.37

Federating Under DNS

This section describes the steps required to add TXT (text) records for a subordinate enterprise naming system implemented with NIS+ or NIS. To federate a subordinate naming system in DNS, you need to add reference information into DNS describing how to reach the subordinate naming system's root reference.

1. Obtain the root reference.

   See "Obtaining the Root Reference".

2. Add a root reference TXT record to the DNS loopback file.

   By default, this manual uses the name /etc/named.local for this file (other common names for this file are domain.127.0.0 or db.127.0.0).

   The root reference TXT record has the following format:

   For NIS+

   TXT "XFNNISPLUS rootdomain server [server_IP_address]"

   For example:

   TXT "XFNNISPLUS doc.com. nismaster.doc.com"

   For NIS

   TXT "XFNNIS rootdomain server [server_IP_address]"

   For example:

   TXT "XFNNIS doc.com/ ypmaster.doc.com"

   The TXT record must be associated with a DNS domain that includes an NS (name server) record entry. The following is an example of a DNS domain with reference information for NIS+ bound in it.

   $ORIGIN doc.com @ IN SOA foo bar.eng.doc.com ( 100 ;; Serial 3600 ;; Refresh 3600 ;; Retry 3600 ;; Expire 3600 ;; Minimum ) NS nshost TXT "XFNNISPLUS doc.com. nismaster 123.123.123.33" nshost IN A 133.33.33.34

   For more information about DNS files, see "DNS Configuration and Data Files".

3. After adding the TXT record into the DNS table, either restart the DNS server or send it a signal to reread the table.

   # kill -HUP pid

   Where pid is the process ID number of in.named.

   For further information on how DNS TXT records are used for XFN references, see "DNS Text Record Format for XFN References".

Federating Under X.500/LDAP

In order to federate a subordinate naming system (either NIS+ or NIS) in X.500/LDAP:

• Root reference information must be added into X.500 describing how to reach the subordinate naming system.

• An X.500 client API must be specified.

Specifying an X.500 Root Reference

1. Obtain the NIS+ root reference for your NIS+ hierarchy.

   See "Obtaining the Root Reference".

2. Create an X.500 entry that supports XFN reference attributes.

   For example, the following command creates a new X.500 entry called c=us/o=doc with the object classes top, organization, and XFN-supplement (1.2.840.113536.25). The XFN-supplement object class allows the c=us/o=doc entry to store reference information for a subordinate naming system.

   # fnattr -a .../c=us/o=doc object-class \ top organization XFN-supplement

   If the X.500 entry already existed and was not defined with the XFN-supplement object class, it must be removed and re-created with the additional object class. Otherwise, it will not be able to hold reference information about the subordinate naming system.

3. Add the reference information about the subordinate system to the entry.

   After creating the X.500 entry, you can then add information about the subordinate system by binding the appropriate root reference to the named entry.

   For example, if your subordinate naming system is NIS+, and the NIS+ server you want to use is nismaster, your would enter:

   # fnbind -r .../c=us/o=doc/ onc_fn_enterprise onc_fn_nisplus_root \ "doc.com. nismaster

   If your subordinate naming system is NIS, and the NIS server you want to use is ypmaster, your would enter:

   # fnbind -r .../c=us/o=doc/ onc_fn_enterprise onc_fn_nis_root \ "doc.com/ ypmaster"

   These examples bind the reference for the NIS+ or NIS hierarchy with the root domain name doc.com., to the next naming system pointer (NNSP) of the X.500 entry c=us/o=doc, thus linking the X.500 namespace with the doc.com. namespace.

   The address format used is that of the root reference described in "Obtaining the Root Reference". Note the use of the trailing slash in the name argument to fnbind, .../c=us/o=doc/, to signify that the reference is being bound to the NNSP of the entry, rather than to the entry itself.

   For further information on X.500 entries and XFN references, see "X.500 Attribute Syntax for XFN References".

Specifying an X.500 Client API

An X.500 client API is required in order to access X.500 using FNS. You can use one of two different clients:

• XDS/XOM API. The XDS/XOM API must be installed. It is exported from the /opt/SUNWxds/lib/libxomxds.so shared object. Consult "Getting started with the SunLink X.500 Client Toolkit" for details on the X.500 product.

• LDAP (Lightweight Directory Access Protocol) API. The LDAP API is automatically installed as part of Solaris Release 2.6.

The API that you use is specified in each machine's /etc/fn/x500.conf file. This file contains configuration information for X.500 and LDAP. This file can be edited directly. The default x500.conf file contains two entries:

x500-access: xds ldap 
ldap-servers: localhost ldap

Where localhost and ldap are the IP addresses or hostnames of one or more LDAP servers.

The first entry specifies the order in which X.500 accesses APIs. In the example above, X.500 will first try to use XDS/XOM. If XDS/XOM is not available, it will default to using LDAP. If the entry read: x500-access: ldap xds, X.500 would use LDAP and only fall back on XDS if LDAP were not available.

The second entry lists the IP addresses or hostnames of servers running LDAP. Each server is tried in turn until a successful LDAP connection is achieved. In the example above, the localhost is tried first. If LDAP is not available on that server, the next one is tried.