10 ms·

Hum, DNSSEC is highly useful tho Both DNSSEC and DoT/DoH prevent hijack between the customer and the resolver However, only DNSSEC prevents hijacks between th

Hum, DNSSEC is highly useful tho Both DNSSEC and DoT/DoH prevent hijack between the customer and the resolver However, only DNSSEC prevents hijacks between the resolver and the authoritative servers DNSSEC is the only way to trust a zone's content Or maybe DoT/DoH shall be the only way to resolve things, and the DNS over UDP/TCP shall be deleted from the surface of the earth ?

ekr____ 3y ago
It's important to understand why one might care about trusting the zone's content. From the perspective of something like a browser, the mapping from the domain name to the IP address (i.e., the A or AAAA records) need not be secured via DNS because the connection to the server is secured via TLS and the WebPKI. So DNSSEC isn't helping here, especially because the clients don't check DNSSEC, so it doesn't protect them from attack on the local network, which is one of the main loci. If the DNS server provides the wrong IP, this is mostly a DoS attack. I am aware that the situation is somewhat different in email but I'm not sure how different really. Note that it is the case that DNSSEC could help secure ACME validation queries, but as tpacek observes, CT has greatly reduced the risk of misissuance. Of course there are other mappings in the DNS, but as a general matter those are being designed under the assumption that the DNS is untrustworthy, due to the low level of DNSSEC deployment. For instance, if you look at the HTTPS RR, it's fine to put a key for Encrypted Client Hello in it because the resolver already knows the desired domain name, so lying about the key doesn't really help. However, we can't safely publish the server's public key to be used for TLS 1.3 early data ("Zero RTT priming") because that would require trusting the DNS. So, any features which require the DNS to be secure have the usual chicken-and-egg deployment problems (this is also to a great extent what happened with DANE). Taking the opportunity to reference myself, the following longer writeups might be useful on this topic: https://educatedguesswork.org/posts/dns-security-dnssec/ https://educatedguesswork.org/posts/dns-security-dnssec/ https://educatedguesswork.org/posts/dns-security-dane/ https://educatedguesswork.org/posts/dns-security-dane/
PreInternet01 3y ago
> DNSSEC is highly useful tho Not as it's deployed today. Since over 80% (conservative guesstimate) of the zones that most people care about are not signed, it's pretty much useless. The 'evil ISP or IT MITMs my DNS traffic' scenario is much more effectively addressed with DoH (since it only requires clients and some resolvers to coordinate, not the entire Internet, and it looks like regular HTTPS, which implementers already understand how to deal with, as a bonus). And the 'evil government redirects some or all zones' play is still very much possible even with DNSSEC, since, guess who ultimately controls the keys. Even if you think that making the latter scenario more difficult to implement is worth it, getting more people to sign their zones is a losing battle, since they're very much likely to self-DoS themselves in the process, significantly reducing their enthusiasm...
- jeroenhd 3y ago
  > Since over 80% (conservative guesstimate) of the zones that most people care about are not signed, it's pretty much useless. Depends on where you live. Last time I checked, about 70% of the top 25k .nl domains were signed. .ch and .se also have a lot of DNSSEC domains.
  - PreInternet01 3y ago
    Yes, I'm aware of the .nl situation in particular, and... it only underscores my point? If those .nl domains dropped off the Internet tomorrow, that (while of course very inconvenient for lots of people) wouldn't cause more than a tiny dip in global traffic. The benchmark here is how much of, say .com and .net combined, is signed. And that's around 4% (4.5M signed zones out of a total 170M, give or take). Because of a well-intended mandate, most .nl domains are signed by their registrar, which generates and holds the private keys. So: the very same entity responsible for enabling domain delegation also secures that delegation. Virtually nobody generates and supplies their own DNSSEC keys when registering their .nl domain. So, a government looking for someone to lean on to modify a delegation, doesn't need to do that much extra work for such 'secure' zones, do they now? From a consumer perspective, visiting digid.nl (signed, probably with their own keys, kept in a nice HSM somewhere!) vs. ah.nl (not signed) offers no meaningful extra privacy or security: when not using DoH, their ISP and anyone else in the middle will still have a pretty good idea what they're up to, and can strip off the 'hey, tell me about your signature' bits in any requests, leaving the client unable to tell the difference in the first place in most situations. In case of a DNS hijack, the consumer security implications are exactly the same for both login (digid.nl) and shopping (ah.nl): their browser or app will refuse to connect, because DNS is already a negligible factor there, and it's the TLS certificate that makes the difference. That, combined with the very real danger that turning on DNSSEC makes a zone unresolvable for hours or even days on end, makes most people a bit wary about doing do. And they're absolutely right.
