From Nate Lawson's most recent entry:

Most public key systems fail catastrophically if you ignore any of their requirements. You can decrypt RSA messages if the padding is not random, for example. With DSA, many implementation mistakes expose the signer's private key.

(emphasis mine.)

Even small implementation mistakes are dangerous to crypto systems, but there are degrees of danger. Most of the time, 'all' that happens is that a bad implementation doesn't deliver either the encryption or the endpoint authentication that you thought you had; an attacker can decrypt your messages or impersonate a host. This is still bad, but it is not totally catastrophic.

DSA is not like that. As Nate Lawson has covered, a mistake by a DSA implementation that you use can directly give away your private key. It doesn't matter if your key was securely generated, and it doesn't matter if you only used the bad implementation briefly; your key is bad now. Generate and propagate a new one, provided that you realize that this has happened.

I have no opinion on whether RSA is theoretically stronger or weaker than DSA. I generate RSA keys instead of DSA keys regardless of the relative theoretical merits because all of the theoretical security in the world doesn't matter when all implementors have to get everything right or they give away the house, because they won't (and haven't).

Sidebar: when it is theoretically less dangerous to use DSA

In order to disclose a private key, a weak DSA implementation must actually have it. Thus, it is theoretically safe to use a local DSA key to authenticate yourself to a remote party if you trust your local implementation but don't entirely trust the other end. The most obvious case for this is personal SSH keys.

Still, I wouldn't do it. Why take chances if you don't have to?