NIS keeps database information in so-called maps containing key-value pairs. Maps are stored on a central host running the NIS server, from which clients may retrieve the information through various RPC calls. Quite frequently, maps are stored in DBM files, which allows for quick searches. For each key to be searched, a separate DBM file must be created. For example, in the /etc/passwd file, the database must be searchable by the login and the UID. The result is two DBM files, passwd.byname and passwd.byuid.

The NIS server is called ypserv. For an average network, a single server usually suffices; large networks may choose to run several of these on different machines and to relieve the load on the server machines and routers. Making one of them a master server and others as slave servers, these are synchronized. Maps will be created only on the master server's host and distributed to all slaves from here.

There's a distinctive concept in NIS that refers to a network, that is the collection of all hosts that share part of their system configuration data through NIS: The NIS domain. NIS domains have absolutely nothing in common with the domains encountered in DNS, although both can have same domain names.

A common scheme is to simply use the DNS domain name for NIS as well. To set and display the NIS domain name of your host, use the domainname command. When invoked without any argument, it prints the current NIS domain name. To set the domain name, login as root and type:

domainname domain

where domain is the domain-name selected for NIS.

NIS domains determine which NIS server an application will query. But how does a client find out which server to connect to? The simplest approach would be to have a configuration file that names the host on which to find the server. However, this approach is rather inflexible, because it doesn't allow clients to use different servers (from the same domain, of course), depending on their availability. Therefore, traditional NIS implementations rely on a special daemon called ypbind to detect a suitable NIS server in their NIS domain. Before being able to perform any NIS queries, an application finds out, from ypbind, which server to use.

ypbind probes for servers by broadcasting to the local IP-network; the first to respond is assumed to be the potentially fastest one and will be used in all subsequent NIS queries. After a certain interval has elapsed, or if the server becomes unavailable, ypbind will probe for active servers again.