It is probably quite a bit slower though needing to have roundtrips at each stage of the resolution, which is also likely a reason that these public resolvers get so much use (latency improvement via caching).

The average load time for a website is 2.5 seconds. The added load time from running your own recursive resolver, which is only added the first time the site is loaded, would be around 50ms, or 2% increase load time.

DNS resolving is not a major aspect of a typical websites load time. If you want to speed things up, run a local proxy which local cached version of all popular web frameworks and fonts, and have it be be constantly populated by a script running in the background. That will save you much more than 2% on first load.

Recursively resolve bbc.com: 18ms https://pastebin.com/d94f1Z7P Recursively resolve ethz.ch: 17ms https://pastebin.com/x6jSHgDn Recursively resolve admin.ch: 39ms: https://pastebin.com/DUTg8Rit

Page load in Firefox: bbc.com DOMContentLoaded: ~40ms, page loaded: ~300ms reuters.com DOMContentLoaded: ~200ms, page loaded: ~300ms google.com DOMContentLoaded: ~160ms, page loaded: ~290ms

So it's quite reasonable to do full recursive resolution, and you'll still benefit from caching after the first time it's loaded. One other idea I had but never looked into it was instead of throwing out entries after TTL expiry to just refresh it and keep it cached, no idea if BIND/Unbound can do that but you can probably build something with https://github.com/hickory-dns/hickory-dns to achieve that.

Google page speed (https://pagespeed.web.dev/analysis/https-bbc-com/yxcpaqmphq?...) use two other terms. First Contentful Paint, that is the first point in the page load timeline where the user can see anything on the screen, and Largest Contentful Paint, the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page. For bbc.com, those sites around 1 second mark.

Other measuring aspect is Time to First Byte, which is the time between the request for a resource and when the first byte of a response begins to arrive. For bbc.com that is 300ms.

My experience does not align with this. My Unbound instances cache only what I am requesting and I have full control over that cache memory allocation, min-ttl, zero-ttl serving and re-fetching, cron jobs that look up my most common requests hourly, etc... I do not have to share memory with anyone outside of my home. Just about anything I request on a regular basis is in the micro-seconds always shows as 0 milliseconds in dig. I've run performance tests against Unbound and all the major DNS recursive providers and my setup always wins for anything I use more than a few times a month or more than a dozen times in a year.

For the cases where I am requesting a domain for the first time the delay is a tiny fraction of the overall page loading of the site as belorn mentioned. I keep query response logs and that also has the response time for every DNS server I have queried. I also use those query response logs to build a table of domains that I look up hourly NS and A records to build the infrastructure cache in addition to resource record cache.

Now where there would be latency is if I had to enable my local Unbound -> DoT over Tinc VPN -> rented server Unbound -> root servers. That would only occur if my ISP decided to block anyone talking to the root servers directly and my DoT setup would only be in place while my legal teams get ready to roast my ISP and I start putting up billboards. That would of course be a waste of time and money when I could just get the IP's of censored sites from a cron-job running on multiple VM's and shove them into my hosts file. This could even be a public contribution into a git repo and automated on everyone's machines.

Needless to say, the bar is way lower. Anybody willing to pirate stuff can easily change their dns to any public dns service and access any website. You don’t even need a vpn.

I used to do that, but it caused some odd issues at my former ISP, which I suspect were due to connection tracking state table exhaustion on their CGNAT box; running your own recursive server means a lot of UDP connections, and unlike with TCP, there's no well-defined point at which the connection tracking state can be released, which can lead to it accumulating. Making unbound use DoT to cloudflare made things much more stable (since DoT uses TCP, the connection tracking state can be released immediately when each connection is closed).

I don't think traditional DNS can work if your adversary can get court orders [1]. You need some sort of decentralized solution that's hard to block even with court orders, e.g. Namecoin or ENS.

[1] Is evading a court order a legitimate objective? Most people would say "no" but the Internet functions in all countries, including repressive ones. Even in the US, it's not entirely inconceivable the Trump administration could make an executive order to require DNS providers to block certain websites he doesn't like (perhaps using post-9/11 powers granted to the executive branch to fight terrorists, that never got revoked even though Osama bin Laden is dead and the wars in Afghanistan and Iraq are over). The US has strong protections on freedom of speech, but working through the courts takes time, and becomes difficult when someone says the magic words "national security".