How would that protocol work? I'm not seeing how the DNS resolver would securely get the key info from the device. What if an attacker cloned the device's MAC and said to the resolver "hi, my new key is X"?

You're in a LAN. You can not trust any device there anyway, and stuff like DHCP is unencrypted, and anycast anyway.

Trying to add security in such an environment is... useless.

Why? The whole point of authentication and encryption is to allow secure communications over insecure networks. So what if DHCP is unencrypted? If you have E2E auth/encryption, all a malicious DHCP server can do is prevent your communications, it can't spy or MITM them.

If you have E2E auth/encryption, all a malicious DHCP server can is, indirectly, identifying every site you connect to, and potentially blocking you from accessing some sites. Or all. It can intercept all unencrypted stuff. This includes NTP, which in turn means your computer’s clock will be set wrong, which in turn means it can give you long distrusted certificates whose private keys have leaked.

TL;DR: If you can MitM a system at the root, you can already break basically anything relevant.

Yes, they can block me, but that's just annoying, not insecure. Intercepting unencrypted stuff is the reason for this whole thread. And if they change my computer's date, they might get one malicious cert working - assuming they can change it enough, since NTP has mechanisms for avoiding large leaps - but they'll break every single HTTPS connection besides that one, which I'm sure the user would notice almost immediately.

Meanwhile, routers are generally known to be insecure, and who knows how many viruses my guests bring onto my Wifi network when they ask to connect.