4 ms·
> 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 re
by 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 agoI 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 agoI 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 agoThis 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 agoHere 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 agoYou 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 agoNo, 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.