The trusted CA list, that browsers (and other TLS clients) have, consists of a list of the CA public keys. They don't need to connect to the CA to access the key. This mechanism can be extended by importing the public key of other CAs (Corporate or Private) that you wish to trust.
The certificate authorities do maintain lists of revoked certificates. It is necessary to contact the CA to check to see if a certificate has been revoked. The results of this check can be cached, so it is not necessary to check every time a certificate is seen. It is not necessary at all if the site uses OSCP stapling to provide a signed verification.
It might be possible to spoof the DNS to redirect revocation requests. However, it would be extremely difficult to provide a properly signed response.
There is a risk that someone might convince a CA to provide a certificate that does not belong to the organization stated in the certificate. This is one reason for certificates to be revoked. There are mechanisms for organizations to publish the certificate authority or authorities that are permitted to sign their certificates.
It is possible to make the described attack more difficult by revoking trust for most of the default certificates. This should cause the browser to issue an alert if it receives a certificate signed by an untrusted CA. CAs are now aware of this issue and are unlikely to issue certificates for sites using this attack. Browser provider are likely to remove any CAs found to be issuing certificates used in such attacks.
The described attack is unlikely to succeed if you are browsing to sites using URLs from bookmarks or recently seen sites. The spoofed URLs will look good to you, but the browser doesn't care what the URL looks like.