[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
	- 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

> 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
> >> UH    0      0  0 eth2
> >> 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
>         netmask
>         network
>         broadcast
>         gateway
> auto eth1
> iface eth1 inet static
>         address
>         netmask
>         network
>         broadcast
> auto eth2
> iface eth2 inet static
>         address
>         netmask
>         network
>         broadcast
> 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, which is served by proxy arp iptables
> rules set by shorewall.
> >>   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.
> >>   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.
> >>         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
> >> nameserver
> AO> i assume your gateway can ping the above 2 ip#
> That gateway, 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= DST= 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
> network through it by DNAT) but seems to be always there
> and fast by proxy arp through the firewall from the
> 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: