Paul Vixie thinks more people should be running their own DNS servers

Unbound.

Paul probably has really nice internet access.

Most people in the USA have really poor access for running services. I have constant problems with Comcast myself.

One day when we have fiber and static ipv6, then we can run mail, IRC, Http, dns, etc.

I have been serving myself a custom root.zone for almost 20 years now.

I use tinydns for this which I think has always been the ideal choice for personal use. The author from the beginning recommended users not to use third party DNS and that advice has proven to be more and more prudent over the years. tinydns stores records on disk and has never been limited by RAM as would be something like nsd, for example. Today, I manage to fit all the data I need on tmpfs anyway.

I am certainly not the only person to serve their own root.

There used to be a project called ORSC that started around 1998 when there were people actively protesting ICANN management of domain names. ORSC ran their own root servers, as a service for others, as an alternative to ICANN. I remember seeing a page -- it may have been associated with ORSC -- showing how to run an alternative root. The software used was tinydns.

I also remember a former head of ICANN who said he ran his own local root.zone. Not sure what software he used. This was years before any "expert", e.g. Cricket Liu, even admitted running a local cache (nevermind a local root) could be a good idea.

Managing DNS for myself I noticed a few things over the years.

The amount of DNS data I will need for all internet use in the course of a lifetime -- subtracting all data for ad servers -- is relatively small. With today's computer equipment it can easily be stored locally.

Within that subset of DNS data the amount that is changing constantly is also relatively small. The Mockapetris DNS is premised on handling dynamic data but I manage to meet own needs with almost all static data. Further, the sampling I have done kept showing that most data stored in the DNS as a whole was not very dynamic.

Serving the data I need via authoritative servers like tinydns or nsd reduces the need for a cache, let alone one shared with others (who could possibly poison it... thereby reducing need for more complexity to protect against such poisoning).

As mentioned in the article, Vixie's problem was with Google hardware. Something like not being able to edit /etc/resolv.conf. Several solutions exist.

What happens when the ISP is redirecting all queries to port 53 to their own DNS servers? Imagine where the ISP has made its resolvers authoritative for everything, where it modifies the answers and you cannot access any other remote DNS server on port 53.

What is the solution? Multiple possibilities. If the needs are only for a relatively small amount of mainly static DNS data, then one option is to prefetch the data in bulk via FTP/HTTP. If the user wants a DNS cache, then another option is to set up own remote cache listening on a port other than 53 then forward queries there. VPN seems like overkill when the only issue is DNS traffic.

As such, "running their own DNS servers" could involve more than just using a RPi on the local network.

For an end user, a resolver only DNS server is probably one of the easiest services to run as there's really nothing to configure. I run my own resolver only DNS server at home. The configuration is minimal and I haven't had to touch it in years (about every five years I update the root zone to pick up new root servers if any).

I also happen to run DNS for my domain (as well as email, web, gopher and qotd) and that is a bit more involved than just resolving only, but it's by far easier to manage than an email server.

Yes, they can always see the metadata. To, from, ports, bytes sent, packets, time, duration of the flow, etc.