stubby: init could be at same time dnsmasq

[Azureit]

I followed the wiki DoT with Dnsmasq and Stubby, and redirect all DNS traffic to Dnsmasq so that all DNS be encrypted. I notice the dnsmasq init much early than stubby, why dnsmasq and stubby don't start at the same time. This can produce init problems if a init service need to do a DNS query and stubby didn't start yet even if dnsmasq already started.

Maintainer: @jamesmacwhite

[brada4]

It does not change local resolv.conf i.e. processes on the router have normal 53/udp resolver from ISP DHCP available.

If you want to go full stubby (not on that wiki page) you need to override nameserver from DHCP via resolv.conf in addition to that wiki page, and for obvious reason have every upstream in stubby noted by IP in addition to mandtory hostname.

EDIT reflecting a bit - SSL cert validation would require working NTP (as RTC is absent in nearly arr routers) in all cases, sort of forcing circular dependency that makes router with new stubby package unusable coming up after few months of poweroff.

[Azureit]

@brada4

It does not change local resolv.conf i.e. processes on the router have normal 53/udp resolver from ISP DHCP available.

If you want to go full stubby (not on that wiki page) you need to override nameserver from DHCP via resolv.conf in addition to that wiki page, and for obvious reason have every upstream in stubby noted by IP in addition to mandtory hostname.

Look at the wiki page in the Command-line instructions, dnsmasq only requests from stubby: uci set dhcp.@dnsmasq[0].noresolv="1" uci set dhcp.@dnsmasq[0].localuse="1" uci add_list dhcp.@dnsmasq[0].server="${STUBBY_SERV}"

and to be sure all DNS is encrypted, I set port forwarding to forward all 53/udp/tcp from lan to internal DNS uci add firewall redirect uci set firewall.@redirect[-1].dest='wan' uci set firewall.@redirect[-1].target='DNAT' uci set firewall.@redirect[-1].name='redirect_dns-lan' uci set firewall.@redirect[-1].src='lan' uci set firewall.@redirect[-1].src_dip='! 192.168.1.1' uci set firewall.@redirect[-1].src_dport='53' uci set firewall.@redirect[-1].dest_ip='192.168.1.1' uci set firewall.@redirect[-1].dest_port='53'

---

EDIT reflecting a bit - SSL cert validation would require working NTP (as RTC is absent in nearly arr routers) in all cases, sort of forcing circular dependency that makes router with new stubby package unusable coming up after few months of poweroff.

To be safe I make a DNS exception for NTP servers: for NTP_HOST in `uci get system.ntp.server`; do uci add_list dhcp.@dnsmasq[0].server="/${NTP_HOST}/9.9.9.9"; done

[brada4]

Do you think whole intrusion should be brought in by a single package? sysntpd starts "late", so actual stubby already starts under harsh conditions prone to fail anyway.

Maybe you improve wiki to full stubby?

[Azureit]

Do you think whole intrusion should be brought in by a single package? sysntpd starts "late", so actual stubby already starts under harsh conditions prone to fail anyway.

Maybe you improve wiki to full stubby?

In the rare situation when the clock is so wrong that interfere with stubby SSL it will start to work as soon as [sys]ntpd sync the clock.

My command for NTP_HOST in `uci get system.ntp.server`; do uci add_list dhcp.@dnsmasq[0].server="/${NTP_HOST}/9.9.9.9"; done has a flaw, system.ntp.server can be changed. Just made a pull request for a better solution to address this at dnsmaq init dnsmasq: DNS upstream override for NTP https://github.com/openwrt/openwrt/pull/11947 Lets wait if it is approved.

[brada4]

That gives chance for stubby to start after a year of sleep in a dusty box. I suppose having dnsmasq DHCP+DNS on LAN is more important than upstream DoH being provided for those early start seconds.