Https-dns-proxy canary domain persistance

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:

If the canary domains exist in your config before https-dns-proxy is started, they are backed up and restored on service stop.

Steps to reproduce:

  • Stop https-dns-proxy
  • Check for and remove any canary domains from /etc/config/dhcp
  • Start https-dns-proxy
  • Stop https-dns-proxy

Observe the presence of the canary domains as active with service stopped and never having been otherwise active without https-dns-proxy.

Please confirm the version of https-dns-proxy you're using.

What is a canary domains?

google canary domain ?

TLDR; used to check if internet access works

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.

https-dns-proxy - 2022-08-12-1

I just noticed an upgrade available, will give that a try.

EDIT: Behavior persists in 2022-10-15-1, same method to reproduce

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.

1 Like

PRs: https://github.com/openwrt/packages/pull/19635 https://github.com/openwrt/packages/pull/19636

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

Yes, this is how opkg works when you have a config file for the package being installed.

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

Did you intend to set the version to dev-test as part of the pull request?

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.

Ah, learned something new - thank you! It works fine. =)

began to work worse, the service restarts for a long time, it thinks for a long time

What is the output of this?

time /etc/init.d/https-dns-proxy restart

By asking this question, is there anything you can do to help, or are you just keeping the conversation going?

You reported a problem. I'm trying to confirm the problem. If you don't want help, that's OK too.