> > >> Mike Branda said:
> > >> > O.K. here goes. after muddling around for a bit now I am out
of ideas
> > >> > as to why this isn't working. I have set up an internal only
domain
> > >> > "my.fakedomain.local" and am having a minor issue. I can use
dig from
> > >> > the dns server to any machine listed in the zone and get the
proper
> > >> > answer and can do the same from any client machine as well as
reverse
> > >> > lookups. The caching from external web servers works also.
What I am
> > >> > having an issue with is that I can ping by IP and hostname for
the
> > >> local
> > >> > network machines from the dns box itself but pings only work by
IP
> > >> from
> > >> > the clients. Again, dig works on both dns and clients for
local
> > >> machine
> > >> > name lookups. Any ideas why I can't ping hostnames from
clients??
> > >> >
> > >> > Thanks.
> > >> >
> > >> > Mike
> > >>
> > >>
> > >> On Wed, 2004-12-01 at 13:56, Kerry Thompson wrote:
> > >> Mike
> > >> Some information on what the client OS is would help.
> > >>
> > >> (taking a punt that they are *nix) It sounds like the clients
have
> > >> /etc/resolv.conf configured, but /etc/nsswitch.conf hasn't got
"dns"
> > >> configured for hosts lookups. A key difference between dig/host
and
> > >> vanilla commands ( ping, telnet ) are that dig goes straight to
> > >> resolv.conf to find DNS servers, whereas ping uses normal
libraries to
> > >> read nsswitch.conf then oges to resolv.conf
> > >>
> > >> Kerry
> > >
> > >
> > >
> > > Mike Branda said:
> > > Kerry,
> > >
> > > here's what's in nsswitch.conf. it already had dns in the hosts
and
> > > networks lines. What's strange is that if I remove the nameserver
from
> > > resolv.conf, when I do "ping machinename" it immediately returns
"ping:
> > > unknown host machinename". But when the nameserver is there, it
takes
> > > about 15 seconds to return the same message.
> > >
> > > Mike
> > >
> >
> >
> > On Wed, 2004-12-01 at 14:50, Kerry Thompson wrote:
> > That delay sounds like its searching for the domain, in other words
the
> > client system doesn't know what domain its in.
> > Try pinging the fully qualified domain name eg.
> > machinename.your_domain.tld, and/or adding a 'domain' statement into
> > /etc/resolv.conf:
> >
> > domain your_domain.tld
> >
> > Kerry
> >
> >
> >
> >
>
> On Wed, 2004-12-01 at 15:14, Mike Branda wrote:
> I did both before joining the list. Ping doesn't work for short or
> fully qualified and the domain and search entries are both in
> resolv.conf. The server is set to listen on all interfaces right now
> for testing. Other than the related bind files, /etc/hosts and resolv
> are the same (with the exception of the hostname in hosts) on both
> client and server. www/external stuff works fine from the client with
> no problem. I'm assuming that's due to the root.hint servers.
External
> caching seems to be o.k. too from dig response times. Dig on the
client
> returns the properly associated IP in the answer section and the
reverse
> lookup (-x) returns the fully qual. domain name. No other internal
> services work....eg ssh,ping,http.
>
> Mike
>
Since I didn't get anywhere on our local list, I turned to the
bind-users list. The only reason I'm posting this is I know a lot of
people have recently installed SuSE 9.1 from the Novell eval pack and
this may pertain to you and anybody using a recent copy of Mandrake.
They have taken a new step in the way local network names are resolved.
So Here's what I've got in case anybody's interested. Somewhere along
the line I must have failed to mention that I'm using SuSE 9.1 as the
client. Herein lies the problem....apparently SuSE decided to go the
zeroconf route with /lib/libresolv.so.2 and anything that uses the
".local" top level automatically tries to go to multicast for
resolution. I'm still doing research as to solutions. One guy just
copied an older libresolv from 9.0 and that worked. Indeed it does.
I've tried it. But who know what else they've changed so That's going
to be a last resort until I get a chance to check the source. Other
options seem to be to pick another "fake" non-likely internal domain
name. Here's one of the more informative links that explains how this
has already been done in apple's Rendezvous and MS for multicast
lookups.
http://www.kalamazoolinux.org/pipermail/members/2004-September/011764.html
It seems this is an attempt to nuke the need for a local DNS server on
smaller networks.
Mike
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:08:51 EDT