Both should be just as secure as it was previously. DNS just resolves domain names to ip addresses. This is completely separate from any security model, and OpenDNS is probably as trustworthy as the DNS you were getting from your local ISP.
When you go to a website, you type in a domain name (security.stackexchange.com.) which your browser than queries a DNS server to get an IP address (184.108.40.206). This tells your computer which address your request packets should be directed to over the open internet. Then your packets are routed over the open internet, so they should go to the computer that was assigned that IP address. By choosing to use OpenDNS you just are asking different computers what is the IP address of
security.stackexchange.com, whether you'll trust your ISP's DNS servers or OpenDNS's for these types of inquiries.
However, both of these systems could be subverted. The DNS record/response could be tampered with to direct you to the wrong IP address, or the routing that should go to 220.127.116.11 could be redirected by a malicious router to the wrong server. So in general you shouldn't trust regular old
But if you connect to your bank, you typically go to an HTTPS site (
https://www.yourbank.com). Most modern web browsers will display a Lock in the URL and have https in green, if your browser has a properly signed certificate issued from a trusted certificate authority (CA). Your web browser comes with a list of trusted CAs, and automatically checks that the certificate is valid, is trusted, and was issued to the domain name you wanted to go to. You will also be warned if the page doesn't have a properly signed certificate, or a certificate for the wrong site, or one that expired, etc. You should not do any sort of banking/credit card transactions over non-https connections. Furthermore, your https traffic will be encrypted, so eavesdroppers cannot listen in. You should be careful to make sure that the domain name of the
https is correct, e.g., its
https://www.yourbank.com as opposed to
ssh to a server that you have connected to in the past, you have the public key of the remote server stored on your computer in the
~/.ssh/known_hosts file. You will be warned if the remote server cannot answer a challenge for the public key (that the server could only answer if it has the corresponding private key) or if the public key changes. Thus after connecting to a ssh server once from a trusted computer, you can be assured that subsequent connections are to the same computer.
ssh also encrypts all traffic.