Not saying my setup has lower reliability than the hosted service (did nextdns.io promise any SLA?). For the added privacy, the potential lower reliability is a risk that I'm willing to take.
Even with this setup there are ways to increase reliability with-in the budget/skill set of a normal engineer, e.g. run two RasPi with keepalived and run VRRP on your routers. As a last resort, I can disable the "Private DNS" setting on my phone if my DNS is down and I can't fix quickly enough remotely.
keepalived is never the answer; if you can run it, your services are by definition crash-only share-nothing or inconsistent by design, or else you wouldn't let keepalived choose when to move the "primary flag" to the other service (as there'd be no way of sending the last ACKed data from the previous primary). Since this is the case, you could just load balance across the services and have them both active.
From a networking perspective, getting VRRP working on anything but physical equipment (e.g. in the cloud) is a fool's errand; it's L7/API-based and not on the ethernet level. Similarly with keepalived, which will get isolated from the monitored instances (thereby failing to the other, also "down" instance) — except it might have access to the API gateway of the cloud provider thereby disassociating the V-IP from both your instances; so you'll end up with more downtime with keepalived than you gain by it.
Since DNS is by default inconsistent, but eventually consistent and thereby possible to load-balance, you could run one instance of this stack on your static home IP and another instance on GCP/DO/AWS and configure multiple DNS servers in your DHCP options and on your phone, to get higher availability.
Even with this setup there are ways to increase reliability with-in the budget/skill set of a normal engineer, e.g. run two RasPi with keepalived and run VRRP on your routers. As a last resort, I can disable the "Private DNS" setting on my phone if my DNS is down and I can't fix quickly enough remotely.