mike_d 3y ago
> However, only DNSSEC prevents hijacks between the resolver and the authoritative servers It does no such thing. An attacker on the resolver or between the resolver and authoritative is able to strip DNSSEC. DNSCrypt was the solution to all the problems we had, but at the time DNS software vendors and operators also had a financial interest in passive monitoring so DNSSEC being clear on the wire won.
- tptacek 3y ago
  I don't think that's really true at all, re the incentive story. DNSSEC (or, at least, the classic IETF DNS stack) has a story for encrypted transport; it's just that nobody ever wanted to deploy it.
  - mike_d 3y ago
    I don't want to dig up private discussions from a dozen years ago, but the DNS vendors that mattered at the time also had passive DNS/security products that paid the bills.
- JackSlateur 3y ago
  This is not true A recursive will drop unsigned responses from root servers. So that if a zone should be signed, then all unsigned answers are boggus and dropped. On unbound, for instance: harden-dnssec-stripped: <yes or no> Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes bogus. If turned off, and no DNSSEC data is received (or the DNSKEY data fails to validate), then the zone is made insecure, this behaves like there is no trust anchor. You could turn this off if you are sometimes behind an intrusive firewall (of some sort) that removes DNSSEC data from packets, or a zone changes from signed to unsigned to badly signed often. If turned off you run the risk of a downgrade at- tack that disables security for a zone. Default is yes.
  - mike_d 3y ago
    Here is an example of how that exact mark as insecure logic is used to downgrade/strip: https://i.blackhat.com/USA-22/Thursday/US-22-Heftrig-DNSSEC-Downgrade-Attacks.pdf https://i.blackhat.com/USA-22/Thursday/US-22-Heftrig-DNSSEC-... This is another example, using IP fragmentation: https://www.athene-center.de/forschung/publikationen/poster-off-path-dnssec-downgrade-attacks-4214 https://www.athene-center.de/forschung/publikationen/poster-... DNSSEC is also a huge foot-gun in that the end user just sees "the internet is broken." This leads to many recursive operators turning off DNSSEC validation when big zones break and eyeballs complain. Perfect homelab quality configurations are rarely deployed to the real world. It really is hot garbage and should be taken out behind the woodshed.

ekr____ 3y ago

It's important to understand why one might care about trusting the zone's content. From the perspective of something like a browser, the mapping from the domain name to the IP address (i.e., the A or AAAA records) need not be secured via DNS because the connection to the server is secured via TLS and the WebPKI. So DNSSEC isn't helping here, especially because the clients don't check DNSSEC, so it doesn't protect them from attack on the local network, which is one of the main loci. If the DNS server provides the wrong IP, this is mostly a DoS attack. I am aware that the situation is somewhat different in email but I'm not sure how different really. Note that it is the case that DNSSEC could help secure ACME validation queries, but as tpacek observes, CT has greatly reduced the risk of misissuance. Of course there are other mappings in the DNS, but as a general matter those are being designed under the assumption that the DNS is untrustworthy, due to the low level of DNSSEC deployment. For instance, if you look at the HTTPS RR, it's fine to put a key for Encrypted Client Hello in it because the resolver already knows the desired domain name, so lying about the key doesn't really help. However, we can't safely publish the server's public key to be used for TLS 1.3 early data ("Zero RTT priming") because that would require trusting the DNS. So, any features which require the DNS to be secure have the usual chicken-and-egg deployment problems (this is also to a great extent what happened with DANE). Taking the opportunity to reference myself, the following longer writeups might be useful on this topic: https://educatedguesswork.org/posts/dns-security-dnssec/ https://educatedguesswork.org/posts/dns-security-dnssec/ https://educatedguesswork.org/posts/dns-security-dane/ https://educatedguesswork.org/posts/dns-security-dane/

PreInternet01 3y ago

