Solaris Naming Services Architecture

• By Tom Bialaski and Michael Haines
• Dec 6, 2001
• Sample Chapter is provided courtesy of Prentice Hall

This chapter is from the book
Solaris and LDAP Naming Services: Deploying LDAP in the Enterprise

NIS and DNS Coexistence

About the same time that Sun introduced NIS, standards for a universal naming system were being defined in RFC 1034 and RFC 1035. Later, implementations of this specification called the Domain Naming System (DNS) began to appear, like the Solaris in.named program, which was derived from Berkeley Internet Name Demon (BIND), found in Berkeley UNIX. Although NIS worked well to store host names and IP addresses of computers within an organization, DNS could scale much better and gained industry-wide adoption.

Companies deploying NIS tended to store the host name and IP addresses of their Sun workstation and server networks in NIS maps, but used DNS to look up names of computers outside of the network. To enable the two naming services to interoperate, Sun added a DNS forwarding capability to the NIS server.

The way DNS forwarding works is that if a search is made in an NIS map that has this feature enabled, the search request is passed on to a DNS server for resolution if the host name is not found. To implement this idea, the hosts.byname and hosts.byaddr maps must have the YP-INTERDOMAIN key in them. Creation of this key requires a simple modification to the NIS Makefile.

The alternative to enabling DNS forwarding is to include DNS as an option in the nsswitch.conf file which is described in the next section. It is not advisable to use both schemes together because redundant searches are performed if the name cannot be resolved, that is DNS will be searched twice.