The Oracle Solaris platform provides the naming services described in the following sections:
Most modern networks use two or more of these services in combination. The name service switch coordinates the naming service that is used for a particular lookup. For more information, see About the Name Service Switch.
In Oracle Solaris, all naming services are managed by the Service Management Facility (SMF). Configuration information is no longer stored in configuration files but in the SMF repository. Refer to the individual chapters in this book for more information about how SMF works with a specific naming service.
Legacy configuration files are retained in the Oracle Solaris 11 release only for purposes of compatibility with previous Oracle Solaris releases. The SMF service that is relevant to the specific naming service generates the contents of the legacy configuration files. You should no longer use these files for naming service configuration. Instead, you must use the general SMF commands such as svcs, svcadm, and svccfg.
When you upgrade from Oracle Solaris 10 to Oracle Solaris 11 and its update releases, the system's name service configuration is automatically migrated to SMF. However, if necessary, you can perform manual migration by using the nscfg command. For more information, see the nscfg(1M) man page.
The Domain Name System (DNS) is a hierarchical, distributed database implemented on a TCP/IP network. It is primarily used to look up IP addresses for Internet host names and host names for IP addresses. The data is distributed across the network and is located by using period-separated names that are read from right to left. DNS is also used to store other Internet-related host information, such as mail exchange routing information, location data, and available services. The hierarchical nature of the service enables the local administration of local domains while providing international coverage of other domains that are connected to the Internet, an intranet, or both.
DNS clients request information about a system from one or more name servers and wait for a response. DNS servers respond to requests from an information cache that was loaded from any of the following sources:
A file or a third-party database on a DNS master server
A file or a third-party database from a cooperating DNS slave server in the network
Information stored from previous queries
If no response is found and the DNS server is not responsible for the domain in question, the service, if appropriately configured, will recursively request the host name from other DNS servers and cache that response.
The svc:network/dns/multicast service manages two extensions to the DNS protocol. Multicast DNS (mDNS) implements DNS in a small network where no conventional DNS server has been installed. DNS Service Discovery (DNS-SD) extends Multicast DNS so that it also provide simple service discovery (network browsing). For more information, see Multicast DNS and Multicast DNS Service Discovery.
The mDNS service uses the .local domain name, so do not use that name in DNS to avoid possible conflicts.
The original host-based UNIX naming system was developed for stand-alone UNIX system and then adapted for network use. Many old UNIX operating systems till manage all naming data by using only local files in /etc. However, managing hosts, users, and other naming data by using local files is not well suited for large complex networks. For a description of each file, refer to their associated man pages. For example, the /etc/inet/hosts file is described in the hosts(4) man page.
The Network Information Service (NIS) was developed independently of DNS. DNS makes communication simpler by using host names instead of numerical IP addresses. NIS focuses on making network administration manageable by providing centralized control over a variety of network information. NIS stores information about the network, host names and addresses, users, and network services. This collection of network information is referred to as the NIS namespace.
NIS namespace information is stored in NIS maps. NIS maps replace UNIX /etc files as well as other configuration files. Because NIS maps store much more than names and addresses, the NIS namespace has a large set of maps. For more information, see Working With NIS Maps.
NIS uses a client-server arrangement, which is similar to DNS. Replicated NIS servers provide services to NIS clients. The principal servers are called master servers, and for reliability, the master servers have backup, or slave servers. Both master and slave servers use the NIS retrieval software and both store NIS maps. For more information about NIS architecture and NIS administration, see Setting Up and Configuring Network Information Service and Administering Network Information Service.
The Lightweight Directory Access Protocol (LDAP) is the secure network protocol that is used to access directory servers for distributed naming and other directory services. This standards-based protocol supports a hierarchical database structure. You can use the same protocol to provide naming services in both UNIX and multiplatform environments.
The Oracle Solaris OS supports LDAP in conjunction with the Oracle Directory Server Enterprise Edition (formerly Sun Java System Directory Server), as well as other LDAP directory servers.
For more information about LDAP and instructions to transition from NIS to LDAP, see Working With Oracle Solaris 11.3 Directory and Naming Services: LDAP.
For information about single sign-on as well as the setup and maintenance of Kerberos authentication services, see Chapter 2, Kerberos on Oracle Solaris in Managing Kerberos and Other Authentication Services in Oracle Solaris 11.3.
The name service switch is a mechanism that enables clients to search through the DNS, LDAP, NIS, or local files data sources for naming information. The switch is managed through the svc:/system/name-service/switch service. For more information, see About the Name Service Switch.