Re: Re[4]: What can make DNS lookups slow?
hi ya chris
On Fri, 14 Jan 2005, Chris Evans wrote:
easiest way to solve the problem ( temporarily )
a) disable your firewall .. make it pass everything in and pass everything
out
- if that works .. than start figure out the firewall rules
b) i suspect removing the fw will not help, you will need to make sure
all machines have the same "gateway" to the outside
( what used to be the firewall )
the firewll in turn taks tot he ouside world
- use a simple 3-line masquerade firewall ( ipchains or iptables )
- the "firewall" should probably be running a dns or
/etc/hosts of all the ip# of all the machines
and that file copied to all machines
if you dont want to configure a dns for your local domain
c ya
alvin
> Friday, January 14, 2005, 9:08:37 AM, Alvin wrote:
>
> AO> hi ya chrsi
> Hi ya Alvin: huge thanks for persevering in helping me!
> I've changed the order of your questions in my responses as I think it
> may help us.
>
> >> Kernel IP routing table
> >> Destination Gateway Genmask Flags Metric Ref Use Iface
> >> 217.34.100.194 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
> >> 217.34.100.192 0.0.0.0 255.255.255.248 U 0 0 0 eth0
>
> AO> the above might be bad... to have those ip# going to 2 different ethernets
> OK, I agree that feels odd. I've always had this in
> /etc/networks/interfaces (I've pruned comments and blank lines):
> auto lo
> iface lo inet loopback
> auto eth0
> iface eth0 inet static
> address 217.34.100.197
> netmask 255.255.255.248
> network 217.34.100.192
> broadcast 217.34.100.199
> gateway 217.34.100.198
> auto eth1
> iface eth1 inet static
> address 192.168.1.1
> netmask 255.255.255.0
> network 192.168.1.0
> broadcast 192.168.1.255
> auto eth2
> iface eth2 inet static
> address 192.168.2.1
> netmask 255.255.255.0
> network 192.168.2.0
> broadcast 192.168.2.255
>
> The eth0 was created during the original debian install and the
> gateway is from the information that BT gave me. eth1 is the local
> area network which is DNAT served through the server by iptables set
> by shorewall 1.2, eth2 is the interface to the server machine
> www.psyctc.org, 217.34.100.194 which is served by proxy arp iptables
> rules set by shorewall.
>
> >> 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
>
> AO> good since its the "2.0" network
> Yes, and lookups through this interface, from the slow server in the
> dmz, seem generally to be fast.
>
> >> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
>
> AO> good since its the "1.0" network
> on which the damn windoze machines that I and wife have to use for all
> our work sit. Both lookup slowly but otherwise seem fine.
>
> >> 0.0.0.0 217.34.100.198 0.0.0.0 UG 0 0 0 eth0
>
> AO> good cause eth0 is the way to get out to the world ??
> Correct.
>
> AO> so anything on eth2 ( 192.168.2.xx ) will have occasional "slow problems"
> AO> ( aka timeout )
> AO> but everything on eth1 ( 192.168.1.x ) seems fine ??
> No, precisely the reverse.
>
> OK. I'm sure you're onto something there but damned if I understand
> it. With that in mind, back to the question you'd asked earlier....
>
> >> resolv.conf:
> >> nameserver 213.120.62.97
> >> nameserver 213.120.62.98
>
> AO> i assume your gateway 217.34.100.198 can ping the above 2 ip#
> That gateway, 217.34.100.198 is a dumb router box. I can ping it but
> not get into it to ping from it.
>
> Stepping back one. I can't ping almost anything beyond it from either
> the firewall machine or the dmz server (I get 100% packet loss) but I
> can get to just any www server beyond it for http or the like so I assume
> that BT (my ISP) have rules set to dump ping packets. I can traceroute
> to those addresses from the dmz but not from the firewall (from the
> firewall I get "traceroute: sendto: Operation not permitted" so I
> assume I've got something that traceroute needs blocked in my
> shorewall settings. The syslog message that appears to relate to that
> is:
> all2all:DROP:IN= OUT=eth0 SRC=217.34.100.197 DST=213.120.62.97 LEN=38 TOS=0x00 PREC=0x00 TTL=1 ID=61933 PROTO=UDP SPT=61932 DPT=33435 LEN=18
>
>
> I do definitely get lookups from those DNS servers from that machine
> but not reliably, they are often timing out today. I think the route
> is there but not reliably from the firewall machine directly (nor the
> 192.168.1.0 network through it by DNAT) but seems to be always there
> and fast by proxy arp through the firewall from the 192.168.2.0
> network. To me that seems very weird and probably diagnostic if I
> only knew enough about how iptables DNAT and proxy arp work.
>
> Thanks: any other thoughts or any of this help in any way?
>
> Chris
>
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: