2 Days Left to Save $400 on SANS Cyber Defense Initiative 2014, Wash DC

Intrusion Detection FAQ: Analysis of the Type0 (Class 0) DNS that has been detected, version 1.0

Multiple sites have reporting seeing strange DNS packets in their traces with the form: 172.20.42.160 > dns-server.53: 0 [0q] Type0 (Class 0)? . (36)

The following is an early analysis by Howard Kash

This is a malformed DNS query with a query ID of 0, no questions, undefined query type 0, and undefined query class 0.

Further research reveals the following full packet trace (these are FDDI packets, so the IP header starts after byte 8):

10:10:13.558969 172.20.78.200.2400 > 
dns-server.53: 0 [0q] Type0 (Class 0)? . (36)
aaaa 0300 0000 0800 4500 0040 35f0 0000
f411 ee01 ac14 4ec8 c0a8 0270 0960 0035
002c 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000
10:10:13.559445 172.20.78.200.2401 >
dns-server.53: 256 [0q] Type0 (Class 0)? . (36)
aaaa 0300 0000 0800 4500 0040 35f2 0000
f411 edff ac14 4ec8 c0a8 0270 0961 0035
002c 0000 0100 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000
10:10:13.559526 172.20.78.200.2402 >
dns-server.53: 512 [0q] Type0 (Class 0)? . (36)
aaaa 0300 0000 0800 4500 0040 35f4 0000
f411 edfd ac14 4ec8 c0a8 0270 0962 0035
002c 0000 0200 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000
10:10:13.560117 dns-server.53 >
172.20.78.200.2400: 0 FormErr [0q] 0/0/0 (12)
aaaa 0300 0000 0800 4500 0028 437f 0000
3b11 998b c0a8 0270 ac14 4ec8 0035 0960
0014 d2f4 0000 8081 0000 0000 0000 0000
10:10:13.560287 dns-server.53 >
172.20.78.200.2401: 256 FormErr [0q] 0/0/0 (12)
aaaa 0300 0000 0800 4500 0028 4380 0000
3b11 998a c0a8 0270 ac14 4ec8 0035 0961
0014 d1f3 0100 8081 0000 0000 0000 0000
10:10:13.560373 dns-server.53 >
172.20.78.200.2402: 512 FormErr [0q] 0/0/0 (12)
aaaa 0300 0000 0800 4500 0028 4381 0000
3b11 9989 c0a8 0270 ac14 4ec8 0035 0962
0014 d0f2 0200 8081 0000 0000 0000 0000
10:10:13.635617 172.20.78.200 >
dns-server: icmp: 209.67.78.200 udp port 2400 unreachable
aaaa 0300 0000 0800 4500 0038 3614 0000
f401 edf5 ac14 4ec8 c0a8 0270 0303 5a07
0000 0000 4500 003c 7f43 0000 3211 0000
c0a8 0270 ac14 4ec8 0035 0960 0014 0000
10:10:13.635962 172.20.78.200 >
dns-server: icmp: 209.67.78.200 udp port 2401 unreachable
aaaa 0300 0000 0800 4500 0038 3616 0000
f401 edf3 ac14 4ec8 c0a8 0270 0303 5906
0000 0000 4500 003c 8043 0000 3211 0000
c0a8 0270 ac14 4ec8 0035 0961 0014 0000
10:10:13.636245 172.20.78.200 >
dns-server: icmp: 209.67.78.200 udp port 2402 unreachable
aaaa 0300 0000 0800 4500 0038 3618 0000
f401 edf1 ac14 4ec8 c0a8 0270 0303 5805
0000 0000 4500 003c 8143 0000 3211 0000
c0a8 0270 ac14 4ec8 0035 0962 0014 0000


There are always three queries with the query id equal to 0, 256, and 512. All other bytes in the DNS packet are null. The DNS server responds with a format error. One other distinguishing factor is that the starting source port number is always divisable by 100 (e.g. 2000, 2900, 3300, etc.) and increments by one for each of the three packets. Also, the DNS packet size in always 36 bytes.

Digging deeper, it appears they are also using TCP:

