Same Question ...

Kevin Darcy kcd at daimlerchrysler.com
Fri May 25 22:13:27 UTC 2001


I think you are misdiagnosing the problem. It's not "on the server things
work, off the server they don't". From what you've shown, it's "meteore3
works and dnsx doesn't". The fact that meteore3 happens to be the default
nameserver for your Ultra-5 is coincidental.

So, next question: how is dnsx (the problem child) configured? Looks like it
has no knowledge of the 168.192.in-addr.arpa namespace and has recursion
turned off. Note that you have a duty to prevent bogus 168.192.in-addr.arpa
queries from leaking out onto the Internet. So please give dnsx knowledge of
the 168.192.in-addr.arpa namespace *before* enabling recursion on the box.

Of course, I'm assuming here that dnsx is supposed to have some form of
connectivity to the Internet DNS, either directly or by forwarding through
another server. If that's not true, then that's an even more fundamental
configuration problem: it shouldn't be configured with the Internet root
hints file at all in that case.

And please use "dig", as you've been told before. *Always*. nslookup sucks
and is complicating your troubleshooting here.


- Kevin

Desmond Coughlan wrote:

> I'm taking the liberty of asking this question again, as no one seems able
> to answer ...
>
> As far as I can make out, whilst logged on locally to the server, lookups
> function perfectly (I included the output from dig in an e-mail
> yesterday), within our local domain, and on company.us.com (which, as an
> aside, is a VPL linked to us by a leased line).
>
> The only problem now seems to be that if I point a machine at this new
> server, and tell it to use dnsx.company.internal.com (192.168.3.191) as
> its DNS server, it does not _answer_ queries.
>
> Example: my Ultra-5, on which I'm typing this.  I open a shell, and try a
> lookup of my own workstation's FQDN, using the DNS server that is in my
> workstations's /etc/resolv.conf :
>
>         $ nslookup foehn.company.internal.com
>         Server:  meteore3.company.internal.com
>         Address:  192.168.3.45
>
>         Name:    foehn.company.internal.com
>         Address:  192.168.3.31
>
> Now, if I try that same operation, but tell foehn to use dnsx, instead of
> meteore3 (which is our current primary for company.internal.com and the
> machine which dnsx is supposed to replace) :
>
> $ nslookup foehn.company.internal.com dnsx.company.internal.com
> Authoritative answers can be found from:
> (root)  nameserver = E.ROOT-SERVERS.NET
> (root)  nameserver = F.ROOT-SERVERS.NET
> (root)  nameserver = G.ROOT-SERVERS.NET
> (root)  nameserver = H.ROOT-SERVERS.NET
> (root)  nameserver = I.ROOT-SERVERS.NET
> (root)  nameserver = J.ROOT-SERVERS.NET
> (root)  nameserver = K.ROOT-SERVERS.NET
> (root)  nameserver = L.ROOT-SERVERS.NET
> (root)  nameserver = M.ROOT-SERVERS.NET
> (root)  nameserver = A.ROOT-SERVERS.NET
> (root)  nameserver = B.ROOT-SERVERS.NET
> (root)  nameserver = C.ROOT-SERVERS.NET
> (root)  nameserver = D.ROOT-SERVERS.NET
> *** Can't find server name for address 192.168.3.191: No information
> *** Default servers are not available
>
> So, _on the server_, things work the way they're supposed to.  It's when
> DNS lookups from a machine _other than_ the localhost arrive, that things
> go tits up.
>
> I'd appreciate your ideas.  :)
>
> D.
>
> --
> Desmond Coughlan               |Restez Zen ... UNIX peut le faire
> desmond at cybercable.fr          |YGL#4 YFC#1 YFB#1 UKRMMA#14 two#38
> http://www.chez.com/desmondcoughlan/
> Clé Publique: http://www.chez.com/desmondcoughlan/pgp/pubring.pkr





More information about the bind-users mailing list