Strange DNS Queries - Request Packets/Logs

Published: 2012-01-13
Last Updated: 2012-01-15 13:51:25 UTC
by Guy Bruneau (Version: 2)
8 comment(s)

We have received some strange DNS traffic sample Type A query that isn't your typical DNS format. The DNS query has some fields that do change are marked with a X (see DNS query pattern). Other format/pattern may exist since the capture was based on a very short capture. We are trying to establish what this traffic maybe doing, whether it is a messed up DNS resolver, some sort of command and control or covert channel.

If you have seen this type of DNS query with this kind of behavior, we would like to hear from you.

Update 1:

Handler Bojan wrote a diary last year about Google Chrome DNS prefetching [1], however, the DNS samples submitted to ISC (XXXXXXaaaaXXX0000pjaaaabaafaejam) don't match the format described in Bojan's diary.

However, I have found another example that is similar to our sample except it is only 10-char long vs 32-char [2]. So far, the only plausible explanation it might be DNS prefetching.


32-bit DNS Query Pattern


Sample Queries

omchikaaaaerd0000pjaaaabaafaejam: type A, class IN
ibjegdaaaaerd0000pjaaaabaafaejam: type A, class IN
ehjjafaaaaesx0000pjaaaabaafaejam: type A, class IN
dlegnhaaaaern0000pjaaaabaafaejam: type A, class IN
cfdnnoaaaaern0000pjaaaabaafaejam: type A, class IN



Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

Keywords: DNS Type A
8 comment(s)


Looks like a botched IPv6 query of sorts.
I had three of these today, all coming from IP addresses registered to Google.
Make sure these are google chrome DBS queries. Chrome will prefetch DNS and then do random DNS queries to verify the results aren't tampered with. See
DNS not DBS. Autocorrect fail. Aren't not are. Human fail.
Just to clarify; the queries were sent to our nameserver from clients using IP's registered to Google.
Log example:
14-Jan-2012 00:36:15.346 queries: client query: IN A -E
If these are Google Chrome queries, the the Chrome clients are within the Google network.
might be some sort of dns verification for some Google apps services

but Google's DNS verification of domain ownership for apps usually uses TXT records not A / AAAA records, unless Google is testing some new verification method...

another reason might be that there's a badly configured DNSSEC option somewhere...
Since DNSSEC was mentioned.. didn't Comcast roll out DNSSEC this week to residential customers?
Could possibly be a query from someone running dnsenum ( or similar tool. It does a wildcard check to look for a *.domain entry, the default test is "pseudorandabcdefuvwxyz0123456789". It doesn't match the pattern, but it matches the length.

Diary Archives