Re: Re: 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
> 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
> >> 18.104.22.168 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
> >> 22.214.171.124 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 126.96.36.199
> netmask 255.255.255.248
> network 188.8.131.52
> broadcast 184.108.40.206
> gateway 220.127.116.11
> 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, 18.104.22.168 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 22.214.171.124 0.0.0.0 UG 0 0 0 eth0
> AO> good cause eth0 is the way to get out to the world ??
> 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 126.96.36.199
> >> nameserver 188.8.131.52
> AO> i assume your gateway 184.108.40.206 can ping the above 2 ip#
> That gateway, 220.127.116.11 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
> all2all:DROP:IN= OUT=eth0 SRC=18.104.22.168 DST=22.214.171.124 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?
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com