OK, so for those of us naive about DNS security, can someone summarize the current best practice for DNS on gateway routers and roaming endpoints (laptops)?
The short answer is: pretty much everyone uses normal DNS, because the many show-stopping problems with DNSSEC includes the insane design decision not to protect the "last mile" between the stub resolver on your own machine and the "DNS server" (technically: recursive cache) that DHCP configures.
If you're using Google's DNS, it will (pretty much pointlessly) validate DNSSEC records for you --- but the link between your computer and Google's DNS servers are completely unprotected (any attacker could simply trick your browser into believing there was no such thing as DNSSEC).
This doesn't much matter because only a tiny, tiny fraction of all DNS records are DNSSEC-signed. The modal experience for companies that do take the trouble to sign their DNS records is "taken offline completely by DNSSEC configuration mistakes". There is virtually no upside to participating.
The good news about all of this is that there's really nothing you need to do to have good DNS OPSEC. Just do what everyone else does, including pretty much all security people: delegate security to a higher layer of the Internet stack.
Google of course wants people to continue to use their DNS resolvers. So it is in their interest to focus only on techniques to improve access to their resolvers.
One thing that happened in recent years is that a very nice library called 'getdns' has been developed. Getdns does local DNSSEC validation but also contains various ways of accessing DNS servers and resolvers ("Roadblock Avoidance")
I use getdns in ssh for SSHFP, to obtain SSH key fingerprints from DNS. If DNSSEC doesn't work then SSH fails (or complains about an insecure connection). So far my experience is that is works.
The problem with DNSSEC local validation is that it doesn't protect your privacy.
So there are two techniques under development to address that. One is to run DNS directly over TLS. The second is to run DNS over HTTPS.
Running DNS over TLS has to advantage that the semantics are clear (just DNS over TCP but then encrypted) but the downside that the port may be blocked.
DNS over HTTPS is unlikely to get blocked, but there are too many ways to transmit DNS over HTTPS, so it may take some time for that to get sorted out.
Of course, moving DNS from a lightweight UDP exchange to TLS or HTTPS requires quite a bit more resources on the server side.
So, local DNSSEC validation works. It is just matter of turning it on. Server side, if the admins are behind a DNSSEC validating resolver then they quickly figure how to avoid breaking it.
When it comes to privacy, if you send all your DNS queries to Google, who else do you care about who might be watching your DNS traffic?
I know Google has supported an HTTPS bridge for DNS for a while (https://developers.google.com/speed/public-dns/docs/dns-over...) but I'm not aware of any router firmware or Mac/Windows/Linux software that supports it, is it out there?