For this approach, I require bulk DNS data. However I do not need DNS data for every domain on the internet. Consequentially, it is not a large amount of data. Contemporary computers usually have more than enough primary storage space to hold it.
When I request zone files from czds.icann.org or extract DNS data from publicly available UDP scans, two methods of obtaining bulk DNS data, I am not disclosing any information about what domains I plan to look up via DNS in the future. Obtaining bulk DNS data does not reveal as much as doing piecemeal lookups, not to mention doing them contemporaneous with HTTP requests to the IP address returned by the queries. Intermediary DNS caches will see all lookup activity, as would authoritative nameservers for a domain if I query them directly. Obtaining bulk DNS data generally does not suffer from this problem.
Even more, I am not sure I understand the privacy issue around an authoritative nameserver seeing one's requests, e.g., from a stub resolver or a local cache. If I am going to visit example.com, the the operator of example.com will see the HTTP request. Why would I care if the operator of example.com's nameserver sees the DNS requests. If the concern is that network observers, not the operator of example.com, will see the contents of DNS requests made to example.com's authoritative nameservers, then that is exactly what DNSCurve prevents. Encrypt the DNS packets.
In the end, I believe bulk DNS data served from the loopback provides the greatest privacy, not to mention the best performance.
All the DNS data served by the "DNS root servers" is public and available for download via HTTP or FTP request.[FN1] As such, IMHO, there is rarely a reason to query those servers for the data they serve. I already have it.[FN1] For example, the IP address for the "a" com nameserver probably will not change in my lifetime. I am so sure of this that I have it memorised as 192.5.6.30.
A simple illustration of how to reduce DNS queries to one and reduce remote DNS queries to zero. Compile nsd as a root server using --enable-root-server. Add DNS data to a root.zone. Bind nsd to a localhost address, e.g., 127.8.8.8 and serve the zone. Configure the system resolver to query nameserver 127.8.8.8.
mkdir /tmp/nsd-01
cd /tmp/nsd-01
echo . 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2021101501 1800 900 604800 86400 > root.zone
echo example.com 1 IN A 93.184.216.34 >> root.zone
test ! -d /nonexistent||rm -rf /nonexistent
groupadd nsd-01
useradd nsd-01 -g nsd-01 -s /bin/false -b /nonexistent -d /nonexistent
chown nsd-01 /tmp/nsd-01
chgrp nsd-01 /tmp/nsd-01
printf 'server:\nipv4-edns-size: 0\nzonesdir: "/tmp/nsd-01"\nzone:\nname: "."\nzonefile: "root.zone"\n' > conf
nsd -u nsd-01 -4 -a 127.8.8.8 -c conf -l log -P pid -f db
cp /etc/resolv.conf resolv.conf.bak
echo nameserver 127.8.8.8 > /etc/resolv.conf
drill -oRD example.com
# cleanup
mv resolv.conf.bak /etc/resolv.conf
kill $(cat pid)
rm -rf /tmp/nsd-01
sleep 1
userdel nsd-01
FN1. How to get the DNS data that the root servers provide, without using DNS: x=$(printf '\r\n');
sed "s/$/$x/" << eof|openssl s_client -connect 192.0.32.9:43 -ign_eof
GET /domain/root.zone HTTP/1.1
Host: www.internic.net
User-Agent: www
Connection: close
eof
ftp://192.0.32.9/domain/root.zoneFN2. Except in emergencies where I have no access to locally stored root.zone DNS data. Also because I have the "a" root server IP address memorised as 198.41.0.4, I sometimes use it as a ping address.
What is the best way to go about this? AFAIU the root DNS servers will refuse requests for recursive resolutions. So I understand the need for a self-hosted caching resolver in the middle. But is it actually necessary? If I configure my iPhone DNS to use a root server IP [0], will it perform the recursive resolution locally? And if so, is there any downside, other than increased latency, to contacting the root servers directly?
I guess privacy and trust might be issues, when asking untrusted computers (any of the intermediate resolvers) to resolve an address for your client. You would certainly give the host of a domain more information when you contact it than you would by using a third party caching resolver as an intermediary. It’s basically a question of spraying small bits of activity to many resolvers, or all your activity to one resolver. Which is a smaller attack surface? Depends.
[0] https://www.iana.org/domains/root/servers