Message-ID: <41103E2B.5090304@f5.com>
From: j.hall at f5.com (John Hall)
Subject: FW: Question for DNS pros

Responses in-line...

Frank Knobbe wrote:

>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? 
>  
>
No, but most DNS servers *will* respond with a RST which is just as
valuable for reachability and RTT measurements.  We accept either
response.

>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 general, most sites use local forwarding DNS servers that do the
recursive lookups for all the clients at that site, so our probes
measure the RTT from each datacenter to that forwarding DNS server
and maintain that data so we can make intelligent decisions the next
time a client from that site (via that local forwarder) makes a request.

>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)
>  
>
That does look like a full set of 3-DNS probes.  We generally recommend
that our customers only configure two probe methods.  Looks like this 
guy has all of the probe methods configured.  Since your firewall doesn't
respond at all, it's trying each method in turn.  The traffic does look
like it's pretty low volume, so I guess your major concern is being
woken up at 4am with IDS alerts (at previous jobs I was a network
manager at an ISP and a fortune 500 company, so I know how you feel).
Currently, I don't know of any specific signature other than the ID
field that would help identify our "." probes.  I'll ask around.

JMH

-- 
John Hall              Test Manager - Switch Team             F5 Networks, Inc.

Powered by blists - more mailing lists