A Few Examples of nslookup Usage

No response from server No name server is running on the server machine. No records The server does not have resource records of the current query type for the host, although the host name is valid. Nonexistent domain The host or domain name does not exist. Connection refused Connection was refused. Network is unreachable The connection to the name server could not be made at the present time. Server failure The name server found an internal inconsistency in its database and could not return a valid answer. Refused The name server refused to service the request. Format error The name server found that the request packet was not in the proper format.

16.4.2 A Few Examples of nslookup Usage

Let us see a few examples. The default domain is myschool.scps.edu and it is determined by the etcresolve.conf file on the host that provided the lookup. The first name server defined in this very same file is pegasus.myschool.scps.edu, which is the primary name server for this domain. nslookup Default Name Server: pegasus.myschool.scps.edu The default data type is A. Address: 146.98.1.12 patsy Look up the hosts address. Name Server: pegasus.myschool.scps.edu Address: 146.98.1.12 Name: patsy.myschool.scps.edu Address: 146.98.1.11 apollo.ph Look up the hosts address. Name Server: pegasus.myschool.scps.edu Address: 146.98.1.12 Name: apollo.ph.myschool.scps.edu Address: 146.98.8.31 apollo.ph. Look up the hosts address. Name Server: pegasus.myschool.scps.edu absolute hosts name Address: 146.98.1.12 pegasus.myschool.scps.edu cant find apollo.ph.: Non−existent domain set type=ptr Shift to another data type PTR. 146.98.8.31 Look up the hosts name. Name Server: pegasus.myschool.scps.edu Address: 146.98.1.12 31.8.98.146.in−addr.arpa name = apollo.ph.myschool.scps.edu set type=ns Shift to another data type NS. myschool Look up the domain name servers. Name Server: pegasus.myschool.scps.edu Address: 146.98.1.12 myschool.scps.edu nameserver = pegasus.myschool.scps.edu myschool.scps.edu nameserver = orion.myschool.scps.edu myschool.scps.edu nameserver = acme.ucc.cuny.edu myschool.scps.edu nameserver = nis.ans.net myschool.scps.edu nameserver = ns.ans.net myschool.scps.edu nameserver = cunixd.cc.columbia.edu pegasus.myschool.scps.edu internet address = 146.98.1.12 orion.myschool.scps.edu internet address = 146.98.1.17 acme.ucc.cuny.edu internet address = 128.228.1.10 nis.ans.net internet address = 147.225.1.10 ns.ans.net internet address = 192.103.63.100 cunixd.cc.columbia.edu internet address = 128.59.40.142 400 myschool Look up the zone SOA record. Name Server: pegasus.myschool.scps.edu Address:146.98.1.12 myschool.scps.edu origin = pegasus.myschool.scps.edu mail addr = sajhc.cunyvm.cuny.edu serial = 9406091 refresh = 3600 1 hour retry = 600 10 min expire = 2419200 28 days minimum ttl = 86400 1 day server orion Shift to another name server. Name Server: orion.myschool.scps.edu The data type is SOA. Address: 146.98.1.17 myschool Look up the zone SOA record. Name Server: orion.myschool.scps.edu Address: 146.98.1.17 myschool.scps.edu origin = pegasus.myschool.scps.edu mail addr = sajhc.cunyvm.cuny.edu serial = 9406091 refresh = 3600 1 hour retry = 600 10 min expire = 2419200 28 days minimum ttl = 86400 1 day exit or Ctrl−D A great deal of very useful information can be obtained with the nslookup utility, such as hosts names, IP addresses, a list of name servers for domains, etc. The last two lookups of the zone SOA r e c o r d s f o r m y s c h o o l . s c p s . e d u d o m a i n a r e e s p e c i a l l y i n t e r e s t i n g . T h e h o s t pegasus.myschool.scps.edu is declared the primary name server for this domain, and the host orion.myschool.scps.edu the secondary name server. Identical serial numbers in both SOA records indicate that the host databases in the name servers are equals, i.e., the secondary name server orion follows the primary name server pegasus. nslookup can be used in many other ways to look up DNS data, as well as to perform very sophisticated debugging. 401

Chapter 17: Network Information Service NIS

17.1 Purpose and Concepts

Networking has led to the introduction of an enormous number of different network applications, which in turn has brought new qualities to computer use. The single host environment has been replaced by multiple hosts, which offer their resources to users and create an almost unrestricted working environment. However to make and maintain such a working environment, a certain level of administration is required; otherwise, everything becomes useless. Multiple hosts in the network present multiple administrative points and require more attention and work to be provided. Can you imagine the network with several hundred computers in it and a new user account to be opened on each of them; or maybe a deletion or modification? The Network Information Service or System − NIS, initially known as the Yellow Pages, is an administrative database that enables a central control over a group of hosts computers that belong to the same, so−called NIS domain. NIS converts important administrative files into a database that can be queried over the network. This ensures that all hosts in the NIS domain have access to the very same administrative databases, which can then be centrally maintained. In NIS terminology, the databases are called NIS maps; they are all created at the single host, the NIS master server, and made accessible through the network to all hosts in the NIS domain — the NIS clients. Any modification of an administrative file at the NIS master server can be easily transferred to an NIS map, and immediately made transparent to all other hosts. Since the number of NIS hosts could be very large, the benefit of a centralized administration is obvious: instead of repeating the same administrative task dozens, or even hundreds, of times, everything has to be done only once. The consistency of the data is guaranteed and achieved in an optimal way. In addition, a sufficient flexibility in administering individual hosts is preserved; NIS enables a selective approach to all administrative issues. NIS is Sun Microsystems baby, and it was a very successful product, first implemented on the SunOS platform. Despite some inherent security problems, other UNIX vendors quickly adopted NIS. Today NIS is a standard part of any UNIX installation. Sun Microsystems later released a new version of the Network Information System, known as NIS+. This was a new product for the same purpose, but definitely a different software package. The basic idea has been to improve the older product with the preserved compatibility. Unfortunately things do not always happen as expected. The new product has not been so successful, and Solaris is practically the only UNIX flavor that implemented it. Neither of the main UNIX players followed this path. Chances for some future comeback of NIS+ are also cumbersome. Today it seems that another product, LDAP, is the most serious candidate to replace NIS. LDAP stands for Lightweight Directory Access Protocol and presents a project to provide global directory services over the Internet in an easier way. The idea is to obtain different types of information from distributed databases spread all over the Internet like e−mail addresses, phone numbers, etc.. Each individual LDAP server would manage its own database about its own community. Individual servers will then be hierarchically merged, making needed information accessible worldwide. The concept of LDAP is quite close to the DNS concept; this is not strange, bearing in mind their similarities and the fact that DNS has been going on so successfully for quite a long time. LDAP was specified in the RFC−1777. LDAP mechanisms could also be used to distribute administrative data, of course in a slightly more restrictive way. The existing RFC−2307 with the title An Approach for Using LDAP as a Network Information Service indicates such a tendency. 402