> DNSSEC is highly useful tho Not as it's deployed today. Since over 80% (conservative guesstimate) of the zones that most people care about are not signed, it's pretty much useless. The 'evil ISP or IT MITMs my DNS traffic' scenario is much more effectively addressed with DoH (since it only requires clients and some resolvers to coordinate, not the entire Internet, and it looks like regular HTTPS, which implementers already understand how to deal with, as a bonus). And the 'evil government redirects some or all zones' play is still very much possible even with DNSSEC, since, guess who ultimately controls the keys. Even if you think that making the latter scenario more difficult to implement is worth it, getting more people to sign their zones is a losing battle, since they're very much likely to self-DoS themselves in the process, significantly reducing their enthusiasm...

jeroenhd 3y ago
> Since over 80% (conservative guesstimate) of the zones that most people care about are not signed, it's pretty much useless. Depends on where you live. Last time I checked, about 70% of the top 25k .nl domains were signed. .ch and .se also have a lot of DNSSEC domains.
- PreInternet01 3y ago
  Yes, I'm aware of the .nl situation in particular, and... it only underscores my point? If those .nl domains dropped off the Internet tomorrow, that (while of course very inconvenient for lots of people) wouldn't cause more than a tiny dip in global traffic. The benchmark here is how much of, say .com and .net combined, is signed. And that's around 4% (4.5M signed zones out of a total 170M, give or take). Because of a well-intended mandate, most .nl domains are signed by their registrar, which generates and holds the private keys. So: the very same entity responsible for enabling domain delegation also secures that delegation. Virtually nobody generates and supplies their own DNSSEC keys when registering their .nl domain. So, a government looking for someone to lean on to modify a delegation, doesn't need to do that much extra work for such 'secure' zones, do they now? From a consumer perspective, visiting digid.nl (signed, probably with their own keys, kept in a nice HSM somewhere!) vs. ah.nl (not signed) offers no meaningful extra privacy or security: when not using DoH, their ISP and anyone else in the middle will still have a pretty good idea what they're up to, and can strip off the 'hey, tell me about your signature' bits in any requests, leaving the client unable to tell the difference in the first place in most situations. In case of a DNS hijack, the consumer security implications are exactly the same for both login (digid.nl) and shopping (ah.nl): their browser or app will refuse to connect, because DNS is already a negligible factor there, and it's the TLS certificate that makes the difference. That, combined with the very real danger that turning on DNSSEC makes a zone unresolvable for hours or even days on end, makes most people a bit wary about doing do. And they're absolutely right.

mike_d 3y ago

> However, only DNSSEC prevents hijacks between the resolver and the authoritative servers It does no such thing. An attacker on the resolver or between the resolver and authoritative is able to strip DNSSEC. DNSCrypt was the solution to all the problems we had, but at the time DNS software vendors and operators also had a financial interest in passive monitoring so DNSSEC being clear on the wire won.

tptacek 3y ago
I don't think that's really true at all, re the incentive story. DNSSEC (or, at least, the classic IETF DNS stack) has a story for encrypted transport; it's just that nobody ever wanted to deploy it.
- mike_d 3y ago
  I don't want to dig up private discussions from a dozen years ago, but the DNS vendors that mattered at the time also had passive DNS/security products that paid the bills.
JackSlateur 3y ago
This is not true A recursive will drop unsigned responses from root servers. So that if a zone should be signed, then all unsigned answers are boggus and dropped. On unbound, for instance: harden-dnssec-stripped: <yes or no> Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes bogus. If turned off, and no DNSSEC data is received (or the DNSKEY data fails to validate), then the zone is made insecure, this behaves like there is no trust anchor. You could turn this off if you are sometimes behind an intrusive firewall (of some sort) that removes DNSSEC data from packets, or a zone changes from signed to unsigned to badly signed often. If turned off you run the risk of a downgrade at- tack that disables security for a zone. Default is yes.
- mike_d 3y ago
  Here is an example of how that exact mark as insecure logic is used to downgrade/strip: https://i.blackhat.com/USA-22/Thursday/US-22-Heftrig-DNSSEC-Downgrade-Attacks.pdf https://i.blackhat.com/USA-22/Thursday/US-22-Heftrig-DNSSEC-... This is another example, using IP fragmentation: https://www.athene-center.de/forschung/publikationen/poster-off-path-dnssec-downgrade-attacks-4214 https://www.athene-center.de/forschung/publikationen/poster-... DNSSEC is also a huge foot-gun in that the end user just sees "the internet is broken." This leads to many recursive operators turning off DNSSEC validation when big zones break and eyeballs complain. Perfect homelab quality configurations are rarely deployed to the real world. It really is hot garbage and should be taken out behind the woodshed.