As noted in comments, DSS strictly means the Digital Signature Standard, a document (FIPS 186) published by NIST, a part of the US government. The original version of FIPS 186 in 1994 defined (and was the original definition of) a single algorithm, DSA the Digital Signature Algorithm. Later versions of FIPS 186 added other algorithms primarily by reference to definitions elsewhere: RSA from X9.31 and later PKCS1, ECDSA from X9.62 (and SEC1). So technically DSS is now ambiguous as an algorithm identification, but quite a few standards including SSL (now TLS) were set using 'DSS' when it actually meant DSA and those names still survive because it would be a huge hassle to change them and everyone who matters knows what is meant.
In principle both DSA and ECDSA rely on the difficulty of finding discrete logarithms (or equivalently the one-way-ness of exponentiation) in appropriately structured finite groups. For DSA this group is a generated subgroup of the multiplicative group of integers modulo a large prime, notated $Z_p^*$. For ECDSA it is a subgroup (often 'improper' = the whole group) using 'addition' of points on a suitable elliptic curve over a suitable finite field -- either a 'prime' curve over $F_p$ represented/implemented as integers modulo p ($Z_p$) or a 'characteristic two' or 'binary' curve over $F_{2^m}$ represented as binary polymonials modulo a given irreducible polynomial. Although the point operation is usually notated as addition and the curve operation as scalar multiplication, these operations are not ordinary arithmetic addition and multiplication.
Although in abstract the same, there are practical differences due to the size and resulting strength of the 'parameters' used.
The original versions of FIPS 186 specified that p, the prime defining $Z_p^*$, should be 512 to 1024 bits in steps of 64 bits only, and the subgroup size $q$ only 160 bits. These sizes were sufficient in the 1990s, but as the 2000s passed they no longer provided sufficient margin of safety. FIPS 186-3 in 2009 belatedly increased standard sizes of p to 2048 and 3072 bits and q to 224 and 256, but it took some time for implementations to follow; as one notable example, Java 7 was supported until 2015 (and appears to still be in use today from Qs in stackoverflow and similar places) and limits p in DSA (and also DH!) to 1024 bits.
RSA similarly needs larger sizes now than it did in the 1980s and 1990s, but the standards for RSA never set a fixed maximum and most implementations allowed some (often a lot) of leeway. Thus when most standards and authorities -- and especially SSL/TLS CAs -- began requiring RSA-2048 instead of RSA-1024 in or soon after 2014, a lot of people had to generate new keys and certs but did NOT need to change their software (at least not for this reason).
In contrast ECDSA was initially defined with curves covering a range of sizes up to 500+ bits with strengths up to 250+ bits, and NSA adopted two of them (P-256 and P-384) in its Suite B, so practically everybody began using those two (or at least the first) which are strong enough.
As a result in general you can assume that if ECDSA (or ECDH) is used at all it is probably used with sufficiently strong parameters, whereas you can't always make this assumption for DSA and RSA. However for OpenSSL this is usually not a problem; due perhaps to lucky timing OpenSSL 1.0.0 was released in 2010 and included the increased FIPS 186-3 sizes, so unless you're on a really old system stuck at 0.9.x you're okay.
Another feature/limitation of both DSA and ECDSA is that they require each signature to use a nonrepeating and at least nominally random value (a nonce), and if you do repeat a value an adversary can easily recover your private key and forge signatures, which is Bad. There are proposals to change this including by our very own bear but not much progress yet. RSA signatures do not strictly require randomization, and the most-common (mostly because oldest) scheme RSASSA-PKCS1v1_5 does not use it at all (after key generation, which does require good randomness but is done rarely).
FWIW a similar naming issue occured with DES, which formally was the Data Encryption Standard document FIPS 46 from what was then NBS, and defined a single algorithm DEA the Data Encryption Algorithm (modified from IBM's Lucifer). As time passed and 56-bit keys became too short -- or at least more visibly too short -- the document FIPS 46 (DES) was revised to include TDEA the Triple Data Encryption Algorithm which many people called (and still call) Triple-DES even though it was not a separate standard. Then after AES (document) FIPS 197 was published defining AEA (algorithm, a profile of Rindael) FIPS 46 was withdrawn and TDEA (but NOT DEA) was republished as a Special Publication which is formally not a standard and thus formally DES and Triple-DES no longer exist. But both people and software and documents written in the past still refer to them, and many (like some SSL/TLS ciphersuites and OpenSSL, and also Java crypto) refer to TDEA as DESEDE or DES-EDE, sometimes with 3 attached somewhere, which were basically the nicknames used during a discussion period before TDEA was standardized; this is because both encrypt-decrypt-encrypt (EDE) and encrypt-encrypt-encrypt (EEE) constructions were seriously considered before the former was chosen.
