Concrete case of DigiNotar
For the concrete case that depends on how deep the vulnerability was:
If the attackers were only able to access a program (web frontend) that signs any SSL server certificate, then only those sites are affected. Proper logging mechanisms would allow them to produce a complete list of all affected domains.
If they got access to the private key or the program allowed to create certificate with the CA bit set, then the attacker can create certificates for any site.
For the general case: Yes, the CA model in its current form depends on the trust of the weakest CA.
There are a number of CAs in the default list of the common browsers that are known to have issued bogus certificates for their respective governments in the past (most notable the BlackBerry Interception update in the United Arab Emirates) or got their lawful interception advertisement material leaked (most notable in the United States of America).
As far as I know DigiNotar is the only case in which a complete CA was removed from the browser list. In the other cases only the bogus server or software certificates have been revoked.
Jeff Ferland posted an excellent article on the security blog, A Risk-Based Look at Fixing the Certificate Authority Problem.
Convergence tries to mitigate the issue by recording server certificates from many different angles of the Internet. This assumes that the attacker is relatively close to the victim so that other notaries see the real certificate.
Instead of using a CA to sign server certificates, the certificates could be included in DNS, assuming that DNSSEC is widely adapted, which is not the case, yet.
Google hard codes the valid hashes into the source code of their Chrome browser calling it public key pinning. This approach obviously does not scale, they can only put a limited number high traffic sites in there.