[rayhaanj]

I think you mean "running your own recursive resolver", an authoritative server is one which is authoritative for some zone (e.g. example.net), whilst a recursive resolver is one that goes and walks from the root of the DNS hierarchy to the leaf that you have queried.

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).

[belorn]

> It is probably quite a bit slower though needing to have roundtrips at each stage of the resolution

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.

[rayhaanj]

I just did some measurements and am impressed on both fronts: DNS recursive resolution is faster than I anticipated, but also page load times for well optimised sites are also very fast (sub 0.5s). Here's some data:

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.

[belorn]

The page you get when DOMContentLoaded is finished is a white page with no content. The page is only loaded in a very technical sense for sites like bbc.com.

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.

[Bender]

It is probably quite a bit slower though needing to have roundtrips at each stage of the resolution

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.

[copula4]

There is life outside major population centers. I have pings in excess of 200 ms to many major websites; if every DNS lookup requires doing several queries with 100-300 ms of waiting for each one, the web becomes unusable. From reading HN, users from e.g. New Zealand run into similar issues.

[Bender]

I too am in a rural area, just not as rural as NZ. My setup would also be 0ms in NZ and AU for 98+% of my requests. The real impactful delays come from the excessive requests browsers have to make to bloated frameworks, excessive cookies and third party integrations, ads, videos and so on. uBlock can clean some of that up but not all of it.