Just in relation to stubby with dnsmasq: https://openwrt.org/docs/guide-user/services/dns/dot_dnsmasq_stubby
I came across a race condition with NTP and DNS resolution. Because NTP couldn't sync to the openwrt pool
[0-3].openwrt.pool.ntp.org servers that were configured as DNS resolution was broken through stubby which is set as nameservers in dnsmasq. In a chicken and egg scenario DNS resolution was broken through stubby because the system time was wrong and hence the TLS connection to the DoH servers defined was broken.
Is it worth adding a note around potentially making NTP pool DNS requests go through plain DNS like 188.8.131.52 or 184.108.40.206?
Example for dnsmasq:
list server '/0.openwrt.pool.ntp.org/1.openwrt.pool.ntp.org/2.openwrt.pool.ntp.org/3.openwrt.pool.ntp.org/220.127.116.11'
I must admit I haven't encountered this before, but it seems depending on timing NTP may be broken by DoT, if the NTP pool names are resolved with stubby and not in the clear if the system time is not accurate.
It doesn't look like stubby has a fallback resolver, unlike DNSCrypt.