Https-dns-proxy and dnsmasq config "noresolv"

i've just setup https-dns-proxy that automatically changes dnsmasq config file at each start, to use the local "fake" dns server and yes, this is working
Basically it adds - and removes - this config:

        option noresolv '1'
        option doh_backup_noresolv '-1'
        list doh_backup_server ''
        list server ''
        list server ''

i can't understand the need for the noresolv option that seems also to create problems with local lookup of hostnames: i can't resolve any local name on the router itself
Can you help me understanding why it is needed? afaik this option should avoid reading resolvers from /Etc/resolv.conf, that is:

search lan
nameserver ::1

so it seems nothing breaking the dns over https..


DNS encryption services including https-dns-proxy rely on split-DNS.
So, you'd best specify public resolvers as an upstream DNS provider for the local system.


sorry, i don't think i understood :frowning:
my network already has upstream dns:

config interface 'wan'
        option _orig_ifname 'eth0'
        option _orig_bridge 'false'
        option proto 'pppoe'
        option ipv6 'auto'
        option peerdns '0'
        option device 'eth0'
        list dns ''
        list dns ''
        option keepalive '3 5'

but i can't see how this should help in resolving local hostnames, so i assume i did not understood your suggestion :slight_smile:
now my system is up and running without the noresolv option, am i at risk of a race condition?

Restarting a router can make system time out of sync since there's typically no RTC.
This results in a deadlock for https-dns-proxy and sysntpd:

  • sysntpd cannot sync time because it needs to resolve the NTP domain.
  • https-dns-proxy cannot resolve the NTP domain because the system time is out of sync.

So, enabling split-DNS is the most efficient method to solve the race condition.
OpenWrt not using dnsmasq for the local system is a downside of this method.


ok so basically i can have local resolution of hostnames or dns over ssl, but not both.
seems a bad choice anyway, isn't it?

Edit: oh, and i forgot to thank you! every time you teach me something new :slight_smile: thanks!

You still can enforce dnsmasq for the local system and bypass the NTP domain.


Ok, so basically the idea is forcing the NTP lookup to go in any case on "plain" dns and the "localuse" should allow me to lookup local hostnames also with the noresolv option. Ok, i'll give a try.
I see the disclaimer "Beware of race condition with Adblock service when using DNS encryption" and obviously i have adblock, also in this case i can't see the race condition. Adblock is using dnsmasq to work, why should it have problems? i assume the download of lists (that need a name lookup) can easily happen after dnsmasq is up and running through https.. right?
thanks :slight_smile:

If you enforce dnsmasq for the local system, all DNS queries are forwarded to https-dns-proxy.
However, it takes some time for https-dns-proxy to initialize at startup.
At the same time, Adblock fails to download the blocklists since https-dns-proxy is not ready yet.
I don't use Adblock at the moment, so I'm unsure if this has been fixed or not.

ok, makes sense, maybe my local backup is helping also for this problem..
Thanks, let's see if i can kill my router :smile:

1 Like

It should work if you use a persistent location to store blocklists.

Or you can configure adblock to wait for a time

1 Like

oh well, i already had the local backup of lists on my external HDD so this is not even a topic.. now i'm trying to understand the ntp point because:

  • it seems it works even if i do not specify the "exclusion" for the NTP server, but this seems strange because afaik a time is needed to check a SSL certificate..
  • if i add the exclusion, in any case https-dns-proxy is changing it to a "doh_backup_server" so, back again, i assume it is not used to resolve the ntp server name

Btw i'm still not sure i want to keep dns over https, but i wanted to make this work, and it seems it does!

The issue is hardware specific, so some models are less affected than others.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.