[lug] strange name resolving/ftp

[D. Stimits]

"D. Stimits" wrote:
> 
> ...
> >
> > I'm a bit ignorant of nsswitch.conf. For background, I do not run DNS or
> > bind on any machine. All machines point towards the ISP's DNS (and the
> > firewall blocks any DNS conversation with any machine other than those
> > of the ISP; I see lots of logged outside parties trying to reach my DNS
> > ports, probably for exploits). This machine has only an ethernet card,
> > and the machine it points to is not connected to the internet at the
> > time of test (it uses ppp dialup). But I think the relevant lines you'd
> > be interested in are:
> > hosts: files nisplus dns
> > ethers: files
> > netmasks: files
> > networks: files
> > protocols: files nisplus
> > rpc: files
> > services files nisplus
> > aliases: files nisplus
> ...
> 
> Additional note I forgot. I want the machines I use to consult
> /etc/hosts first, and then the outside DNS at the ISP. About 75% of the
> time the outside DNS is not available, but that's fine with me (I have
> to hang up the phone sometimes). Internal names resolving is the main
> thing, I'm trying to test client server software, as well as using the
> two as a partial backup of each other.
> 
> D. Stimits, stimits at idcomm.com

Ok, one more clue. If I run the "/etc/rc.d/init.d/network restart", I
find that /var/log/messages mentions this:
ifup: SIOCADDRT: Network is unreachable

Now, this could just be a reflection of what I am experiencing, and not
a real clue as to cause, but the particular signal SIOCADDRT might
narrow the cause down some (unfortunately there does not seem to be a
man page to "ifup", which I presume is being script wrapped in the
network restart script). But all interfaces are pingable by any name or
dotted-decimal format; it is access through ftp where it is bizarre (my
wu-ftp on this machine is set to allow without reverse name lookup, and
the host trying to access it is itself, not another host, so it is just
puzzling why I can use either 127.0.0.1 or localhost, but not both).

D. Stimits, stimits at idcomm.com