On Tue, 5 Feb 2002, Paul M Foster wrote:
> Failing to reach the primary (fake) nameserver, won't this
> essentially result in the same thing, but with a slight delay? Are you
> saying that adding a fake internal DNS server to resolv.conf will keep
> telnet/ssh et al from causing the server to dail out?
... no -- I am saying that you may them snipp the iethernet on
the internal net, and see the query -- sniffinf the ppp0
interface is a bit harder
> It seems, from the posts on this thread, that DNS is the culprit here.
> But if DNS won't follow its own dang config file, doesn't it seem like
> it's well and truly broken? I mean this is a pretty simple problem--
> internal IP x asks for IP of machine y. Check host.conf.
There are several approaches to DNS and hosts.conf is an
vertigial appendix -- some old application may still use it,
but /etc/nsswitch.conf is (more) commonly referred to by the
resolver libraries -- compounding the matter is there is a BSD
and a SysV way of doing things, and they are (of course) not
totally consistent. The ancient Unix schisms and NIH syndrome
are in play as well.
> Says look at
> hosts file first. Look at hosts file. Is y there? Yes. Return
> appropriate IP. Do not pass go, do not collect $200. And whatever you
> do, don't try to query some internet name server. How hard could this
> be? Particularly when DNS has been around for so long?
>
> Or am I missing something?
dunno -- Before you found out that there are dark corners with
crufty code, did you feel like your life was incomplete?
<big grin>
I solve the problem by running a fully set up DHCP and DHS
pair of servers for my inside network -- but then, it is
completely possible that the link-up to upstream top-level DNS
servers would _still_ happen -- As I said, 80% of the time, it
is DNS.
-- Russ Herrold
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 15:42:31 EDT