In order to connect to any website, through https or not, you need the ip address of the site, and you ask your DNS server for it using the domain name of your site. If your DNS server has not cached the answer, it will try to resolve your request by asking a whole series of DNS servers (the root dns server, the top level domain handler ... until the dns server that is authorative for the domain).
An attacker that controls any of those servers can respond to you with a fake IP address for that website, and this is what your browser will try to visit. This IP address in the general case will have a replica of the website hosted, to make it look the same as the original one, or just act as a silent forwarder of your connection to the correct site after capturing what it needs.
Now on to more details: If the website is HTTPS protected there will be many pitfalls. The normal website will have a certificate issued that binds details of the domain name to the website, but this is done using assymetric encryption.
What this means is that through the process of SSL handshake, the website has to prove that it has knowledge of the private key that is associated with the public key in the certificate. Now, the malicious party can very well serve you the original certificate of the website when you try to access the wrong IP under the correct hostname, but he will not have knowledge of the private key so the SSL handshake will never complete.
But there are ways for the interceptor to make the whole thing work, I can think of four:
1) The simplest solution is to serve you a self-signed certificate instead of a normal one. This will be issued by the attacker itself. Normally your browser will warn you about that, and if you run a recent browser version the warnings will be all over the place, but users tend to click-through that kind of stuff..
2) Another approach, used in the Stuxnet attacks, is to steal the private keys used for a valid certificate from the organization that you want to impersonate.
3) Another solution, that has happened in a couple of cases (we are not talking about the average attacker here) is that he exploits some fault in the registration procedure that certificate authorities (or registration authorities) use, and manages to issue a certificate for a website that does not belong to him. There have been cases that RAs simply did not do enough checks and issued certificates for google.com ..
4) Similar to the above: A competent attacker 'hacks' a certificate or registration authority and manages to issue some certificates under whatever name he wants. It happened in May of 2011 (the famous comodo-hack) and July of 2011 (the DigiNotar hack). See more details at How feasible is it for a CA to be hacked? Which default trusted root certificates should I remove? - IT Security.
5) Finally the most scary tecnique is the one that three letter agencies and similar parties can use: If a government controls a Certificate Authority, in theory it can force it to issue certificates at will, for whatever site. Now think that Certificate Authorities are spread throughout the world, some being in countries where this can seem very possible. An example to watch here is the CA operated by the Emirates Telecommunications Corporation (Etisalat), 60% owned by the United Arab Emirates (UAE) government. Etisalat once rolled out an innocuous looking BlackBerry patch that inserted spyware into RIM devices, enabling monitoring of e-mail.
In addition, if the client still supports the old SSL 2.0 protocol, a MITM can downgrade the SSL connection and use either a weaker symmetric encryption algorithm or a weaker key exchange.
So to sum up, if the attacker controls the DNS server he can do very malicious things, but for intercepting SSL encrypted traffic he needs something more than that.
And to answer your last question: The CA's site does not need to be resolved each time you visit a site: The website usually serves you the public certificate it uses itself, but it is possible that you get it from the CA instead. This does not change any of the mentioned things above though.