I was reading this article http://sockpuppet.org/blog/2015/01/15/against-dnssec/ and this line caught my eye, "With TLS properly configured, DNSSEC adds nothing." My gut reaction was to disagree, but the more I thought about it, I realized I couldn't think of a counter example. Granted I only have a cursory understanding of DNSSEC, but he seems correct. Am I missing something?
TL;TR: In some use cases like HTTPS (web) DNSSec is not really needed. In other use cases like SMTP (mail) DNS spoofing will not be noticed by TLS, that is man-in-the-middle is possible if DNS can be spoofed even if TLS itself is properly used.
When used within HTTPS (web) and the currently established CA system you don't need DNSSec, because the browser checks the name in the URL against the name in the certificate and validates the trust chain using a locally stored (pre-trusted) root-CA. But note that the proper issuing of the certificate itself might be affected by DNS spoofing (see below).
With SMTP (mail transport) the situation is different. To get the next hop within mail delivery a mail transfer agent (MTA) must know which server is responsible for which recipient domain. This is done by looking up the MX record in DNS. If this record can be spoofed (which can be done without DNSSec) then the MTA will deliver the mail to the wrong mail server. Even if delivery is done with TLS the sending MTA will not notice if the MX reports the attackers server as target server, because the hostname of the attackers server and the name inside the certificate will still match. A mechanism similar to MX for mail exists for SIP (VoIP) in the form of SRV records and it has thus the same problems.
Apart from that there are other protocols which rely on secured DNS. The most prominent is probable DANE which tries to replace the currently used but broken CA system with a system where the expected certificate is stored at the same place as the hostname, that is inside the DNS. The same way you could also store SSH host keys.
Also, in the current system with public pre-trusted CA most of the identity checks done when issuing a domain validated certificate can be forged if the attacker is able to do DNS spoofing at the right place. This includes the case where the domain validation is done with mail or where the validation is done by accessing a specific file on the site with HTTP only (because the site has no HTTPS yet). While in the first case the MX record will need to be spoofed you need to spoof A/AAAA or CNAME records in the second case. And once the attacker has got the certificate for the site in question the MITM attack against the site will not be noticed any longer.