# Lets tune openwrt, i.e. DNS with https-dns-proxy

**URL:** <https://forum.openwrt.org/t/lets-tune-openwrt-i-e-dns-with-https-dns-proxy/249116>\
**Category:** Installing and Using OpenWrt\
**Created:** [April 16, 2026, 1:52pm UTC](https://forum.openwrt.org/t/lets-tune-openwrt-i-e-dns-with-https-dns-proxy/249116 "2026-04-16T13:52:18Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![reinerotto](https://forum.openwrt.org/letter_avatar/reinerotto/32/5_5575768a8748004e209b776fc1b2916d.png) [@reinerotto](https://forum.openwrt.org/u/reinerotto)\
**Post date:** [April 16, 2026, 1:52pm UTC](https://forum.openwrt.org/t/lets-tune-openwrt-i-e-dns-with-https-dns-proxy/249116/1 "2026-04-16T13:52:19Z")

</div>

During my research regarding my Chrome/DNS-TCP issue, I modified certain openwrt pars, to speed up ops. Which might be of interest to other parties, as well, especially, when using not-so-beefy devices.

1. Edit /etc/sysctl.d/11-nf-conntrack.conf

net.netfilter.nf\_conntrack\_acct=0 # I guess, accounting here only required for special accounting packages.

1. Eliminate some DNS-related conntrack items, to save CPU/RAM. Especially, when https-dns-proxy is used, as it causes quite a few local conns to dnsmasq. Which might be even both DNS-UDP or DNS-TCP conns. Ref. [Dnsmasq, adblocking and Chrome - #2 by reinerotto](https://forum.openwrt.org/t/dnsmasq-adblocking-and-chrome/249045/2)

Set up following mods to fw4:

```plaintext
    chain raw_prerouting {
            type filter hook prerouting priority raw; policy accept;
            meta l4proto { tcp, udp } th dport 53 counter packets 6049 bytes 305496 notrack
    }

    chain raw_output {
            type filter hook output priority raw; policy accept;
            meta l4proto { tcp, udp } th dport 5053 ip daddr 127.0.0.0/8 counter packets 1125 bytes 76469 notrack
            meta l4proto { tcp, udp } th sport 5053 ip daddr 127.0.0.0/8 counter packets 1098 bytes 112953 notrack
            meta l4proto { tcp, udp } th sport 53 ip daddr 192.168.1.0/24 counter packets 5254 bytes 309893 notrack

```

In case of not using https-dns-proxy, same can be done, without rules for ‘s/dport 5053’ .

---

<div class="post-metadata">

**Author:** ![stangri](https://forum.openwrt.org/user_avatar/forum.openwrt.org/stangri/32/58_2.png) [@stangri](https://forum.openwrt.org/u/stangri)\
**Post date:** [April 18, 2026, 12:42am UTC](https://forum.openwrt.org/t/lets-tune-openwrt-i-e-dns-with-https-dns-proxy/249116/2 "2026-04-18T00:42:32Z")

</div>

@reinerotto are you using this with force\_dns enabled or disabled in https-dns-proxy?

---

<div class="post-metadata">

**Author:** ![reinerotto](https://forum.openwrt.org/letter_avatar/reinerotto/32/5_5575768a8748004e209b776fc1b2916d.png) [@reinerotto](https://forum.openwrt.org/u/reinerotto)\
**Post date:** [April 18, 2026, 8:19am UTC](https://forum.openwrt.org/t/lets-tune-openwrt-i-e-dns-with-https-dns-proxy/249116/3 "2026-04-18T08:19:31Z")

</div>

My config:

config main 'config'  
option canary\_domains\_icloud '1'  
option canary\_domains\_mozilla '1'  
option dnsmasq\_config\_update '-'  
option force\_dns '1'  
list force\_dns\_port '53'  
list force\_dns\_port '853'  
list force\_dns\_src\_interface 'lan'  
option procd\_trigger\_wan6 '0'  
option heartbeat\_domain 'heartbeat.melmac.ca'  
option heartbeat\_sleep\_timeout '10'  
option heartbeat\_wait\_timeout '10'  
option user 'nobody'  
option group 'nogroup'  
option listen\_addr '127.0.0.1'  
option statistic\_interval '3600'  
option logfile '/tmp/https-dns-proxy.log'  
option verbosity '3'

config https-dns-proxy  
option bootstrap\_dns '9.9.9.10,9.9.9.9'  
option resolver\_url '[https://dns10.quad9.net/dns-query](https://dns10.quad9.net/dns-query)'  
option listen\_port '5053'

BTW, I filed an official issue for https-dns-proxy, on aarond10, on git. May be, you have the opportunity to confirm/reject it.

---

<div class="post-metadata">

**Author:** ![stangri](https://forum.openwrt.org/user_avatar/forum.openwrt.org/stangri/32/58_2.png) [@stangri](https://forum.openwrt.org/u/stangri)\
**Post date:** [April 24, 2026, 5:27pm UTC](https://forum.openwrt.org/t/lets-tune-openwrt-i-e-dns-with-https-dns-proxy/249116/4 "2026-04-24T17:27:55Z")

</div>

@reinerotto as far as I understand, the below:

```plaintext
      chain raw_prerouting {
              type filter hook prerouting priority raw; policy accept;
              meta l4proto { tcp, udp } th dport 53 counter packets 6049 bytes 305496 notrack
      }

```

breaks the force\_dns, so clients with hardcoded DNS will still use hardcoded servers instead.

BTW, @aarond10’s repo is the wrong place to create an issue for the OpenWrt package. It’s maintained at mossdef-org repo.

---

<div class="post-metadata">

**Author:** ![reinerotto](https://forum.openwrt.org/letter_avatar/reinerotto/32/5_5575768a8748004e209b776fc1b2916d.png) [@reinerotto](https://forum.openwrt.org/u/reinerotto)\
**Post date:** [April 24, 2026, 6:35pm UTC](https://forum.openwrt.org/t/lets-tune-openwrt-i-e-dns-with-https-dns-proxy/249116/5 "2026-04-24T18:35:45Z")

</div>

breaks the force\_dns … Good find. Sh.., you are correct. For force\_dns=0 alone it is not so exciting.

Regarding where to create an issue, my idea was, that it MIGHT be a general problem of https-dns-proxy. OK, I will create a ref in mossdef-org repo. Thank you.