The question of truth is not a technical one at its core, so you can never fully answer a question such as "Should I trust X", specifically if you add "... not to do action Y in some Z distant future".
Specially since in your question you seem both unsure about the provider itself, and what happens on the path between the provider and you.
If you want to be more in control of your resolution process you have mainly no other choice than running your own recursive caching nameserver, either on your host directly, or on some other one that you would trust. Especially if you want to fully ascertain to use features provided by DNSSEC: if you use a distant validating nameserver you trust it to do all the DNSSEC calculations correctly for you.
So I will not even try to assess if
220.127.116.11 (CloudFlare) or
18.104.22.168 (Google) or
22.214.171.124 (IBM+PCH+GlobalCyberAlliance) or OpenNIC or any other on https://en.wikipedia.org/wiki/Public_recursive_name_server or elsewere is trustworthy or more trustworthy than another one. It is also a hugely personal opinion (who do you give your trust to), and it shifts over time.
Your assertion "but it definitely would not scale to every household." is not so clear cut. The movement is more and more for people to handle their DNS resolution in house (or forward to one of the previous public one), and the root servers have plenty of capacity. Note that the problem may not lie there in fact as this zonefile moves slowly, is small, and cached everywhere. The problem could be far more at some TLD nameservers, like
.COM, where the zonefile has both millions of entries and regular changes that may not be small.
You have various options on the table, that you can sometimes mix and match:
- Use QNAME minimization (supported by some of the above public services) on the nameservers you are using. This gives less information to each nameserver while leaving the DNS protocol to work exactly as before
- You can use the now standard DNS over TLS to be able to query any nameserver offering you that (again some of the public one do, or are planning to do) or even "soon" DNS over HTTPS. By doing so, of course, you just move the problem: you are safe against hijackers in the path, but you need to establish authentication of the endpoint you are exchanging with; again, simpler if you manage it yourself.
- Some are advising to just use "multiple" public DNS servers, in a random fashion (so that none of them gets all your traffic), and even comparing results
- You also have some more subtle tools, like Stubby (using the getdns API) that attempts to give you the best features privacy-wise but can also be configured to fall back to earlier insecure mechanism if you favor availability over security. Software like dnssec-trigger also tries to give you DNSSEC benefits first by using your default nameservers and checking they do indeed work correctly and going to handle requests itself if needed.
- To be exhaustive, I need to list DNSCrypt (open but not standardized) that aims to prevent spoofing. You need however specific clients and servers to communicate using this protocol.
To expand your knowledge, this wiki may be a good start: https://dnsprivacy.org/wiki/