omarchy dns applies a resolver without checking that it answers

[johnpipi]

omarchy dns <provider> writes the resolver configuration and returns. It never checks that what it just configured can actually answer a query, so a provider that does not work on the current network is applied silently and the failure surfaces later as "the internet is broken."

To be clear up front: using 1.1.1.1 for Cloudflare is correct, and a network that blocks it is the anomaly, not Omarchy. The suggestion is about the missing feedback, not the address choice.

What prompted this

On my network 1.1.1.1 is blackholed upstream — every protocol, not just ICMP:

Target	ICMP	TCP 443	TCP 53	DNS query
1.1.1.1	100% loss	blocked	blocked	fails
1.0.0.1 (Cloudflare's own secondary)	0% loss, 3.9 ms	open	—	—
8.8.8.8	0% loss, 4.5 ms	—	—	ok

The route is normal and nothing on the LAN claims the address, so this is an ISP or router block. Plenty of consumer gear and ISPs used 1.1.1.1 internally before Cloudflare acquired it.

omarchy dns Cloudflare on this network configures a dead primary resolver and reports nothing. Resolution still limps along via 1.0.0.1, but systemd-resolved spends its time discovering that the first server never answers, which showed up in my journal as continuous feature-set churn:

Using degraded feature set UDP+EDNS0 instead of TLS+EDNS0 for DNS server 1.1.1.1
Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 1.1.1.1
Using degraded feature set TCP instead of UDP for DNS server 1.1.1.1
Using degraded feature set UDP instead of TCP for DNS server 1.1.1.1     <- oscillating

omarchy dns still reports Cloudflare, which is true of the configuration and not of what works.

Three gaps

1. No validation after writing. bin/omarchy-dns has no resolvectl query, dig, or reachability check anywhere. A one-shot query against the servers it just wrote, with a warning on failure, would have turned a silent misconfiguration into an obvious one.

2. IPv6 resolvers are configured unconditionally. Both Cloudflare and Google write an IPv6 pair regardless of whether the host has IPv6 connectivity. This machine has no IPv6 default route, so two of the four configured servers are permanently unreachable and resolved still tries them.

3. DNSOverTLS is inconsistent across providers. From bin/omarchy-dns:

Provider	DNSOverTLS
Cloudflare	opportunistic
Google	opportunistic
DHCP	no
Custom	no line written → resolved default (no)

Choosing Custom and entering Cloudflare's own addresses silently gets different transport behaviour than choosing Cloudflare. If that is deliberate, it is at least surprising; DoT is also its own failure mode on networks that block port 853, as mine does.

Suggested behaviour

After writing the configuration, query the servers once and report the outcome — something like:

$ omarchy dns Cloudflare
Configured Cloudflare DNS.
Warning: 1.1.1.1 did not answer on this network. 1.0.0.1 responded in 4ms.
         Resolution will work but will be slower than expected.

That keeps the provider choice entirely with the user while making a dead server visible at the moment it is chosen. Skipping IPv6 servers when the host has no IPv6 route, and settling on one consistent DNSOverTLS policy, would remove the other two surprises.

Happy to open a PR if this seems worth having.