A few commenters have mentioned using hdparm --secure-erase, which sends an ATA SECURE ERASE command, and I thought it's worth a bit more detail.
On self-encrypting drives, a secure enhanced erase command can be nearly instant, as it will simply change the on-disk encryption key, rendering all the existing data unrecoverable. For other drives, the secure erase command will internally, efficientialy write nulls over the entire drive, including remapped sectors. This last point makes it more secure than any other writing to the drive, as they cannot touch remapped sectors.
A modern 1TB drive takes around 3 hours to erase, and because you aren't consuming bus bandwidth to do this erasure (it's all on-drive), you can erase as many drives as you can attach to your system in the same 3 hours (eg, I've erased 16 drives at a time).
Both ATA SECURE ERASE and "simple" methods like a single pass of dd if=/dev/zero might seem less secure than tools that do multiple passes, however in 2006 NIST recommended that a single overwrite pass was enough to protect modern drives (eg, manufactured since 2001) from recovery. Furthermore, NIST states that ATA SECURE ERASE is sufficient to "render sanitized data unrecoverable by laboratory attack methods".
CMRR followed up with a tutorial on disk drive data sanitization. CMRR rate the security of a "SECURE ERASE" as better than the old DoD 5520 Block Erasure standard, as well as pointing out it is significantly quicker. (I believe DBAN used to use the same kind of method as the DoD 5520 standard - multiple passes with different bit patters. I can't actually find what DBAN does now, the docs seem very vague on this)
Detailed instructions on using hdparm to perform are at the libata wiki. There are other tools, such as HDDErase, or the -PdClear command for the megacli utilitity for managing LSI RAID controllers.
The CMRR report also states that, based on the NIST report, ATA SECURE ERASE is sufficient to meet the security requirements of HIPAA, PIPEDA, GLBA, Sarbanes-Oxley, and some others. I've seen other reports that suggest it's good enough for PCI compliances as well, but I trust that source slightly less, although I see no reason why it wouldn't be sufficient for PCI.