researchtoolssurveys Factory


Originally noticed by Gadi Evron (gadi at 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 > [udp sum ok]  38262 [1au] A? (43) (DF) (ttl 243, id 17479,
23:01:37.866960 > [udp sum ok]  43233 [1au] A? (61) (DF) (
23:01:38.672156 > [udp sum ok]  5549 [1au] A? (38) (DF) (ttl 243, id 17481, len 6
23:01:39.086597 > [udp sum ok]  14728 [1au] A? (41) (DF) (ttl 243, id 17482, l
23:01:39.140012 > [udp sum ok]  20064 [1au] A? (48) (DF) (ttl 243, id 1
23:01:39.142028 > [udp sum ok]  21495 [1au] A? (52) (DF) (ttl 243, 
23:01:39.549047 > [udp sum ok]  33267 [1au] A? (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:


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 > [udp sum ok]  51408 [1au] A? (42) (DF) (ttl 243, id 32425, 
00:06:02.413774 > [udp sum ok]  23245 [1au] A? (39) (DF) (ttl 243, id 32493, len
00:06:02.792049 > [udp sum ok]  16864 [1au] A? (42) (DF) (ttl 243, id 32495, 
00:08:41.033152 > [udp sum ok]  802 [1au] A? (42) (DF) (ttl 243, id 32626, le
00:13:58.151163 > [udp sum ok]  45698 [1au] A? (42) (DF) (ttl 243, id 32827, 
00:14:03.384405 > [udp sum ok]  4010 [1au] A? (39) (DF) (ttl 243, id 32829, len 

and for 4-character first components:

23:59:41.327750 > [udp sum ok]  28196 [1au] A? (40) (DF) (ttl 243, id 32271, le
00:01:34.217419 > [udp sum ok]  38578 [1au] A? (40) (DF) (ttl 243, id 32345, le
00:01:34.554350 > [udp sum ok]  61215 [1au] A? (43) (DF) (ttl 243, id 32346,
00:01:44.431544 > [udp sum ok]  43359 [1au] A? (40) (DF) (ttl 243, id 32359, le
00:01:44.838770 > [udp sum ok]  8109 [1au] A? (43) (DF) (ttl 243, id 32360, 
00:02:17.275177 > [udp sum ok]  44889 [1au] A? (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 "", for example, which can be easily shown to not exist.

My theory is that they are not actually querying for "" but rather they are querying for "" (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.cs co.fx co.nt 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

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 (, to the source:

sfo2y-wessels ~ 21# ping -c 10
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=240 time=319.743 ms
64 bytes from icmp_seq=1 ttl=240 time=309.486 ms
64 bytes from icmp_seq=2 ttl=240 time=310.280 ms
64 bytes from icmp_seq=3 ttl=240 time=335.469 ms
64 bytes from icmp_seq=4 ttl=240 time=305.747 ms
64 bytes from icmp_seq=5 ttl=240 time=303.931 ms
64 bytes from icmp_seq=6 ttl=240 time=305.627 ms
64 bytes from icmp_seq=7 ttl=240 time=308.804 ms
64 bytes from icmp_seq=8 ttl=240 time=318.964 ms
64 bytes from 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.