DoH proxy: https-dns-proxy new RFC8484-supporting package and Web UI

here is the config /etc/config/https-dns-proxy.

config main 'config'
        option dnsmasq_config_update '*'
        option force_dns '0'
        list force_dns_port '53'
        list force_dns_port '853'
        option procd_trigger_wan6 '0'

config https-dns-proxy
        option resolver_url 'https://dns.alidns.com/dns-query'
        option user 'nobody'
        option group 'nogroup'
        option listen_addr '127.0.0.1'

config https-dns-proxy
        option resolver_url 'https://doh.pub/dns-query'
        option listen_addr '127.0.0.1'
        option user 'nobody'
        option group 'nogroup'
1 Like

I can confirm that for some reason the luci app doesn't load the bootstrap_dns entries from the json files, I'll have to look into js code at some point in the future.

I get "crash loops" when my internet connection fails...

I'm sorry to bother you but I haven't found a solution to my problem,

I have a connection via an LTE module so sometimes it happens that there are circumstances that give rise to an unstable internet connection ...

I would like to have some information, is it possible that by doing an "ifdown wan" the packet goes into "crash loop"?

because I have a script that checks my internet connection and if it detects that it is not present it does an "ifdown wan && ifupwan" but I find this indication in the log:

daemon.info procd: Instance https-dns-proxy::instance1 s in a crash loop 44 crashes, 15 seconds since last crash
user.notice firewall: Reloading firewall due to ifup of wan (wwan0)
user.notice https-dns-proxy [23351]: Starting https-dns-proxy 2023.12.26-r4 instances on_interface_trigger βœ“
user.notice https-dns-proxy [23351]: Setting trigger for wan_4 βœ“
daemon.info procd: Instance https-dns-proxy::instance1 s in a crash loop 45 crashes, 2 seconds since last crash
user.notice https-dns-proxy [23610]: Starting https-dns-proxy 2023.12.26-r4 instances on_interface_trigger βœ“
user.notice https-dns-proxy [23610]: Setting trigger for wan_4 βœ“
user.notice firewall: Reloading firewall due to ifup of wan_4 (wwan0)

I have already tried to update the package to the latest available version, using "owut" but I still have this problem, is there a solution?

https-dns-proxy - 2025.05.11-r1

thanks to anyone who wants to help me...

Try:

/etc/init.d/https-dns-proxy stop
ifdown wan
ifup wan
/etc/init.d/https-dns-proxy start
1 Like

thanks for replying, great program :grinning:

yes maybe I solved it as you said,
I will monitor everything if there are still "crash loops".

Can you test luci-app-https-dns-proxy 2025.05.11-r2 from my repo? I've tried to address the bootstrap_dns loading but may not have considered all other use cases, so I'd appreciate a thorough testing.

Sorry to say it, but I'm only an OpenWrt user instead of a coder. I install released ipks, but never build one, not to speak of a thorough testing.

You can grab the pre-built IPK from here: https://dev.melmac.net/repo/luci-app-https-dns-proxy_2025.05.11-r2_all.ipk

There are bugs in version 2025.05.11-r2.

I installed both https-dns-proxy_2025.05.11-r2_x86_64.ipk and luci-app-https-dns-proxy_2025.05.11-r2_all.ipk.

The luci app can address the bootstrap_dns loading in the web UI, but what it shows in the web UI, no matter if it's the default bootstrap_dns address or user setted ones, will not actually be saved into the config file /etc/config/https-dns-proxy.

If I edit the /etc/config/https-dns-proxy file, set an option bootstrap_dns '1.1.1.1,1.0.0.1' to an instance, the web UI can read it. And then if I edit the instance's bootstrap_dns in the web UI, it seems will not actually edit but delete the option bootstrap_dns

Besides, it seems that IPv6 bootstrap_dns will not been used.
I manually set the config file as the following:

config https-dns-proxy
        option bootstrap_dns '223.5.5.5,223.6.6.6,2400:3200::1,2400:3200:baba::1'
        option resolver_url 'https://dns.alidns.com/dns-query' 

and then

