From what I can understand from your question, there seems to be some confusion as to which is the role of a CA certificate in the public key infrastructure.
Since others have already addressed most of your questions, I'll try to quickly clarify some things for you. My explanation will be based on HTTPS (HTTP + TLS), but the concepts remain the same for similar setups.
Every certificate that is used in HTTPS is supposed to be signed by someone, so that it is considered valid. The signer is called a certificate authority ("CA"). Usually, there's a chain of CAs that sign a certificate, but let's keep things simple. So, how do you trust the CA's signature? You have the CA's public key (certificate) pre-installed in your browser, so that you can verify its signatures.
The key concept here is pre-installed. You cannot trust a CA's signature if you don't have its certificate. So, your browser comes bundled with a list of CA certificates that you should trust.
There are two things to note here:
- A CA's certificate is used for vouching (signing) that someone's certificate is valid
- A CA's certificate is not used to en-/decrypt traffic. This is the job of symmetric ciphers, whose key is derived by a form of the Diffie-Hellman (Merkle) protocol
So, to conclude: if someone breaks into your router and install her own CA certificate somewhere, it does not mean that she can decrypt the traffic flowing through the router. Even man-in-the-middle attacks are made impossible when the sites that are involved use valid certificates (i.e. signed by a trusted CA)
In the case of DNS hijacking there's one caveat (for the attacker): let's say that you ask for https://www.stackexchange.com. The router returns a fake IP where you connect. There, a malicious site sends you a fake certificate (posing as stackexchange).
Can they fool you? No, because the certificate they use is signed by a CA (their fake) that you don't trust.
Can they send the valid stackexchange certificate and use that to encrypt traffic and fool you? No, because in the initial handshake of the TLS protocol, the parameters exchanged between the two peers need to be signed, i.e. each side signs the parameters with the private key they have. Then the other peer verifies the signature with the public key of their counterpart. They trust the public key of their counterpart because that public key is signed by a CA that the peer trusts. This means that even if an attacker sends you the valid certificate from stackexchange, they cannot create a valid signature because they don't have the private key, which means that the protocol handshake breaks.
As such, if an attacker hijacks the DNS traffic to send their own DNS replies, and you only use encrypted communications, the best they can do is deny access to any site.
All in all, if you know that your browser is not compromised to include malicious CA certificates, you can be sure that your encrypted traffic cannot be decrypted by an attacker.