bind, ping and gethostip

English Network/Internet
#1

Hi all
I’m getting really crazy with one issue:
I’ve installed one dns server inside a openSuse 11.
I’ve tested it with a windows client, a fedora client, a debian client and everything was fine. But I’ve tested it with a openSuse 11 client and this weird thing happens:

linux:/# host portalweb.aula01.cntg.local
Host portalweb.aula01.cntg.local has address 10.61.154.30

linux:/# ping portalweb.aula01.cntg.local
ping: unknown host portalweb.aula01.cntg.local

dig worsk fine also resolving the ip successfuly
linux:/# dig portalweb.aula01.cntg.local
…
;; ANSWER SECTION:
portalweb.aula01.cntg.local 604800 IN A 10.61.154.30
…

portalweb.aula01.cntg.local has a apache server and mozilla can’t resolve the name also.
The weird thing is internet addresses work.

I searched something about nscd service and noticed gethostip is used to resolve dns questions and I tried:

linux:/# gethostip portalweb.aula01.cntg.local
portalweb.aula01.cntg.local: Unknown host

Is this a missconfiguration of nameserver?
I installed another bind9 into one debian r4 and the same thing happens: every client resolve dns queries, but openSuse.
Is this a gethostip issue?

Help… pleeeaaaseeee

#2

Mesigua wrote:

>
> Hi all
> I’m getting really crazy with one issue:
> I’ve installed one dns server inside a openSuse 11.
> I’ve tested it with a windows client, a fedora client, a debian client
> and everything was fine. But I’ve tested it with a openSuse 11 client
> and this weird thing happens:
>
> linux:/# host portalweb.aula01.cntg.local
> Host portalweb.aula01.cntg.local has address 10.61.154.30
>
> linux:/# ping portalweb.aula01.cntg.local
> ping: unknown host portalweb.aula01.cntg.local
>
> dig worsk fine also resolving the ip successfuly
> linux:/# dig portalweb.aula01.cntg.local
> …
> ;; ANSWER SECTION:
> portalweb.aula01.cntg.local 604800 IN A 10.61.154.30
> …
>
> portalweb.aula01.cntg.local has a apache server and mozilla can’t
> resolve the name also.
> The weird thing is internet addresses work.
>
> I searched something about nscd service and noticed gethostip is used
> to resolve dns questions and I tried:
>
> linux:/# gethostip portalweb.aula01.cntg.local
> portalweb.aula01.cntg.local: Unknown host
>
> Is this a missconfiguration of nameserver?
> I installed another bind9 into one debian r4 and the same thing
> happens: every client resolve dns queries, but openSuse.
> Is this a gethostip issue?
>
> Help… pleeeaaaseeee
>
>

Did you type in the dig response or cut&paste?

There should be a trailing dot after local.

portalweb.aula01.cntg.local. 604800 IN A 10.61.154.30

Check your bind/dns setup, as it’s not forgiving about periods. They have
great significance and the trailing dot is rather important to signify ‘end
of name’ (or something like that, been a while since I played with bind, I
cheat and use dnsmasq more often now)

Loni

L R Nix
lornix@lornix.com

#3

I’ve typed the response, and it’s true, there is a trailing dot:
portalweb.aula01.cntg.local. 604800 IN A 10.61.154.30

I’m thinking about to try with another dns server, but which one?

#4

Hi again.
I guess I know what is happening… or something like that: openSuse 11 has a bug

I’ve tested several clients against the domain name server installed into openSuse 11 (BIND): Windows Vista, fedora 9, openSuse 10.2, debian r4, redhat el 4 and every one works fine. Every one gets the pong of RRs, every one can surf the webs from servers defined in RRs… but openSuse 11 can’t do it.

openSuse 11 can do a telnet, but it can’t get a pong because it says “unknown host”, Firefox can surf internet (forwarded by BIND) but can’t surf servers registered in BIND… but lynx can do it.

This means some software can resolve dns queries but someother can’t do it… May be some library is asking to dns server and some other isnt… WAIT!!

Lets do some logging…

Client side:
ping portalweb.cntg.local

Server side:
Aug 7 14:10:13 cernunnos named[16288]: client 10.0.4.181#47462: query: portalweb.cntg.local.site IN A +

Client side:
host portalweb.cntg.local

Server side:
Aug 7 14:11:01 cernunnos named[16288]: client 10.0.4.181#60553: query: portalweb.cntg.local IN A +
Aug 7 14:11:01 cernunnos named[16288]: client 10.0.4.181#52790: query: portalweb.cntg.local IN AAAA +
Aug 7 14:11:01 cernunnos named[16288]: client 10.0.4.181#42191: query: portalweb.cntg.local IN MX +

The client domain is set to aula04.cntg.local, the fqdn of the client is ed04181.aula04.cntg.local
So, there is a bug what adds “site” suffix to every dns question.

Lets try another thing:

Client side:
host portalweb

Server side:
Aug 7 14:17:07 cernunnos named[16288]: client 10.0.4.181#56969: query: portalweb.aula04.cntg.local IN A +
Aug 7 14:17:07 cernunnos named[16288]: client 10.0.4.181#36148: query: portalweb.aula04.cntg.local IN AAAA +
Aug 7 14:17:07 cernunnos named[16288]: client 10.0.4.181#37291: query: portalweb.aula04.cntg.local IN MX +

Client side:
ping portalweb

Server side:
Aug 7 14:18:06 cernunnos named[16288]: client 10.0.4.181#49252: query: portalweb.site IN A +

:open_mouth: ping isnt reading the resolv.conf search parameter

Client side:
cat resolv.conf

search aula04.cntg.local site
nameserver 10.0.4.101

I’ve done a default network instalation, so I’ve noticed the setup for name and domain was linux-something site. I’ve changed it and the result is the same so I must say…

BUG!!

#5

Hi there.

Try adding

mdns off

to your /etc/host.conf file.

I had exactly the same problem and that fixed it.

#6

I must try it at work, but I’ve tested it 5 minutes ago with my virtual machines and it seems to work fine. Well, first pong is slow (4 secs) and the next pongs are ok ( 0,1 ms)

Bartlm, thank you so much!!

#7

It works!
Real machines resolve ping as fast as expected as soon as “mdns off” is set into /etc/host.conf

Thank you so much!

#8

Nevermind.
I looked whether i can find out more about the problem and i found a thing named zeroconf.
Domains ending on .local send their DNS requests automatically to 214.0.0.251 if mdns (multicast dns) ist switched on. Your local dns will never receive the request in this case.
I guess this is fixed in RFC 3030 or something.