Barrages of Packet Errors

[<webmagician () altern org>]

Hopefully this is not an off-topic posting. I've scanned a variety of groups looking to see if anyone else has 
encountered a similar problem, to no avail, and I simply thought this might be the most appropriate place to post an 
inquiry.

I'm not a service provider, simply a small business operator with a few servers, providing business clients with mostly 
standard web and email type services. A couple of nights ago my systems started experiencing a sharp increase in DNS 
traffic generating a new flavor of error messages. I'd like to know if anyone else out there noticed similar DNS errors 
in the past couple of days.

The barrage first hit at roughly 9:15pm (Mountain Std Time) on June 28th and lasted only a few minutes.  It repeated 
again at 9:25pm, and then again at roughly 9:38pm, and a 4th round at 10:06pm. I fired up ethereal shortly after the 
4th battery in the hopes of capturing additional data, but there was no further activity, and I shut ethereal down the 
next morning (June 29th). However, later in the morning of the 29th the problem resurfaced, first at roughly 10am, then 
at 11:00am, 11:30am, and a final blast at 11:45am. Unfortunately I wasn't around during those barrages, so again I 
missed the opportunity to collect additional information - I only noticed it had happened while reviewing the server 
logs later that afternoon. The errors haven't re-occurred since.

The error messages are all the same (other than the inbound IP address causing the errors). The error message is as 
follows:
  "DNS Server encountered bad packet from 192.5.6.30. Packet processing leads beyond packet length."  

After extracting and sorting the error messages from the server log, I noticed the errors were associated with about 3 
dozen IP addresses. The list of IP's associated with the packets that were generating the errors is as follows:

128.63.2.53 = h.root-servers.net
128.9.0.107 = ns1.isi.edu
152.163.159.234 = dns-01.icq.net
192.112.36.4 = g.root-servers.net
192.12.94.32 = aloe.arin.net
192.203.230.10 = e.root-servers.net
192.228.79.201 = b.root-servers.net
192.26.92.30 = c.gtld-servers.net
192.33.14.30 = b.gtld-servers.net
192.33.4.12 = c.root-servers.net
192.35.51.32 = dill.arin.net
192.36.148.17 = i.root-servers.net
192.42.93.30 = g.gtld-servers.net
192.5.5.241 = f.root-servers.net
192.5.6.30 = a.gtld-servers.net
192.5.6.32 = a3.nstld.com
192.54.112.30 = h.gtld-servers.net
192.58.128.30 = j.root-servers.net
193.0.14.129 = k.root-servers.net
193.205.245.8 = dns2.nic.it
198.32.64.12 = l.root-servers.net
198.41.0.4 = a.root-servers.net
198.96.180.33 = ns1.bmo.com
198.96.183.6 = ns2.bmo.com
199.191.128.105 = cbru.br.ns.els-gms.att.net
199.191.145.136 = macu.ma.mt.np.els-gms.att.net
202.12.27.33 = m.root-servers.net
204.152.185.196 = west-pub.mail-abuse.org
205.188.157.232 = dns-02.ns.aol.com
205.188.157.234 = dns-02.icq.net
209.182.216.75 = ns1.gnac.net
209.237.237.10 = dns1-public.alexa.com
209.47.26.190 = ns.uunet.ca
216.239.34.10 = ns2.google.com
216.239.38.10 = ns4.google.com
35.9.116.13 = serv1.cl.msu.edu
64.4.240.70 = ns1.nix.paypal.com
64.4.240.71 = ns2.nix.paypal.com
64.4.244.70 = ns1.sc5.paypal.com
64.4.244.71 = ns2.sc5.paypal.com

I never assume anything happens "by chance" when it comes to anomalies in any of my systems log files, particularly 
when it's something brand new (I've never encountered this particular error in the past 7 years or so, so it set bells 
ringing to examine the problem more closely) (and there was nothing different or non-normal in the way of user activity 
or other processing, etc. at any time prior to or during these 'events'). My initial guess is it's someone trying out 
some new attack vector attempting to exploit yet another buffer overflow problem in windoze, but the strange thing is 
that the IP's are all (with the exception of a couple) associated with top-level domain servers (or am I mistaken in 
that assessment?). I'm not a network specialist by any stretch of the imagination, my skill-sets are in other areas, so 
I'm afraid I haven't much else to add in the way of information about this problem. I'm just looking to bring it to the 
attention of those who do have the knowledge/experience in this area in case it's a problem of some significance where 
forewarning may prove useful to others.

Thank you.

Brian Pederson
Chief Technology Officer
TeamWorx Productions Ltd.