On Tue, Feb 05, 2002 at 08:15:55PM -0500, Russ Herrold wrote:
> On Tue, 5 Feb 2002, Paul M Foster wrote:
>
> > > come into play -- tcpdmp would show the content of the query
> > > in question. Diald relied upon this behaviour to start
> > > sessions.
> > >
> >
> > I'm inclined to agree. I did a bunch of tcpdumping today, just getting
> > used to the output and experimenting. I don't know if it shows up in the
> > following dump, but I did see some rarping and arping going on. At home,
>
> ... close -- but on the wrong interface ... the DNS traffic is
> 'upstream' on the ppp interface. Add a 'fake' DNS server as
> the first listed in /etc/resolv.conf with an IP on the
> INTERNAL network on the gateway host, and it will be queried
> at first (and not being present, not respond -- so it will
> time out, and then query the second server...
I'll try this, but...
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?
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. 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?
Paul
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 15:40:12 EDT