First off I'd like to thank everyone who took the challenge and submitted their thoughts on the capture!  The response was overwhelming and I tried to answer everyone's email.  If I missed someone, please accept my apologies.  A thanks as well to Jon Wohlberg from Towson University who submitted this capture and allowed me to use it for the challenge.

I would also like to send a congratulations to the four individuals who figured it out:  Brandon Greenwood, Jean-Philippe Luiggi, Peter Koch and Richard Bejtlich.  As a side note,  Richard has a great paper entitled "Interpreting Network Traffic: A Network Intrusion Detector's Look at Suspicious Events".  Specifically look at the last part "A Final Case" which talks about this type of traffic.  

Last, but definately not least, thanks to Johannes Ullrich who looked at the initial traffic with me and helped to determine the initial answer .  Also, Scott Fendley who sat up very late with me one night while we dug through the second capture Jon submitted and worked to confirm our initial observations.  It was a great team effort!

Now for what you have really been waiting for....the answer to this traffic. (Drum roll please)

The tentative solution was initially determined from the capture that I posted with this challenge.  A later capture from Jon allowed it to be confirmed.  As a summary from what you were given: the traffic came from multiple IPs and all destined for one primary DNS server.  There were six characteristics of the traffic that you needed to take note of:

1.  The repeating IP ID which rotated using only 1, 2, or 3
2.  The windows size was a constant 2048
3.  The TTLs which were usually 44/45 or very close to that.
4.  It was always TCP connections to the primary DNS server.  No UDP traffic was captured from those IPs.  
5.  The 24 0x00 data bytes (keep in mind that these are SYN packets)
6.  The time stamps and source ports were also helpful in determining that these were not TCP retries.

Based on these characteristics and armed with Google, it is possible to solve the puzzle.  After much research, I found there were other folks questioning very similar traffic, but not totally sure of what it was.  There was alot of speculation to read through.  However, looking at the characteristics of the traffic, an answer quickly emerged.  It appeared to be traffic generated by a load balancer.  Here is the study that really led to our initial conclusion, although it did not match totally: 
http://www.sans.org/resources/idfaq/dns.php

Jon then sent us a second, more complete, capture that contained other information and allowed the initial conclusion to be confirmed and identify the load balancer being used.   F5 has a product called BIG-IP and one of the modules to that product is the Global Traffic Manager (formally known as 3-DNS, same functionality) is what generated this traffic.

Here are some other URLs of exactly the same traffic (to include
source IP) in order of reading recommendation:

http://archive.cert.uni-stuttgart.de/archive/intrusions/2002/09/msg00123.html
http://lists.dshield.org/pipermail/intrusions/2004-June/008100.html
http://lists.grok.org.uk/pipermail/full-disclosure/2004-August/024687.html  (read the entire thread)

Thanks again everyone for your participation and I hope that you learned as much from this capture as I did.  We automatically tend to assume traffic anomalies are up to no good when in reality, there may be a very logical explanation.  I have had many requests for more of these challenges.  It's good to know there are other folks out there who love to look at packets as much as I do.  I hope to do more of these in the near future so stay tuned!

UPDATE:  Frank Knobbe sent us the following.  Thanks Frank!

Ever since that fateful thread in FD, we had added Snort signatures for these probes to the BleedingSnort rules. They are in the SCAN category with SIDs 2001609-2001611.

A direct link is:
http://www.bleedingsnort.com/cgi-bin/viewcvs.cgi/sigs/SCAN/SCAN_F5_BIG-IP_Probe?rev=1.9&view=log

Latest version:
http://www.bleedingsnort.com/cgi-bin/viewcvs.cgi/sigs/SCAN/SCAN_F5_BIG-IP_Probe?view=markup