root@ImmortalWrt:/etc/config# service https-dns-proxy info
{
        "https-dns-proxy": {
                "instances": {
                        "instance1": {
                                "running": true,
                                "pid": 27507,
                                "command": [
                                        "/usr/sbin/https-dns-proxy",
                                        "-r",
                                        "https://dns.alidns.com/dns-query",
                                        "-a",
                                        "127.0.0.1",
                                        "-p",
                                        "5053",
                                        "-b",
                                        "223.5.5.5,223.6.6.6",
                                        "-4",
                                        "-u",
                                        "nobody",
                                        "-g",
                                        "nogroup"
                                ],
                                "term_timeout": 5,
1 Like

Hello, I have a domain policy on PBR that routes the DNS server through the VPN. The problem is that it doesn't function until you access the OpenWRT console and type in nslookup <dnsdomain.com>. Is there a known fix for this?

I see the presence of the '-4' in the instance status, it means that it forces IPv4-only mode, thus skipping IPv6 addresses from bootstrap_dns.

Just to confirm, you're reporting two issues:

  1. the bootstrap_dns loaded from json in the WebUI doesn't get saved to config file?
  2. when editing the bootstrap_dns in WebUI, the bootstrap_dns gets deleted in the config file?

I think the first issue may be a result of the second one, that whatever I do in the WebUI, it deletes the bootstrap_dns in the config file. If I start an instance in with the Web UI, it starts an instance without option bootstrap_dns settings in the config file.

Thanks for that detail, I'll look into it.

Hello. I'm getting a strange error (uci:invalid argument) when starting http-dns-proxy. It doesn't seem to happen when option dnsmasq_config_update is set to '*'? The service does start.

Any ideas?

root@Router:~# service https-dns-proxy restart
Starting https-dns-proxy 2025.05.11-r1 instances /sbin/uci: Invalid argument
/sbin/uci: Invalid argument
/sbin/uci: Invalid argument
/sbin/uci: Invalid argument
/sbin/uci: Invalid argument
/sbin/uci: Invalid argument
/sbin/uci: Invalid argument
/sbin/uci: Invalid argument
/sbin/uci: Invalid argument
/sbin/uci: Invalid argument
βœ“/sbin/uci: Invalid argument
/sbin/uci: Invalid argument
/sbin/uci: Invalid argument
/sbin/uci: Invalid argument
βœ“
Setting trigger for wan βœ“

Config:

root@Router:~# cat /etc/config/https-dns-proxy

config main 'config'
	option canary_domains_icloud '1'
	option canary_domains_mozilla '1'
	option force_dns '1'
	list force_dns_port '53'
	list force_dns_port '853'
	list procd_fw_src_interfaces 'lan'
	option procd_trigger_wan6 '0'
	option dnsmasq_config_update '-'

config https-dns-proxy
	option bootstrap_dns '194.242.2.6,2a07:e340::6'
	option resolver_url 'https://family.dns.mullvad.net/dns-query'
	option listen_addr '127.0.0.1'
	option listen_port '5053'
	option user 'nobody'
	option group 'nogroup'

config https-dns-proxy
	option bootstrap_dns '194.242.2.4,2a07:e340::4'
	option resolver_url 'https://base.dns.mullvad.net/dns-query'
	option listen_addr '127.0.0.1'
	option listen_port '5054'
	option user 'nobody'
	option group 'nogroup'

Further information:

root@Router:~# ubus call system board
{
	"kernel": "6.6.93",
	"hostname": "Router",
	"system": "Intel(R) Celeron(R) J4105 CPU @ 1.50GHz",
	"model": "QEMU Standard PC (i440FX + PIIX, 1996)",
	"board_name": "qemu-standard-pc-i440fx-piix-1996",
	"rootfs_type": "ext4",
	"release": {
		"distribution": "OpenWrt",
		"version": "24.10.2",
		"revision": "r28739-d9340319c6",
		"target": "x86/64",
		"description": "OpenWrt 24.10.2 r28739-d9340319c6",
		"builddate": "1750711236"
	}
}
root@Router:~# curl -V
curl 8.12.1 (x86_64-openwrt-linux-gnu) libcurl/8.12.1 mbedTLS/3.6.4 nghttp2/1.63.0
Release-Date: 2025-02-13
Protocols: file ftp ftps http https ipfs ipns mqtt
Features: alt-svc HSTS HTTP2 HTTPS-proxy IPv6 Largefile SSL threadsafe UnixSockets
root@Router:~# dnsmasq --version
Dnsmasq version 2.90  Copyright (c) 2000-2024 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-nftset no-auth no-cryptohash no-DNSSEC no-ID loop-detect inotify dumpfile

This software comes with ABSOLUTELY NO WARRANTY.
Dnsmasq is free software, and you are welcome to redistribute it
under the terms of the GNU General Public License, version 2 or 3.
root@Router:~# https-dns-proxy -V
2025.05.11-r1
Using: ev/4.33 c-ares/1.33.1 libcurl/8.12.1 mbedTLS/3.6.4 nghttp2/1.63.0
Features: HTTP2 HTTPS-proxy IPv6

root@Router:~# service https-dns-proxy status
running
root@Router:~# service https-dns-proxy info
{
	"https-dns-proxy": {
		"instances": {
			"instance1": {
				"running": true,
				"pid": 20010,
				"command": [
					"/usr/sbin/https-dns-proxy",
					"-r",
					"https://family.dns.mullvad.net/dns-query",
					"-a",
					"127.0.0.1",
					"-p",
					"5053",
					"-b",
					"194.242.2.6",
					"-4",
					"-u",
					"nobody",
					"-g",
					"nogroup"
				],
				"term_timeout": 5,
				"data": {
					"firewall": [
						{
							"type": "redirect",
							"target": "DNAT",
							"src": "lan",
							"proto": "tcp udp",
							"src_dport": "53",
							"dest_port": "53",
							"family": "any",
							"reflection": false
						},
						{
							"type": "rule",
							"src": "lan",
							"dest": "*",
							"proto": "tcp udp",
							"dest_port": "853",
							"target": "REJECT"
						}
					],
					"mdns": {
						"https-dns-proxy_5053": {
							"service": "_https-dns-proxy._udp.local",
							"port": 5053,
							"txt": [
								"DNS over HTTPS proxy"
							]
						}
					}
				},
				"respawn": {
					"threshold": 3600,
					"timeout": 5,
					"retry": 5
				}
			},
			"instance2": {
				"running": true,
				"pid": 20011,
				"command": [
					"/usr/sbin/https-dns-proxy",
					"-r",
					"https://base.dns.mullvad.net/dns-query",
					"-a",
					"127.0.0.1",
					"-p",
					"5054",
					"-b",
					"194.242.2.4",
					"-4",
					"-u",
					"nobody",
					"-g",
					"nogroup"
				],
				"term_timeout": 5,
				"data": {
					"mdns": {
						"https-dns-proxy_5054": {
							"service": "_https-dns-proxy._udp.local",
							"port": 5054,
							"txt": [
								"DNS over HTTPS proxy"
							]
						}
					}
				},
				"respawn": {
					"threshold": 3600,
					"timeout": 5,
					"retry": 5
				}
			}
		},
		"triggers": [
			[
				"interface.*",
				[
					"if",
					[
						"eq",
						"interface",
						"wan"
					],
					[
						"run_script",
						"/etc/init.d/https-dns-proxy",
						"restart",
						"on_interface_trigger"
					]
				],
				1000
			],
			[
				"config.change",
				[
					"if",
					[
						"eq",
						"package",
						"https-dns-proxy"
					],
					[
						"run_script",
						"/etc/init.d/https-dns-proxy",
						"reload",
						"on_config_change"
					]
				],
				1000
			]
		]
	}
}
root@Router:~# nslookup google.com 127.0.0.1:5053
Server:		127.0.0.1:5053
Address:	127.0.0.1:5053

Non-authoritative answer:
Name:	google.com
Address: 142.250.180.14

Non-authoritative answer:
Name:	google.com
Address: 2a00:1450:4009:81e::200e

It could be your bootstrap servers

A bootstrap must be a DNS server which is publicly available using plain DNS53

My testing shows that that is not the case for the DNS servers you have set

So try with e.g. 1.1.1.1 as bootstrap server

I thought I've pushed a fix for this into OpenWrt repo, but for some reason 2025.05.11-r1 still doesn't have it.

You can grab a fixed init-script from my repo: https://raw.githubusercontent.com/stangri/https-dns-proxy/refs/heads/main/files/etc/init.d/https-dns-proxy or you can update to 2025.05.11-r3 hopefully by or just after the weekend.

PS. The functionality is not affected, despite the invalid argument output, the 2025.05.11-r1 functions as expected.

2 Likes

I get this when I try to install r3 manually.

Oh, don’t try to install the https-dns-proxy IPK/APK from my packages repo unless you’re on x86-64.

I’m looking into enabling automatic builds using official OpenWrt docker images via github CI, but not having much luck yet.

1 Like

Very large upstream code update from @baranyaib90 was merged by @aarond10 yesterday: https://github.com/aarond10/https_dns_proxy/pull/192

Until the new code is merged into OpenWrt repo you can grab the updated binaries for most platforms (IPK for 24.10 and APK for snapshots) from https://github.com/stangri/https-dns-proxy/releases and run the most up-to-date code.

1 Like

So for ipq807x target, is this the right snapshot file?

https-dns-proxy-2025.09.01-1_snapshots_aarch64_generic.apk