10

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?

Scott C Wilson
  • 543
  • 3
  • 11
mercurial
  • 898
  • 1
  • 9
  • 17
  • It may help for the generation of the certificate, with DNSSEC your reduce the risk of an attacker spoofing your DNS to a CA. – Tom Jan 08 '17 at 13:41

1 Answers1

11

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.

Details:

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.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 2
    If you do not actually trust all of the CAs your browser trusts (IOW if you suspect the enormous list of pre-trusted CAs contains some rogue or compromised CAs) then DNSSec *does* improve security for HTTPS, as a combination of DNS spoofing and a corresponding certificate from a pre-trusted but untrustworthy CA would go unnoticed. – Tilman Schmidt Nov 24 '15 at 00:09
  • 1
    If an attacker can spoof or alter responses from your DNS servers (or the tld you use) they can send fake responses to a CA and get a domain validated (or email validated) certificate for your domain. – JasperWallace Nov 24 '15 at 00:46
  • 1
    @JasperWallace No, just because an attacker can spoof _you_ (maybe you're on a public wifi network that they control), that doesn't mean they can also spoof a CA that is running its own recursive DNS servers. – Mike Scott Nov 24 '15 at 06:58
  • The part about hijacking the process of issuing the certificate is important. I've incorporated it into the answer. Thanks a lot. – Steffen Ullrich Nov 24 '15 at 07:08
  • How does an attacker spoof the MX record in the DNS query response if it's served over TLS from a trusted DNS server? Or does the victim have to use attacker's DNS server for the attack to succeed? (in which case TLS is pretty irrelevant) – libertylocked Oct 26 '18 at 00:01
  • @libertylocked: This several year old question is not about DNS over TLS (DoT, which is a pretty new thing). It is about application traffic over TLS (like in HTTPS, SMTP+STARTTTLS) and DNS using the traditional unprotected way, i.e. plain UDP or TCP on port 53, without any DNSSec or TLS involved. – Steffen Ullrich Oct 26 '18 at 02:20
  • "In some use cases like HTTPS (web) DNSSec is not really needed." Except when someone is able to change the zone content (by hijacking nameserver IP addresses, or having access to some webportal where you configure the zone content, etc.) and put whatever IP it wants there for the website, after what it can get a DV certificate from a trusted CA without problems, and then HTTPS will merely show everything OK where you finally only reached the goal to encrypt your content towards an unknown third party! DNSSEC solves that, especially when CAs start to use a validating resolver at cert issuance. – Patrick Mevzek Aug 01 '19 at 15:18