researchtoolssurveys Factory

LARGE DOMAIN SEARCH LISTS CONSIDERED HARMFUL

Originally noticed by Gadi Evron (gadi at tehila.gov.il). This is also documented as OARC incident 10331

A few DNS clients seemed to be trying to query all possible names in a large number of 2LD and higher zones. For example: 

23:01:35.214791 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  38262 [1au] A? aaaaaif.gov.is. (43) (DF) (ttl 243, id 17479,
23:01:37.866960 202.113.20.87.35090 > 224.161.108.85.53: [udp sum ok]  43233 [1au] A? aaaaaaaaaaaaaaaaaaaaagv.bz.co.fr. (61) (DF) (
23:01:38.672156 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  5549 [1au] A? aif.cn.aq. (38) (DF) (ttl 243, id 17481, len 6
23:01:39.086597 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  14728 [1au] A? aif.cn.co.aq. (41) (DF) (ttl 243, id 17482, l
23:01:39.140012 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  20064 [1au] A? aaaaaaaaaaig.org.hr. (48) (DF) (ttl 243, id 1
23:01:39.142028 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  21495 [1au] A? aaaaaaaaaaaig.org.co.sk. (52) (DF) (ttl 243, 
23:01:39.549047 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  33267 [1au] A? aaaaaaaaaaig.org.co.hr. (51) (DF) (ttl 243, i

Note that these primarily show up at authoritative TLD servers because any referrals from the roots have been obeyed and cached.

These "aaaaa" requests come from a few IP addresses:

  • 202.113.20.87
  • 54.53.83.164
  • 72.137.202.29
  • 14.146.69.11
  • 8.182.35.83
  • 224.184.222.110

These clients also send normal, answerable queries, such as for nameserver addresses and MX records, so they appear to be legitimate caching nameservers (probably BIND), rather than a custom hack tool.

When looking at all the queries from a source, it is hard to find a pattern. However, if you separate them by length of the first query name component, you can clearly see how they are sequential. i.e., for 3-character first components: 

00:04:04.376442 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  51408 [1au] A? aig.com.co.il. (42) (DF) (ttl 243, id 32425, 
00:06:02.413774 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  23245 [1au] A? aig.com.ao. (39) (DF) (ttl 243, id 32493, len
00:06:02.792049 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  16864 [1au] A? aig.com.co.ao. (42) (DF) (ttl 243, id 32495, 
00:08:41.033152 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  802 [1au] A? aig.com.co.bg. (42) (DF) (ttl 243, id 32626, le
00:13:58.151163 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  45698 [1au] A? aig.com.co.hr. (42) (DF) (ttl 243, id 32827, 
00:14:03.384405 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  4010 [1au] A? aig.com.si. (39) (DF) (ttl 243, id 32829, len

and for 4-character first components: 

23:59:41.327750 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  28196 [1au] A? aaig.com.ae. (40) (DF) (ttl 243, id 32271, le
00:01:34.217419 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  38578 [1au] A? aaig.com.ao. (40) (DF) (ttl 243, id 32345, le
00:01:34.554350 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  61215 [1au] A? aaig.com.co.ao. (43) (DF) (ttl 243, id 32346,
00:01:44.431544 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  43359 [1au] A? aaig.com.aq. (40) (DF) (ttl 243, id 32359, le
00:01:44.838770 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  8109 [1au] A? aaig.com.co.aq. (43) (DF) (ttl 243, id 32360, 
00:02:17.275177 202.113.20.87.35090 > 148.168.190.28.53: [udp sum ok]  44889 [1au] A? aaig.com.nl. (40) (DF) (ttl 243, id 32377, le

they seem to be querying for first-component lengths from 2--26.

It is really strange that they would keep querying for names in "com.ae", for example, which can be easily shown to not exist.

My theory is that they are not actually querying for "aaig.com.ae" but rather they are querying for "aaig.com" (with gethostbyname()) and a large search list in a resolv.conf file causes queries for that name with a lot of TLDs appended. Presumably this has been done by an ISP so their users can type "google" in browsers, etc. 

search ae ao aq bg br ca co.ao co.aq co.bg co.br co.cs co.cv co.cz co.eh co.fr co.fx co.hr co.il co.kp co.nl co.nt co.ph co.si co.sk co.zr cs cv eh fj fr fx hr il in is kp md na nl np nr nt ph pn pt ro si sk zr
nameserver 202.113.20.87
nameserver 54.53.83.164

Further evidence supporting this thoery is found in the inter-arrival time distribution of queries from these sources:

There is a sharp spike at 250-500 milliseconds, which corresponds to the RTT from this name server (senna.isc.org, piquet.isc.org) to the source: 

sfo2y-wessels ~ 21# ping -c 10 202.113.20.87
PING 202.113.20.87 (202.113.20.87): 56 data bytes
64 bytes from 202.113.20.87: icmp_seq=0 ttl=240 time=319.743 ms
64 bytes from 202.113.20.87: icmp_seq=1 ttl=240 time=309.486 ms
64 bytes from 202.113.20.87: icmp_seq=2 ttl=240 time=310.280 ms
64 bytes from 202.113.20.87: icmp_seq=3 ttl=240 time=335.469 ms
64 bytes from 202.113.20.87: icmp_seq=4 ttl=240 time=305.747 ms
64 bytes from 202.113.20.87: icmp_seq=5 ttl=240 time=303.931 ms
64 bytes from 202.113.20.87: icmp_seq=6 ttl=240 time=305.627 ms
64 bytes from 202.113.20.87: icmp_seq=7 ttl=240 time=308.804 ms
64 bytes from 202.113.20.87: icmp_seq=8 ttl=240 time=318.964 ms
64 bytes from 202.113.20.87: icmp_seq=9 ttl=240 time=320.813 ms

In other words, it looks like the source does not send more than one query at a time. It waits to get the NXDOMAIN from a query before trying the next one in the search list, as we would expect in this case.