Re: resolver latencies return in Mozilla 1.6

From: Alex (xfb52_at_dial.pipex.no_bananas.com)
Date: 01/20/04

  • Next message: Alex: "Re: resolver latencies return in Mozilla 1.6" 
    Date: Tue, 20 Jan 2004 12:23:45 +0000

    Donn Miller wrote:
    > Alex wrote:
    >> I have similar problems. I have watched the packets going out and I
    >> see mozilla sending IPv6 address queries (querytype=AAAA) which my
    >> ISP's DNS server keeps rejecting. After a while I guess mozilla gives
    >> up and sends a simple IPv4 address query (querytype=A) at which point
    >> everything runs normally.
    >
    >
    > One interesting thing to do is to try setting log_in_vain="1" in
    > The reason is to see if you're getting
    > repeated messages like
    >
    > Connection attempt to UDP 192.168.0.105:49705 from 63.67.120.14:53
    > [...]
    > I get all kinds of messages like these, while the DNS lookups are
    > "hanging" in Mozilla. As you can see, it looks like Mozilla is
    > serializing DNS lookups, because it looks my ISP's DNS servers are
    > attempting to connect via different ports.

    I'm not sure that 4.9 supports log_in_vain, but I think I see the same
    behaviour when I turn logging on for relevant firewall packets.

    What I see is:
            Mozilla sends AAAA request -> DNS
            11:46:51.510233 82.41.37.129.1208 > 62.31.64.39.53:
                    6183+ AAAA? ad.uk.doubleclick.net. (39)

            DNS sends some kind of failure
            11:46:53.513503 62.31.144.39.53 > 82.41.37.129.1207:
                    6183 ServFail 1/0/0 CNAME[|domain] (DF)
            
            Then for reasons not understood by me localhost sends and ICMP unreachable
    (mozilla not actually listening on this port???)
            11:46:53.513698 82.41.37.129 > 62.31.144.39:
                    icmp: 82.41.37.129 udp port 1207 unreachable (DF)

            Then the procedure repeats with another port number, often one higher but not
    always (which looks like what you were describing).

            Eventually, after several tries mozilla sends an A DNS request
            11:47:19.950171 82.41.37.129.1212 > 62.31.64.39.53:
                    6184+ A? ad.uk.doubleclick.net. (39)

            Which mozilla seems to get a valid address from
            11:47:19.957988 62.31.64.39.53 > 82.41.37.129.1212:
                    6184 2/0/0 CNAME[|domain] (DF)

    Sometimes some of this conversation seems to be missing. The tcpdump output
    isn't easy to read.

    What's weird is that for these failing conversations my firewall doesn't seem
    to see the incoming UDP packet. So around the time this failing conversation
    was going on it saw:

            Jan 20 11:46:47 cartman /kernel: ipfw:
                    8200 Accept UDP 62.31.64.39:53 82.41.37.129:1205 in via sis1
            Jan 20 11:46:47 cartman /kernel: ipfw:
                    5600 Accept ICMP:3.3 82.41.37.129 62.31.64.39 out via sis1
            Jan 20 11:46:51 cartman /kernel: ipfw:
                    8000 Accept UDP 82.41.37.129:1208 62.31.64.39:53 out via sis1

    Notice the pot number gap between 1205 and 1208 exactly where the failure is
    going on -- port 1207.

    At this point I don't think I understand enough about what's going on to know
    how to proceed, but it does seem to me that if those AAAA requests were never
    sent, then the delays wouldn't be there. What isn't clear is why some of
    these requests go through so much quicker:

            11:46:26.660701 82.41.37.129.1192 > 62.31.64.39.53:
                    6173+ AAAA? www.londonnet.co.uk. (37)
            11:46:26.682620 62.31.64.39.53 > 82.41.37.129.1192:
                    6173 0/1/0 (97) (DF)
            11:46:26.682929 82.41.37.129.1193 > 62.31.64.39.53:
                    6174+ A? www.londonnet.co.uk. (37)
            11:46:26.704725 62.31.64.39.53 > 82.41.37.129.1193:
                    6174 1/0/0 A 217.158.99.83 (53) (DF)

    Same sequential port numbers, but no ICMPs, no "ServFail" packet (whatever
    that is) and all resolved in a fraction of a second.

    I have no idea why this happens only sometimes. I took me twenty or thirty
    goes to find a site which caused a delay. Especially annoying that it was an
    advert site which caused the resolution problems.

    No-one else seems to be chipping in to this conversation. Any ideas about
    other places to try?

    --Alex

  • Next message: Alex: "Re: resolver latencies return in Mozilla 1.6"

    Relevant Pages

    • DNS server behind a firewall
      ... I have a DNS server behind a router/firewall. ... All tcp packets from ports 1024: to port 53 if they originate ... from trusted DNS servers ...
      (comp.os.linux.security)
    • Re: Port scan by DNS normal?
      ... BackTrace the IP address belongs to my ISPs DNS server. ... Protocol = UDP ... The destination port of those packets is> 1024, ...
      (comp.security.firewalls)
    • Re: ISPs dns to firewall box
      ... I didn't let those packets pass through and they died eventually, ... > Jason wrote: ... >> I am wondering why my ISP's DNS keep sending packets from their port 53 ... > You send queries to port 53 on the DNS server, ...
      (comp.os.linux.security)
    • NT Compromise -- Update -- SRC PORT: 53 traffic
      ... I should mention that the packets were flooding our DNS server, ... traffic to saturate and bring down our T1. ... port 53 was not the DST port, rather, the SRC port of each packet. ...
      (Incidents)
    • Re: cant configure networking for static IP address
      ... I test the network configuration: ... before doing this first ping the first hop - the default gateway from ... I can't ping the DNS server ... they might only allow dns packets to these ...
      (Debian-User)