RE: DNS woes

[Scott Stone <SStone@example.com>]

umm... no it's not :)  NIS is not Sun's alternative to DNS.  NIS is a local
database system for distributing system information such as password, group,
hostnames, automount maps, and other stuff.  DNS is still the way things
resolve external addresses, and many places use both in conjunction.

Now, the likelihood of you using NIS and NIS+ together is unlikely.
However, if ypbind is not running and glibc's nss module sees that there is
no NIS or NIS+ domain bound, it should pass over those things in
nsswitch.conf, so it's probably not going to slow things down all that much.


Now, if there IS a NIS domain bound and something's messing up there, that
can cause a slowdown...

> -----Original Message-----
> From:	Jonathan Q [SMTP:jq@example.com]
> Sent:	Saturday, May 12, 2001 6:25 AM
> To:	tlug@example.com
> Subject:	Re: DNS woes
> 
> Jean-Christian Imbeault (jean_christian@example.com) wrote:
> 
> > The order now is: file nis nisplus dns
> > 
> > I assume file means /etc/hosts ... I did take out nis and nisplus just
> in 
> > case and rebooted. No change.
> 
> If you're not going to run NIS, you should remove nis and nisplus
> altogether.  Moreover, in this configuration, lookups will
> attempt to check NIS first, but if you're not running it, this
> just makes lookups take longer.  Also, you wouldn't normally run
> both NIS and DNS, since NIS is Sun's alternative to DNS.
> 
> If you're going to keep nis and nisplus in there but aren't running
> it, it would be best placed after dns, so that NIS won't be
> checked for unless /etc/hosts and DNS lookups both fail.  That way,
> you only see a slower response in the even of failure.  In
> the event of success,  NIS will never be looked for.
> 
> 
> > PS Thanks for the patience! Problemed solved ... don't know why but the 
> > server installation on RH 7.1 disabled by default all (?) xinetd
> services.
> 
> I'm actually impressed by this.  I wish they did that on both
> workstation and custom installs as well.  Having all services disabled
> by default is the proper way to go, from a security perspective.
> No service that is not explicitly enabled by the installing admin
> should be enabled.
> 
> To that end, what the installer *should* do in any install type
> is to require the admin to explicitlky choose which services to 
> enable, and have information for novice admins on why you might
> or might not want to enable that service.
> 
> With that said, Red Hat's 7.1 installer does some very positive things
> compared to previous own-me-now Red Hat default installs.  Disabling
> all services by default in the server install is a very good thing,
> as is the option to enable firewalling during the install.  I don't
> understand, however, why they would choose to not disable all 
> services by default in other install types.  A worktation, after 
> all, is nearly as likely to be connected to the Internet as a 
> server, and is just as vulnerable to attack.
> 
> Jonathan
> 
> -----------------------------------------------------------------------
> Next Technical Meeting:  Sat, May 12 13:30- 
> Next Nomikai Meeting:    Fri, June (TBA) 19:30- Tengu Tokyo Eki Mae
> -----------------------------------------------------------------------
> more info: http://www.tlug.gr.jp           Sponsor: Global Online Japan