Re[4]: What can make DNS lookups slow?

From: Chris Evans (stats_at_psyctc.org)
Date: 01/14/05

  • Next message: Florian Ernst: "Re: php5" 
    Date: Fri, 14 Jan 2005 10:11:40 +0000
To: debian-user@lists.debian.org

    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
  • Next message: Florian Ernst: "Re: php5"

    Relevant Pages

    • << SBS News of the week - Sept 26 >>
      ... And he points to the info you need to put the file on the server in the ... at the network perimeter. ... The Symantec Firewall/VPN and the Gateway Security ... by the firewall at risk. ...
      (microsoft.public.backoffice.smallbiz)
    • << SBS News of the week - Sept 26 >>
      ... And he points to the info you need to put the file on the server in the ... at the network perimeter. ... The Symantec Firewall/VPN and the Gateway Security ... by the firewall at risk. ...
      (microsoft.public.backoffice.smallbiz2000)
    • << SBS News of the week - Sept 26 >>
      ... And he points to the info you need to put the file on the server in the ... at the network perimeter. ... The Symantec Firewall/VPN and the Gateway Security ... by the firewall at risk. ...
      (microsoft.public.windows.server.sbs)
    • Re: RDP can not logon error
      ... Tracert & Ping to dc on the same subnet as the server that is having trouble. ... No network provider accepted the given network path.. ... Starting test: CrossRefValidation ...
      (microsoft.public.windows.server.general)
    • Re: need help re. office network install
      ... > and their network is a mess, the result of years of neglect. ... they have a gateway server w/ no special ... > firewall rules on it, they have a large DMZ that serves no purpose ... install anymore software on the firewall machine than is absolutely ...
      (comp.os.linux.networking)