6 ms·

In case it isn't clear from reading the article PDF or this HN thread, DNSSEC doesn't encrypt DNS. If you want encrypted DNS, DNSSEC isn't the answer, because D

by Panino 5y ago

In case it isn't clear from reading the article PDF or this HN thread, DNSSEC doesn't encrypt DNS. If you want encrypted DNS, DNSSEC isn't the answer, because DNSSEC doesn't encrypt DNS. The main thing DNSSEC does is create outages.

jeroenhd 5y ago
> The main thing DNSSEC does is create outages. It was not that long ago that the same thing was being said about TLS. I like my DNS to be validated. I don't see what the big problem with that is. Just don't enable the checkbox in your DNS resolver if you hate it that much.
- tptacek 5y ago
  First, TLS outages pop a warning box up on your screen, and DNSSEC outages make your site entirely disappear from the Internet. So that's a difference. But the bigger difference is, TLS gets you an encrypted secure channel between the client and the server, and DNSSEC gives you... a signed name lookup. DNSSEC's risks are larger, and the rewards far smaller.
  - moviuro 5y ago
    > First, TLS outages pop a warning box up on your screen, and DNSSEC outages make your site entirely disappear from the Internet. So that's a difference. Meh. If you handle your site correctly, you have at least HSTS, in which case, TLS errors are also game-over. If you don't have HSTS, well I have bad news for you. The other point stands though (risks are higher and rewards lower for DNSSEC).
  - GuidoW 5y ago
    > TLS gets you an encrypted secure channel between the client and the server, and DNSSEC gives you... a signed name lookup. I respectfully disagree with that second part. The risks for DNSSEC/DANE might be higher, the rewards are bigger too. TLS gives me a secure channel only when I connect to the right (i.e. expected) server. A TLS encrypted and validated connection to a wrong party is the threat here. As user, I don't know which is the CA for any given domain. And Chrome only caches a small subset. Otherwise we wouldn't need neither CAs or DANE, self signed certificates would suffice ;-) Either I have to trust that there are vigilant parties that monitor all CT logs against fake certificates or my user agent does that for every connection, blocking when it finds double certificates. With DNSSEC and DANE, my agent fetches the address and CA for the site and validates these against the TLS handshake. From there, HSTS will protect future lookups so it becomes a TOFU issue. Besides, the middle-box problem is being resolved with DOH over TLS1.3, isn't it?
  - jeroenhd 5y ago
    A TLS outage shows all of your visitors a big, red warning message saying "Attackers might be trying to steal your information from example.com (for example, passwords, messages, or credit cards)". Such a warning is a great way of scaring away any business's visitors for good. A DNSSEC outage shows a message saying "this site cannot be reached at the moment, try again later". I'd much rather have people see the latter than the former. Signed DNS lookups are quite important for any use of DNS for domain metadata storage, for example in systems like DKIM or SPF. Neither is encrypted, neither is signed in any other way, yet together they control if you can send emails at all, or if your server will get (near) permanently banned from Outlook's spam filters. There are also various PTR records for auto-configuration of various protocols that can easily redirect traffic to other hosts were a victim to get a spoofed version. We might have abandoned DANE, but there's still important information in DNS. Until we abandon DNS somehow (and I shudder to think what the alternative would be with the way the internet is ruled by Google and Facebook right now), I disagree that the risks are far smaller as you say.
    - tptacek 5y ago
      A DNSSEC outage does not show a message that "the site cannot be reached at the moment, try again later". It shows the same message that you'd get if the site doesn't exist at all, because that's the result of a failed DNSSEC resolution: the site doesn't exist.

by Panino 5y ago

jeroenhd 5y ago

> The main thing DNSSEC does is create outages. It was not that long ago that the same thing was being said about TLS. I like my DNS to be validated. I don't see what the big problem with that is. Just don't enable the checkbox in your DNS resolver if you hate it that much.

tptacek 5y ago
First, TLS outages pop a warning box up on your screen, and DNSSEC outages make your site entirely disappear from the Internet. So that's a difference. But the bigger difference is, TLS gets you an encrypted secure channel between the client and the server, and DNSSEC gives you... a signed name lookup. DNSSEC's risks are larger, and the rewards far smaller.
- moviuro 5y ago
  > First, TLS outages pop a warning box up on your screen, and DNSSEC outages make your site entirely disappear from the Internet. So that's a difference. Meh. If you handle your site correctly, you have at least HSTS, in which case, TLS errors are also game-over. If you don't have HSTS, well I have bad news for you. The other point stands though (risks are higher and rewards lower for DNSSEC).
- GuidoW 5y ago
  > TLS gets you an encrypted secure channel between the client and the server, and DNSSEC gives you... a signed name lookup. I respectfully disagree with that second part. The risks for DNSSEC/DANE might be higher, the rewards are bigger too. TLS gives me a secure channel only when I connect to the right (i.e. expected) server. A TLS encrypted and validated connection to a wrong party is the threat here. As user, I don't know which is the CA for any given domain. And Chrome only caches a small subset. Otherwise we wouldn't need neither CAs or DANE, self signed certificates would suffice ;-) Either I have to trust that there are vigilant parties that monitor all CT logs against fake certificates or my user agent does that for every connection, blocking when it finds double certificates. With DNSSEC and DANE, my agent fetches the address and CA for the site and validates these against the TLS handshake. From there, HSTS will protect future lookups so it becomes a TOFU issue. Besides, the middle-box problem is being resolved with DOH over TLS1.3, isn't it?
- jeroenhd 5y ago
  A TLS outage shows all of your visitors a big, red warning message saying "Attackers might be trying to steal your information from example.com (for example, passwords, messages, or credit cards)". Such a warning is a great way of scaring away any business's visitors for good. A DNSSEC outage shows a message saying "this site cannot be reached at the moment, try again later". I'd much rather have people see the latter than the former. Signed DNS lookups are quite important for any use of DNS for domain metadata storage, for example in systems like DKIM or SPF. Neither is encrypted, neither is signed in any other way, yet together they control if you can send emails at all, or if your server will get (near) permanently banned from Outlook's spam filters. There are also various PTR records for auto-configuration of various protocols that can easily redirect traffic to other hosts were a victim to get a spoofed version. We might have abandoned DANE, but there's still important information in DNS. Until we abandon DNS somehow (and I shudder to think what the alternative would be with the way the internet is ruled by Google and Facebook right now), I disagree that the risks are far smaller as you say.
  - tptacek 5y ago
    A DNSSEC outage does not show a message that "the site cannot be reached at the moment, try again later". It shows the same message that you'd get if the site doesn't exist at all, because that's the result of a failed DNSSEC resolution: the site doesn't exist.