5 ms·

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 dropp

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.
- JackSlateur 3y ago
  You do not think an attack shall be prevented, for the user's best interest ? We shall just let the man-in-the-middle go on, transparently ? I do not agree with you.
  - mike_d 3y ago
    No, I think that is very important which is why I fight against DNSSEC. Have a look at DNSCurve, it solves many of the problems DNSSEC was attempting to address but with proper transport security. We implemented this at OpenDNS back in 2010 so it would opportunistically use it if available.

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.

JackSlateur 3y ago
You do not think an attack shall be prevented, for the user's best interest ? We shall just let the man-in-the-middle go on, transparently ? I do not agree with you.
- mike_d 3y ago
  No, I think that is very important which is why I fight against DNSSEC. Have a look at DNSCurve, it solves many of the problems DNSSEC was attempting to address but with proper transport security. We implemented this at OpenDNS back in 2010 so it would opportunistically use it if available.