amiljkovicThe Ars article mentions: “Even when HTTPS is in place, an attacker can still intercept domain look-up traffic and use DNS cache poisoning to corrupt tables stored by the target’s operating system.” Not sure, but I think this could then be further used for phishing.
DNSSEC prevents that if set up properly.
This is an on-path attacker. In end-user DNS configurations, attackers can simply disable DNSSEC; it's 1 bit in the DNS response header ("yeah, sure, I verified this for you, trust me").
No, modern resolvers like systemd-resolved actually check the dnssec signatures on the client.
No, it's experimental. But I run it on all my machines, the only time I've had a problem is when it caught a typo in a DS record.
Nobody has ever disputed that you could run a fully recursive cache on your workstation, only that any ordinary user ever does.
You can see at this point how hollow "DNSSEC" is as an answer to the problem of this thread.
It's not a full recursive lookup: you don't understand how DNSSEC works. I'm not replying to you any more.
I'm guessing I do. Anyways: no question that there are a variety of experimental setups in which you can address the problem of on-path attackers trivially disabling DNSSEC, freeing you up to work on the next, harder set of DNSSEC security and operational problems.