[this-is-why]

Even if they can rewrite the MAC and force a new one via ping, which are usually already disabled, they still can’t eavesdrop on the TLS key exchange. I fail to see how this is a risk to HTTPS traffic? It’s a mitm sure but it is watching encrypted traffic.

[amiljkovic]

The 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.

[jcalvinowens]

DNSSEC prevents that if set up properly.

[tptacek]

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").

[jcalvinowens]

No, modern resolvers like systemd-resolved actually check the dnssec signatures on the client.

[tptacek]

To check the DNSSEC signatures on the client, you have to do a full recursive lookup. You've always been able to run your own DNS cache, if you want your host to operate independently of any upstream DNS server. But at that point, you're simply running your own DNS server.

[jcalvinowens]

It's not necessarily equivalent to a recursive lookup, you can ask a cache for all the answers because you already know the root keys a priori. But yes, it does follow the entire chain of trust, that's the entire point of dnssec: if you don't do that the whole exercise is utterly pointless.

[akerl_]

Can you link to a distro config that defaults to that?

[jcalvinowens]

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.