Within Network Information Service (NIS), which client-side component discovers and binds to an NIS domain/server and maintains that binding?

Introduction / Context:
NIS (formerly Yellow Pages) centralizes account and configuration data across Unix systems. On each client, background services establish and maintain a relationship with an NIS server so that lookups (for example, passwd, group) resolve against NIS maps seamlessly.

Given Data / Assumptions:

• NIS domain is configured on the network.
• The client must locate and keep a binding to an NIS server.
• We differentiate utilities that query vs. those that establish bindings.

Concept / Approach:
'ypbind' is the daemon that contacts NIS servers, discovers one that serves the specified domain, and maintains the binding so libc/NSS requests can query maps. 'ypwhich' merely reports which server the client is currently bound to. 'ypcat' prints the contents of a map, and 'yppoll' queries the master for map order/version information. Therefore, the component that both finds and stores (maintains) the binding is 'ypbind'.

Step-by-Step Solution:

Verification / Alternative check:
Stop ypbind and observe that NIS lookups fail; restart it and verify that bindings and lookups resume, confirming its role.

Why Other Options Are Wrong:

• ypwhich: Displays current server but does not bind.
• ypcat: Prints map contents only.
• yppoll: Queries map order from the master; no binding function.

Common Pitfalls:
Misconfiguring the NIS domain name, firewalling the portmapper/rpcbind, or assuming ypwhich establishes a binding (it only reports it).

Final Answer:
ypbind