NIS V/s DNS - Which is better in Name Resolution??

[Sanjay Verma]

Hi Friends,

I would like to identify which is more efficient in Name Resolution - NIS or DNS? Would like to get your comments on these:


(a) NIS is known to introduce security risks. Is that right?

(b) Is there any comparison between the DNS Name resolution & NIS Name resolution. Which one is best?

(c) It two servers are in cluster, is it still recommended to have NIS Name Resolution?

(d) In HP-UX 11.0, Which one is HP standard - NIS or DNS?

Regards,
Sanjay

[Patrick Wallek]

It depends entirely on what you are trying to accomplish.

If you want JUST hostname resolution, go with DNS.

But, if you want to have a standard list of users, groups, services, host names, etc., go with NIS.

Yes, NIS does somewhat introduce some security problems in that any user can do a 'ypcat passwd' and get your entire passwd file.

Comparing DNS and NIS is like comparing apples and oranges. There isn't a good comparison.

As I said, it just depends on what you are trying to accomplish.

[Sanjay Verma]

Hi Patrick,

In my scenario, DNS is already configured. Now, there are times when the Name resolution did not happen properly due to n/k or dns server issue. In order to have a fault tolerance and reduce downtime, what's the other alternative available?

Go for another DNS Server or go for NIS??
~Sanjay

[Patrick Wallek]

If you have multiple HP-UX machines, set a couple of them up as dns servers and set your resolv.conf up with the multiple servers so that if one is down it will go to the next.

[A. Clay Stephenson]

One of the main differences is one of scale. DNS is tree-based and can scale up to millions of addresses and reference other name servers on up the chain until a hostname is resolved or it fails. NIS is an essentially flat name space. One method is to combine both: NIS for local and then set /etc/nsswitch.conf to look in DNS if not found. Probably the most efficient though a little tougher to administer is to look for a small group of hosts in /etc/hosts, then check NIS, and finally DNS.

NIS is something of a security risk but if you are managing a large group of machine' it's really a lifesaver because you can manage user, groups, services, and automount maps. Many times I've used NIS for everything but name resolution which I left up to DNS.

Your other more secure option is NIS+ but very little of your NIS knowledge will transfer to NIS+; it's not much more difficult, it's just different.

[U.SivaKumar_2]

Hi,
Practically ,
For Name resolution , I would recommend to use
DNS not NIS.
For single point of administration of config files you can go for NIS.
Again considering security issues , I will avoid NIS and further give NIS+ or LDAP a try.

regards,
U.SivaKumar

[Sanjay Verma]

Thanks everyone for your time and effort. Yes, I liked the comments on executing "ypcat passwd" as a security issue.

Thanks everyone.

Cheers,
Sanjay

[Hartmut Petroll · Accepted solution]

Hi,
most off the bigger companies I know are using several DNS servers for the name resolution. It scales up to the internet!
But if you are considering to implement a directory service I personally would go with an LDAP server because most of the directory based software (e.g. IP telephony ...) has the possibility to use LDAP which is not true for NIS neither NIS+.

Kind regards
Hartmut

[W.C. Epperson]

For robustness of name resolution, DNS is really the only game in town. But as a distributed database, it has its quirks. Violating the standards for DNS data will often not result in failure but in erratically weird results. But most of the commonly made mistakes are in FAQs, so if you're clueful, you'll be all right.

NIS has tendencies to "break" in the presence of any network difficulties, and I've seen situations where the only way to get a server back on the farm was to remove NIS and reinstall. And it relies on RPC, so network security is an issue in addition to server security. Unlike LDAP, however, it's natively integratible into most *nixes.

LDAP is very robust and very cool, but can be difficult to install and support (at least the open source versions), and we've had data corruption and replication problems a number of times. And you have to dig around to find ways to integrate it into native *nix services.