On Tue, 2004-08-03 at 19:46, John Hall wrote: > It is possible some of the traffic you are seeing is the result of a site > using our 3-DNS global load balancing product. A clear indicator that > 3-DNS is responsible would be that the probes ID fields start at 1 and > increase by one for each packet in a set of probes. 3-DNS sends its probes > only in response to DNS queries and uses them to measure round trip time > and reachability from each data-center under 3-DNS's control to the client's > local DNS server. The data collected is used to direct other requests > using that local DNS server to the "best" data-center. You should > generally see > no more than 9 packets per hour per site using 3-DNS, although one of our > customers may have configured more aggressive probing (which we discourage). > 3-DNS does maintain a "do-not-probe" list to which you can be added, if > the 3-DNS's probe traffic is too obnoxious for you. Hello John, glad to see you guys are keeping up with all the current stuff going on in lists ;) I had sent a dump earlier. It is attached again below. The TCP SYN packets do indeed start with IPID 1 and move up to 3. However, these all come from the same IP address. Also, there doesn't appear to be anything in regards to "round-trip". I mean, your devices send the SYN's but nothing is coming back. Are you expecting DNS querying device to have an open DNS port on TCP and are expecting a SYN-ACK? That I can understand. But what the heck is the purpose of performing two DNS queries against the host that is querying a 3DNS balanced server? Seems a bit invasive to me for measuring trip time... :) In any case. I'm glad to see that there is a normal explanation for this, and this does not appear to be an attack mounted by China. Thanks for the info. Now we just need to find a decent IDS signature that allows your 3DNS probes to be ignored, but not render the IDS silent for related traffic (although I really would like to know when someone is probing my server for the "." zone.... Perhaps you guys could move to fixed IPID for those UDP queries or something?) Thanks again, Frank tcpdump: 21:16:15.434753 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok] 51621 NS? . (17) (ttl 44, id 51622, len 45) 21:16:16.194129 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok] 51622 NS? . (17) (ttl 44, id 51623, len 45) 21:16:16.932505 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok] 51623 NS? . (17) (ttl 44, id 51624, len 45) 21:16:18.431546 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok] 9949 PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9950, len 73) 21:16:19.186279 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok] 9950 PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9951, len 73) 21:16:19.939409 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok] 9951 PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9952, len 73) 21:16:21.433511 218.75.110.194.53 > x.x.x.x.33434: [udp sum ok] 10344 FormErr [0q] 0/0/0 (36) (ttl 44, id 10344, len 64) 21:16:22.196164 218.75.110.194.53 > x.x.x.x.33434: [udp sum ok] 10345 FormErr [0q] 0/0/0 (36) (ttl 44, id 10345, len 64) 21:16:22.995559 218.75.110.194.53 > x.x.x.x.33434: [udp sum ok] 10346 FormErr [0q] 0/0/0 (36) (ttl 44, id 10346, len 64) 21:16:24.448425 218.75.110.194.1758 > x.x.x.x.53: S [tcp sum ok] 3939495989:3939496013(24) win 2048 0 [0q] (22) (ttl 44, id 1, len 64) 21:16:25.208289 218.75.110.194.1794 > x.x.x.x.53: S [tcp sum ok] 3774103031:3774103055(24) win 2048 0 [0q] (22) (ttl 44, id 2, len 64) 21:16:26.005612 218.75.110.194.1821 > x.x.x.x.53: S [tcp sum ok] 992083552:992083576(24) win 2048 0 [0q] (22) (ttl 44, id 3, len 64) 21:16:27.441872 218.75.110.194 > x.x.x.x: icmp: echo request (ttl 44, id 32512, len 64) 21:16:28.191483 218.75.110.194 > x.x.x.x: icmp: echo request (ttl 44, id 32747, len 64) 21:16:28.949630 218.75.110.194 > x.x.x.x: icmp: echo request (ttl 44, id 32997, len 64) 21:16:41.758970 218.75.110.194 > x.x.x.x: icmp: echo request (ttl 44, id 36248, len 64) 21:16:42.166118 218.75.110.194 > x.x.x.x: icmp: echo request (ttl 44, id 36448, len 64) 21:16:42.898505 218.75.110.194 > x.x.x.x: icmp: echo request (ttl 44, id 36627, len 64)
Attachment:
signature.asc
Description: This is a digitally signed message part