20:30:15.070616 172.20.78.202.3000 > dns-server.53: S 
1839760761:1839760825(64) win 2048
aaaa 0300 0000 0800 4500 0068 7985 0000
f406 9cb9 ac14 4eca c0a8 1004 0bb8 0035
6da8 8579 0000 0000 5002 0800 f842 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
20:30:15.070712 172.20.78.202.3001 > dns-server.53: S
1457081743:1457081807(64) win 2048
aaaa 0300 0000 0800 4500 0068 bee2 0000
f406 575c ac14 4eca c0a8 1004 0bb9 0035
56d9 4d8f 0000 0000 5002 0800 46fb 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
20:30:15.070804 172.20.78.202.3002 > dns-server.53: S
452098825:452098889(64) win 2048
aaaa 0300 0000 0800 4500 0068 1f9f 0000
f406 f69f ac14 4eca c0a8 1004 0bba 0035
1af2 7b09 0000 0000 5002 0800 5567 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
20:30:15.071483 dns-server.53 > 172.20.78.202.3000: S
2008000000:2008000000(0) ack 1839760762 win 31744
aaaa 0300 0000 0800 4500 002c 60bb 0000
3a06 6fc0 c0a8 1004 ac14 4eca 0035 0bb8
77af a600 6da8 857a 6012 7c00 50b9 0000
0204 0400
20:30:15.071785 dns-server.53 > 172.20.78.202.3001: S
2008064000:2008064000(0) ack 1457081744 win 31744
aaaa 0300 0000 0800 4500 002c 60bc 0000
3a06 6fbf c0a8 1004 ac14 4eca 0035 0bb9
77b0 a000 56d9 4d90 6012 7c00 a570 0000
0204 0400
20:30:15.072132 dns-server.53 > 172.20.78.202.3002: S
2008128000:2008128000(0) ack 452098826 win 31744
aaaa 0300 0000 0800 4500 002c 60bd 0000
3a06 6fbe c0a8 1004 ac14 4eca 0035 0bba
77b1 9a00 1af2 7b0a 6012 7c00 b9db 0000
0204 0400
20:30:15.145119 172.20.78.202.3000 > dns-server.53: R
1839760762:1839760762(0) win 0
aaaa 0300 0000 0800 4500 0028 ba2c 0000
3506 1b53 ac14 4eca c0a8 1004 0bb8 0035
6da8 857a 0000 0000 5004 0000 0080 0000
20:30:15.146193 172.20.78.202.3001 > dns-server.53: R
1457081744:1457081744(0) win 0
aaaa 0300 0000 0800 4500 0028 ba2e 0000
3506 1b51 ac14 4eca c0a8 1004 0bb9 0035
56d9 4d90 0000 0000 5004 0000 4f38 0000
20:30:15.146277 172.20.78.202.3002 > dns-server.53: R
452098826:452098826(0) win 0
aaaa 0300 0000 0800 4500 0028 ba30 0000
3506 1b4f ac14 4eca c0a8 1004 0bba 0035
1af2 7b0a 0000 0000 5004 0000 5da4 0000
20:30:15.164377 172.20.78.202.3000 > dns-server.53: R
1:1(0) ack 1 win 2048
aaaa 0300 0000 0800 4500 0028 6c62 0000
f406 aa1c ac14 4eca c0a8 1004 0bb8 0035
6da8 857a 77af a601 5014 0800 dabe 0000
20:30:15.164845 172.20.78.202.3001 > dns-server.53: R
1:1(0) ack 1 win 2048
aaaa 0300 0000 0800 4500 0028 3500 0000
f406 e17e ac14 4eca c0a8 1004 0bb9 0035
56d9 4d90 77b0 a001 5014 0800 2f76 0000
20:30:15.165504 172.20.78.202.3002 > dns-server.53: R
1:1(0) ack 1 win 2048
aaaa 0300 0000 0800 4500 0028 ca6c 0000
f406 4c12 ac14 4eca c0a8 1004 0bba 0035
1af2 7b0a 77b1 9a01 5014 0800 43e1 0000


Same source port pattern, and payload of SYN packet is always 64 null bytes. The connection is immediately reset after SYN ACK.

And even ICMP:

09:30:55.558457 172.20.78.200 > 
mail-server: icmp: echo request
aaaa 0300 0000 0800 4500 0054 2846 0000
f401 fba7 ac14 4ec8 c0a8 0270 0800 a948
cc00 0100 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 9f8e 6a38 75ef 0200
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000
09:30:55.558543 172.20.78.200 >
mail-server: icmp: echo request
aaaa 0300 0000 0800 4500 0054 2848 0000
f401 fba5 ac14 4ec8 c0a8 0270 0800 1648
cc00 0200 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 9f8e 6a38 07f0 0200
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000
09:30:55.558835 172.20.78.200 >
mail-server: icmp: echo request
aaaa 0300 0000 0800 4500 0054 284a 0000
f401 fba3 ac14 4ec8 c0a8 0270 0800 de47
cc00 0300 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 9f8e 6a38 3ef0 0200
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000
09:30:55.560114 mail-server >
172.20.78.200: icmp: echo reply
aaaa 0300 0000 0800 4500 0054 0658 0000
fe01 1396 c0a8 0270 ac14 4ec8 0000 b148
cc00 0100 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 9f8e 6a38 75ef 0200
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000
09:30:55.560188 mail-server >
172.20.78.200: icmp: echo reply
aaaa 0300 0000 0800 4500 0054 0659 0000
fe01 1395 c0a8 0270 ac14 4ec8 0000 1e48
cc00 0200 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 9f8e 6a38 07f0 0200
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000
09:30:55.560255 mail-server >
172.20.78.200: icmp: echo reply
aaaa 0300 0000 0800 4500 0054 065a 0000
fe01 1394 c0a8 0270 ac14 4ec8 0000 e647
cc00 0300 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 9f8e 6a38 3ef0 0200
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000


When asked about the traffic (Thanks Judy!) one of the offending ISPs sent the following boilerplate response:

Someone within your domain requested content from one of our clients. We do global load balancing and geographic routing based on QOS algorithms. We are using 3DNS servers by F5 Labs to acomplish global load balancing and geographic routing. What you are seeing are our 3DNS servers probing to gain performance statistics from your local DNS. The 3DNS server caches all LDNS statistics and path information from people hitting us, and continuously monitors performance between our architectures. The 3DNS servers use this information to resolve you to the closest location to connect to us. Giving the end user the fastest and best path to our multiple locations. This is the cause of the picture you see. The two IPs are Primary and Secondary DNS or shared interfaces, respectively.

We are not the developers of these fast emerging technologies and these are by no means new. We have leveraged the best technologies in these areas for over two and a half years now and as nice as they are for the delivery side, I understand the misunderstandings from the network admins in networks that are maintaining user-based Internet traffic.

If you would like additional information on these products you can go to the F5 Web site at http://www.f5.com.

I'm still skeptical, but it's the only logical explanation I can find. The packets appear to be harmless, but very persistant.