If I protected myself from POODLE am I also protected against DROWN

POODLE is an abuse of a flaw in SSL 3.0. You are technically protected against POODLE if you disabled support for SSL 3.0.

DROWN leverages a flaw in SSL 2.0. You might be technically protected against POODLE, in the sense explained above, and still be vulnerable to DROWN.

Of course, SSL 2.0 has other flaws and it was already deprecated / forbidden; it has been so for a long time. The advice for POODLE was often worded as "deactivate everything that is older than TLS 1.0" and this includes SSL 2.0, but, honestly, SSL 2.0 should have already been deactivated, killed, and its corpse dumped at sea, long before POODLE. If you had to wait for POODLE to disable SSL 2.0, then you were already very very sloppy. There is no upper limit to sloppiness, so you are encouraged to test whether your server still accepts SSL 2.0. Just in case.

It depends.

You're vulnerable to DROWN if ANY server has the same RSA key as yours and is running SSLV2 and allows the low security "export cipher". Examples of this might be a certificate with multiple alternative names, or a wildcard certificate.

For example:

You disabled SSLV2 and SSLV3 on your webserver. Another admin in your organization, Bob shares the same SSL certificate with you, with both being signed with an alternative name, and thus share the same RSA key. Your server is www.mydomain.com running https, and Bob's server is email.mydomain.com, running SSL over SMTP.

Bob is a bit more sloppy about SSL, and didn't disable SSLV2 on his server. Since you both have the same RSA key, an attacker can use Bob's badly configured server to compromise the SSL security of your properly configured server.

Be aware that a recent OpenSSL version had a bug (CVE-2015-3197) that allowed a client to negotiate disabled cipher suites (such as SSLv2's EXPORT ciphers, for DROWN) even if they were disabled in OpenSSL at runtime. Make sure you're up to date (always a good idea anyhow, of course, especially with stuff like OpenSSL), and disable all versions of SSL. Don't forget to restart your server processes after updating the library, so it picks up the new version of the OpenSSL library.

Also, be aware that DROWN can be exploited across servers hosting different protocols (for example, using an email server to attack an HTTPS connection) if the other server supports SSL2 and is using the same public key as your web server. Since re-using public keys is reasonably common, and since secure connections to email servers (and similar) are usually not subject to as much scrutiny as web server connection security, you might still be vulnerable to DROWN even if your web server doesn't allow SSLv2.