Antwort: Re: ping problems with BIND9 - SemiSolved

holger.honert at signal-iduna.de holger.honert at signal-iduna.de
Mon Dec 6 07:46:26 UTC 2004


Hi Mike,
ever thought about IPv6? Well I' ve got a problem with DNS-Timeouts and 
slow answers from the DNS-Client running on SuSE 9.1. With ethereal I 
found out that my client uses IPv6 DNS-questions instead of IPv4. I 
searched a long time for a solution in the web and a week or so ago I 
found the solution. You have to disable IPv6 in the /etc/modprobe.conf (of 
course, they changed the file name and a lot more used by modprobe)  file 
by adding a line after 

alias net-pf-10 ipv6

add the following line:

install ipv6 /bin/true

and you are done (hopefully). Maybe you check this also out! Good Luck for 
your troubleshooting!

Freundlichen Gruß/Kind Regards
 
Holger Honert
 
KOMN-97851
 
SIGNAL IDUNA Gruppe
Joseph-Scherer-Str. 3
 
44139 Dortmund
 
Phone: +49 231/135-4043
FAX: +49 231/135-2959
 
mailto: holger.honert at signal-iduna.de






Mike Branda <mike at wackyworld.tv>
Gesendet von: bind-users-bounce at isc.org
03.12.2004 20:03
 
An:           bind-users at isc.org
Kopie: 
Thema:        Re: ping problems with BIND9 - SemiSolved



> > >> 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
> 

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






More information about the bind-users mailing list