Yes that would be nice.
The nice thing of a community is that everyone is invited to participate and improve the software
I totally agree that community participation is what makes OpenWrt great.
However, I believe in the principle of division of labor: everyone should stick to what they do best.
A dentist should treat teeth, and a programmer should write code. If a doctor starts writing code, things will break; if a programmer starts performing heart surgery, people might die. I think it’s best if those with the expertise focus on creating a user-friendly GUI, while users like me provide feedback on how to make it even better.
HaHa. yes but not totally true, I actually hold a PhD in medicine (but have been working in ICT)
3 Likes
Haha, fair enough! Since I also have a background in chemical biology, I guess we’re colleagues! Maybe we should open a funeral home together and develop software on the side? Bill Gates and Steve Jobs would be left in the dust — we’d be absolutely unstoppable! Let’s show them how real 'cross-disciplinary' development is done!
1 Like
[SOLVED]
Strange something must have changed. Removed second dnsmasq instance in dhcp.
Now https-dns-proxy is working on lan on wan clients.
Hops this is longtime solution!
I have this in log, and what is it?
[20 juli 2026 05:30:41 CEST] daemon.info: https-dns-proxy[12800]: [W] 1784518241.363465 doh_proxy.c:164 DNS request and response IDs are not matching: 2E65 != CAFE
[20 juli 2026 05:30:42 CEST] daemon.info: https-dns-proxy[12800]: [W] 1784518242.364755 doh_proxy.c:164 DNS request and response IDs are not matching: 2E65 != CAFE
Please test 2026.07.21-r1 from either https://github.com/mossdef-org/https-dns-proxy/releases or from the MOSSDeF APK repo.
It has patches to the principal package to allow much quicker service resets on flapping WANs, I'd like as much testing as possible before I create the PR for the upstream package (reference: https://github.com/aarond10/https_dns_proxy/issues/207).
5 Likes
Just loaded, working at first glance. Lets testing!
[22 juli 2026 20:49:17 CEST] user.notice: https-dns-proxy [26192]: Starting https-dns-proxy 2026.07.21-r1 instances ✓✓✓
[22 juli 2026 20:49:17 CEST] user.notice: https-dns-proxy [26192]: Setting triggers for wan wan6 ✓✓
1 Like
Small improovement request:
Using/testing in combo with mwan3(nftables), I activated logging for https-dns-proxy. Would be handy, in case these logs contain standard time stamps, instead of epoch. To simplify correlations.
Installed today the new version.
Quad 9 secured doesn't work
Which IP(s) ? I reported general issues with quad9 in the past already.
Secured with ECS
Even without ECS I still see a lot of errors with quad9. Only using ipv4, after several retries dns request resolved, but takes lot of time. Thats the behaviour I had quite some time ago, already. cloudflare works without issues, though.
You might want to check it yourself, modifying /etc/config/https-dns-proxy:
Log into router,
uci set https-dns-proxy.config.logfile='/tmp/https-dns-proxy.log'
uci set https-dns-proxy.config.verbosity='5'
uci commit
/etc/init.d/https-dns-proxy restart
And later on check the log file.
Ok, later I'll check.
Anyway seems that the error Is not triggered by the new version of package.
A router with old firmware in a remote location went offline yesterday for the same cause...
I think quad9 is the problem.
1 Like
I also stopped using quad9
I think those are coming from the upstream binary, not sure if I want to look into an openwrt-specific patch, but if you want to submit a PR to mossdef-org repo with one, I'd welcome it.
@egc Is quad9 instability bad enough to have their DoH servers dropped from the luci app? Not sure what should happen to installs targeting quad9 currently then.
I think @reinerotto can answer that better he has done the most research about this:
I'm staying at a place where the WiFi uplink bounces regularly. I've been running 2026.07.21-r1 for a couple of days and it's working fine. Thanks for the continued support.
2 Likes
Thanks for the testing and feedback @grifo I'll create PRs!
1 Like
@stangri Are you the current maintainer of the https-dns-proxy package? If you are, please take a look at the issue below:
config main 'config'
option dnsmasq_config_update '-' # changes dnsmasq server settings on start/stop, default is '*' which means all dnsmasq instances
I have a DNS stack running on a single OpenWrt device: AdGuard Home -> dnsmasq -> https-dns-proxy. I need dnsmasq in the middle so it can update nft sets to be used with another package you are maintaining, which is pbr.
I absolutely know what I am doing, so I need /etc/config/dhcp to be stable. Option dnsmasq_config_update is set to - to prevent https-dns-proxy to interfere with /etc/config/dhcp. I manually set the upstream servers of dnsmasq by myself:
list server '::1#5053'
list server '::1#5054'
As a result, https-dns-proxy stops manipulating /etc/config/dhcp upon startup, but it still does it if a command service https-dns-proxy stop or reboot is issued, and it wipes my 2 list server lines above. All users, including the OpenWrt device, lose DNS resolution. This device was located at my relative's house, it cannot reports its current WAN IP via DDNS because DNS is down, and I had to be on-site to fix the issue. 
The pbr service also messes with /etc/config/dhcp just to add a single line:
list addnmount '/var/run/pbr.dnsmasq'
... and then it restarts dnsmasq. Can we do something about it, to stop these automated, and unwanted behaviors?