If you’re using https-dns-proxy, and have:
Canary Domains iCloud: Force router DNS server to all local devices Canary Domains Mozilla: Force router DNS server to all local devices
… then you’ve likely discovered that your DNS resolution glitches upon router reboot, until you go into Network >> DNS >> Forwards tab and reshuffle the DNS Forwards list to put the Canary Domains back down at the bottom of the list (and the IPv6 entries below the IPv4 entries).
The fault lies with https-dns-proxy. It glitches when reading those Canary Domains, injecting odd entries (I had one that was /://icloud.com/, which isn’t even close to correct, and somehow locked me out of the LuCI interface AND out of DropBear SSH), and shuffling the Canary Domains and IPv6 entries to the top of the list. This messes up DNS resolution when the router is rebooted, and can even prevent dnsmasq from even starting.
Let’s implement a workaround…
mkdir -p /etc/dnsmasq.d
cat << 'EOF' > /etc/dnsmasq.d/canary_domains.conf server=/mask.icloud.com/ server=/mask-h2.icloud.com/ server=/icloud.com/ server=/use-application-dns.net/ EOF
Set dnsmasq to read the new directory:
uci set dhcp.@dnsmasq[0].confdir='/etc/dnsmasq.d' uci commit dhcp
Tell https-dns-proxy to no longer force the Canary Domains into the DNS Forwards list:
uci set https-dns-proxy.config.update_dnsmasq='0' uci set https-dns-proxy.config.force_dnsmasq='0' uci set https-dns-proxy.config.canary_domains_icloud='0' uci commit https-dns-proxy
Stop the proxy service so it can’t refresh during the next steps:
/etc/init.d/https-dns-proxy stop
Remove the Canary Domains from /etc/config/dhcp:
uci del_list dhcp.@dnsmasq[0].server='/mask.icloud.com/' uci del_list dhcp.@dnsmasq[0].server='/mask-h2.icloud.com/' uci del_list dhcp.@dnsmasq[0].server='/icloud.com/' uci del_list dhcp.@dnsmasq[0].server='/use-application-dns.net/' uci del_list dhcp.@dnsmasq[0].doh_backup_server='/mask.icloud.com/' uci del_list dhcp.@dnsmasq[0].doh_backup_server='/mask-h2.icloud.com/' uci del_list dhcp.@dnsmasq[0].doh_backup_server='/icloud.com/' uci del_list dhcp.@dnsmasq[0].doh_backup_server='/use-application-dns.net/' uci del dhcp.@dnsmasq[0].doh_backup_server uci commit dhcp
Check that all the Canary Domains are removed from /etc/config/dhcp:
cat /etc/config/dhcp
You shouldn’t see any Canary Domains in there anymore.
Stop the network daemons, then start them:
/etc/init.d/https-dns-proxy stop /etc/init.d/dnsmasq stop /etc/init.d/https-dns-proxy start /etc/init.d/dnsmasq start
In the Services >> HTTPS DNS PRoxy page, it will show:
Canary Domains iCloud Let local devices use iCloud Private Relay Canary Domains Mozilla Let local devices use Mozilla Private Relay
BUT… we’re importing those Canary Domains into dnsmasq via:
option confdir '/etc/dnsmasq.d'
… in /etc/config/dhcp.
The Canary Domains are local, so they should never be resolved via the internet. You can ascertain that they’re not by doing, for instance:
nslookup icloud.com nslookup mask.icloud.com nslookup mask-h2.icloud.com nslookup use-application-dns.net
You should now properly get something like this:
nslookup icloud.com Server: 127.0.0.1 Address: 127.0.0.1:53 ** server can't find icloud.com: NXDOMAIN ** server can't find icloud.com: NXDOMAIN
By completely isolating these Canary Domains in /etc/dnsmasq.d/canary_domains.conf, dnsmasq handles them perfectly on its own. It serves up the necessary NXDOMAIN errors locally, network devices stay perfectly behaved, and https-dns-proxy no longer puts the router into a buggy reboot due to https-dns-proxy shuffling the DNS Forwards list and glitching when doing so, resulting in odd list entries which prevent DNS resolution or prevent dnsmasq from starting.