When canary domains are enabled (as per default) and https-dns-proxy is started, canary domains are (correctly) added to /etc/config/dhcp as server entries.
However, they are also added as doh_backup_server entries, which means that once https-dns-proxy is stopped (or removed), the canary domains persist as server entries.
I'm assuming this is not intended behavior - @stangri, can you confirm?
I do not think this is related to a similar topic of canary domain duplication found here:
A central way for the network administrator to tell connected clients (respectively their webbrowsers) not to use DoH, e.g. because local domain resolution is needed (also useful for adblocking), like for company intranets, campus resources etc.
Currently use-application-dns.net is used for that, resolving this domain with NXDOMAIN in your network tells browsers to disable DoH.
Great find! After I made the canary domains user-configurable, I forgot to rewrite the service stop function to support that! Will be fixed in the next release.
Collected errors:
resolve_conffiles: Existing conffile /etc/config/https-dns-proxy is different from the conffile in the new package.
The new conffile will be placed at /etc/config/https-dns-proxy-opkg.
this is when updating the package and two files appear in the config
https-dns-proxy and https-dns-proxy-opkg
reset the settings and the package installed without errors.
dns did not work after changing the IP address of the wan on the first router, and does not work until you restart this service.
when the IP address of the wan of the first router changes, dns refuses to work and I don't know what to do
Yes, it's intentional (to indicate that the init script wasn't installed by opkg), it's updated to the actual version in the Makefile/thru the opkg install.