The main issue with the packet (see packet8.pcap) is the query for the

AAAA record of the string "null". "null" is not a top level domain. Note

that the query is not empty (which may be indicated by "null"). The origin

or purpose of the query isn't clear. Correlating the IDS alert with DNS

logs led to a "Unifi Cloudkey 2+", a video survailance server and network

management tool made by Ubiquity. Most likely, a query like this is 

caused by buggy software. It doesn't make much sense as a covert channel.

Google's DNS server would not foward the query to anybody but root DNS

servers. The only response you may get back is a list of root name servers.

But the source was not spoofed so this is not some form of amplification

attempt.

Couple readers pointed out some other properties of the packet:

The DNS query contains two additional items:

- EDNS Option 0: This option indicates that UDP replies may be as large

  as 1KBytes (we ran into this with packet 7).

- DNS Cookie: This is a fairly new option that is supposed to help

  with spoofing. The query includes a client cookie, but no server

  cookie. This either means that the server doesn't support DNS cookies,

  or that the client does not yet have a cookie from this server.