Could it be because the clock is off? Do you see any messages related to a time change?
1 Like
I see nothing related to clock or time. These are the dnsmasq events
Fri Mar 27 21:11:46 2020 user.notice dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
Fri Mar 27 21:11:46 2020 user.notice dnsmasq: Allowing 127.0.0.0/8 responses
Fri Mar 27 21:11:47 2020 daemon.err procd: unable to find /sbin/ujail: No such file or directory (-1)
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: started, version 2.80 cachesize 150
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: DNS service limited to local subnets
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID loop-detect inotify dumpfile
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: using local addresses only for domain test
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: using local addresses only for domain onion
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: using local addresses only for domain localhost
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: using local addresses only for domain local
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: using local addresses only for domain invalid
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: using local addresses only for domain bind
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: using nameserver 127.0.0.1#5054
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: using nameserver fe80::1067:47ff:fe03:4363#53 for domain openwrt.pool.ntp.org
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: using nameserver 192.168.128.1#53 for domain openwrt.pool.ntp.org
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: using nameserver 127.0.0.1#5053
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: using local addresses only for domain lan
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: read /etc/hosts - 4 addresses
Fri Mar 27 21:11:47 2020 daemon.info dnsmasq[961]: read /tmp/hosts/dhcp.cfg01411c - 10 addresses
Fri Mar 27 21:11:48 2020 authpriv.info dropbear[994]: Not backgrounding
Fri Mar 27 21:11:51 2020 user.notice : Added device handler type: 8021ad
Fri Mar 27 21:11:51 2020 user.notice : Added device handler type: 8021q
Fri Mar 27 21:11:51 2020 user.notice : Added device handler type: macvlan
Fri Mar 27 21:11:51 2020 user.notice : Added device handler type: veth
Fri Mar 27 21:11:51 2020 user.notice : Added device handler type: bridge
Fri Mar 27 21:11:51 2020 user.notice : Added device handler type: Network device
Fri Mar 27 21:11:51 2020 user.notice : Added device handler type: tunnel
Fri Mar 27 21:11:55 2020 daemon.info dnsmasq[961]: exiting on receipt of SIGTERM
Fri Mar 27 21:11:55 2020 user.notice dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
Fri Mar 27 21:11:55 2020 user.notice dnsmasq: Allowing 127.0.0.0/8 responses
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Interface 'lan' is enabled
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Interface 'lan' is setting up now
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Interface 'lan' is now up
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Interface 'loopback' is enabled
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Interface 'loopback' is setting up now
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Interface 'loopback' is now up
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Interface 'usbmodem' is enabled
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Interface 'wan' is enabled
Fri Mar 27 21:11:56 2020 daemon.notice netifd: bridge 'br-lan' link is up
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Interface 'lan' has link connectivity
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Network device 'eth0' link is up
Fri Mar 27 21:11:56 2020 daemon.notice netifd: VLAN 'eth0.1' link is up
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Network device 'lo' link is up
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Interface 'loopback' has link connectivity
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Network device 'usb0' link is up
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Interface 'usbmodem' has link connectivity
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Interface 'usbmodem' is setting up now
Fri Mar 27 21:11:56 2020 daemon.notice netifd: VLAN 'eth0.2' link is up
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Interface 'wan' has link connectivity
Fri Mar 27 21:11:56 2020 daemon.notice netifd: Interface 'wan' is setting up now
Fri Mar 27 21:11:57 2020 daemon.notice netifd: wan (1322): udhcpc: started, v1.30.1
Fri Mar 27 21:11:57 2020 daemon.notice netifd: usbmodem (1327): udhcpc: started, v1.30.1
Fri Mar 27 21:11:58 2020 daemon.err odhcpd[1108]: Failed to send to ff02::1%lan@br-lan (Address not available)
Fri Mar 27 21:11:58 2020 daemon.notice netifd: wan (1322): udhcpc: sending discover
Fri Mar 27 21:11:58 2020 daemon.notice netifd: usbmodem (1327): udhcpc: sending discover
Fri Mar 27 21:11:58 2020 user.notice firewall: Reloading firewall due to ifup of lan (br-lan)
Fri Mar 27 21:11:58 2020 user.notice mac80211: Failed command: iw phy phy1 set antenna 0xffffffff 0xffffffff
Fri Mar 27 21:11:58 2020 daemon.err odhcpd[1108]: Failed to send to fe80::1c9d:f38b:8fe4:c7e6%lan@br-lan (Address not available)
Fri Mar 27 21:11:58 2020 daemon.notice netifd: radio1 (1270): command failed: Not supported (-122)
Fri Mar 27 21:11:58 2020 user.notice mac80211: Failed command: iw phy phy1 set distance 0
Fri Mar 27 21:12:02 2020 daemon.err procd: unable to find /sbin/ujail: No such file or directory (-1)
Fri Mar 27 21:12:03 2020 user.notice ucitrack: Setting up /etc/config/network reload dependency on /etc/config/dhcp
Fri Mar 27 21:12:03 2020 user.notice ucitrack: Setting up /etc/config/network reload dependency on /etc/config/radvd
Fri Mar 27 21:12:03 2020 user.notice ucitrack: Setting up /etc/config/wireless reload dependency on /etc/config/network
Fri Mar 27 21:12:03 2020 user.notice ucitrack: Setting up /etc/config/firewall reload dependency on /etc/config/luci-splash
Fri Mar 27 21:12:03 2020 user.notice ucitrack: Setting up /etc/config/firewall reload dependency on /etc/config/qos
Fri Mar 27 21:12:03 2020 user.notice ucitrack: Setting up /etc/config/firewall reload dependency on /etc/config/miniupnpd
Fri Mar 27 21:12:04 2020 user.notice ucitrack: Setting up /etc/config/dhcp reload dependency on /etc/config/odhcpd
Fri Mar 27 21:12:04 2020 user.notice ucitrack: Setting up non-init /etc/config/fstab reload handler: /sbin/block mount
Fri Mar 27 21:12:04 2020 user.notice ucitrack: Setting up /etc/config/system reload trigger for non-procd /etc/init.d/led
Fri Mar 27 21:12:04 2020 user.notice ucitrack: Setting up /etc/config/system reload dependency on /etc/config/luci_statistics
Fri Mar 27 21:12:04 2020 user.notice ucitrack: Setting up /etc/config/system reload dependency on /etc/config/dhcp
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: started, version 2.80 cachesize 150
Fri Mar 27 21:12:05 2020 daemon.notice netifd: wan (1322): udhcpc: sending discover
Fri Mar 27 21:12:05 2020 daemon.notice netifd: usbmodem (1327): udhcpc: sending select for 192.168.128.104
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: DNS service limited to local subnets
Fri Mar 27 21:12:05 2020 daemon.notice netifd: usbmodem (1327): udhcpc: lease of 192.168.128.104 obtained, lease time 43200
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID loop-detect inotify dumpfile
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq-dhcp[1547]: DHCP, IP range 192.168.1.100 -- 192.168.1.249, lease time 12h
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: using local addresses only for domain test
Fri Mar 27 21:12:05 2020 daemon.notice procd: /etc/rc.d/S96led: setting up led WIFI
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: using local addresses only for domain onion
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: using local addresses only for domain localhost
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: using local addresses only for domain local
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: using local addresses only for domain invalid
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: using local addresses only for domain bind
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: using nameserver 127.0.0.1#5054
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: using nameserver fe80::1067:47ff:fe03:4363#53 for domain openwrt.pool.ntp.org
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: using nameserver 192.168.128.1#53 for domain openwrt.pool.ntp.org
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: using nameserver 127.0.0.1#5053
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: using local addresses only for domain lan
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: read /etc/hosts - 4 addresses
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: read /tmp/hosts/odhcpd - 0 addresses
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq[1547]: read /tmp/hosts/dhcp.cfg01411c - 12 addresses
Fri Mar 27 21:12:05 2020 daemon.info dnsmasq-dhcp[1547]: read /etc/ethers - 0 addresses
Enable both services, then reboot the router. Log in immediately, and see if the time is correct. Wait till it is correct, and see if it matches when DNS starts working again.
Even risking being accused of trolling:
I'd consider this a feature, not a bug. DNS over HTTPS is one of the worst things that could have happened to the Internet. That's not only my humble opinion, I do not know any networking expert without a pertinant agenda who considers it benevolent.
Overall, DoH does the opposite of improving your privacy. Your ISP can still see where you're surfing to, DoH hardly changes anything at this end. Organisations like Mozilla promise snake oil here. The backside is that in the end the surfing activity of everyone will be known to a very small set of DoH providers, possibly Cloudflare only (given that most users are to lazy to change the settings of their browser). Paradise for organisations like the NSA.
Even if you only consider DNS traffic, answer yourself the following question: Would you rather share your DNS traffic with your ISP, whom you (sort of) know, with whom you have a contract, which even enables you to sue if they release harmful data? Or would you share your data with a networking giant under US jurisdiction which you have no chance to sue, which probably by virtue of a National Security Letter (which is secret!) has a tap with direct connection to NSA headquarters?
In the end, you decide what you install. But I'd strongly encourage you to learn about ramifications first before doing so. I fail to see how anyone who does still wants DoH (unless their paycheck depends on it, of course).
4 Likes
What worries me even more about DNS over HTTPS, is the trend to move the DNS resolver from the OS (the libc on UN*X operating systems) to individual applications, as a result firefox might (will!) give you different DNS results than chromium, than edge, than nslookup/ traceroute on the cli - and you really need that to be the same, to do effective debugging. That's before even considering local domains, which are common among OpenWrt users, companies and universities at least.
Is this discussion worth a separate thread? This one is about making it work rather than about the moral implications of such decisions 
I synced my PC clock for a good reference. I ran service dnsmasq enable and service https-dns-proxy enable to make sure they were running at boot. I rebooted the router, immediately checked the time and it was accurate to within 2 seconds of my PC. I can even press sync with ntp in the system page and it completed. Still couldn't go to any websites. Left for 15 mins, came back and I could browse the web again. The only new events between that time was:
Sat Mar 28 17:17:32 2020 daemon.warn odhcpd[1110]: A default route is present but there is no public prefix on lan thus we don't announce a default route!
Sat Mar 28 17:26:51 2020 daemon.warn odhcpd[1110]: A default route is present but there is no public prefix on lan thus we don't announce a default route!
these were the commands from the guide I ran to install and set it up:
# Install packages
opkg update
opkg install https-dns-proxy
# Enable DNS encryption
uci -q delete dhcp.@dnsmasq[0].server
DOHPROXY_ADDR="$(uci get https-dns-proxy.@https-dns-proxy[0].listen_addr)"
DOHPROXY_PORT="$(uci get https-dns-proxy.@https-dns-proxy[0].listen_port)"
DOHPROXY_SERV="${DOHPROXY_ADDR//[][]/}#${DOHPROXY_PORT}"
uci add_list dhcp.@dnsmasq[0].server="${DOHPROXY_SERV}"
# Enforce DNS encryption for LAN clients
uci set dhcp.@dnsmasq[0].noresolv="1"
uci commit dhcp
/etc/init.d/dnsmasq restart
#####Local system#####
# Enforce DNS encryption for local system
uci set dhcp.@dnsmasq[0].localuse="1"
# Fetch DNS provider
. /lib/functions/network.sh
network_flush_cache
network_find_wan NET_IF
network_find_wan6 NET_IF6
network_get_dnsserver NET_DNS "${NET_IF}"
network_get_dnsserver NET_DNS6 "${NET_IF6}"
# Bypass DNS encryption for NTP provider
uci get system.ntp.server \
| sed -e "s/\s/\n/g" \
| sed -e "s/^[0-9]*\.//" \
| sort -u \
| while read -r NTP_DOMAIN
do
uci add_list dhcp.@dnsmasq[0].server="/${NTP_DOMAIN}/${NET_DNS%% *}"
uci add_list dhcp.@dnsmasq[0].server="/${NTP_DOMAIN}/${NET_DNS6%% *}"
done
uci commit dhcp
/etc/init.d/dnsmasq restart
I considered the fact that nothing is completely private especially since Google and Cloudflare fall under US jurisdiction but I thought I'd use it as an extra layer of privacy/alternative to paying for the extra protection of a VPN. I'll probably will subscribe to a VPN in the future.
I personally do not plan to engage in any discussion here.
I realised my point is slightly off-topic. However, posting this comment in this thread is justified by my intention to specifically address the top poster. I doubt the top poster would read it if I posted in some separate forum where it might be entirely on-topic.
Have you made any progress? I observed exactly the same behaviour as you did today - no DNS resolution for 15 minutes. No restart of dnsmasq / https-dns-proxy / network helps.
I am using DoT with stubby and the way to solve the race condition between NTP and DoT is to add make the ntp servers bypass DoT completely in /etc/config/dhcp:
list server '/openwrt.pool.ntp.org/9.9.9.9'
1 Like
I have that exact line in my config, and the problem still occurs. I wonder why it is 15 minutes... maybe there is a timeout (or cache?) in https-dns-proxy that stops retries?
Never got it to work. I started using a VPN instead.
Working without issues here.
BusyBox v1.31.1 () built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt SNAPSHOT, r13628-870588b6eb
-----------------------------------------------------
root@OpenWrt:~# cat /etc/config/dhcp
config dnsmasq
option domainneeded '1'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option localservice '1'
option localuse '1'
option noresolv '1'
option nonegcache '1'
option strictorder '1'
option allservers '1'
option cachesize '1000'
list addnhosts '/tmp/badhosts'
list address '/1e100.net/'
list server '/openwrt.pool.ntp.org/1.0.0.1'
list server '/openwrt.pool.ntp.org/1.1.1.1'
list server '127.0.0.1#5053'
list doh_backup_server '/openwrt.pool.ntp.org/1.0.0.1'
list doh_backup_server '/openwrt.pool.ntp.org/1.1.1.1'
list doh_backup_server '1.0.0.2#53'
list doh_backup_server '1.1.1.2#53'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option ra_slaac '1'
list ra_flags 'managed-config'
list ra_flags 'other-config'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
root@OpenWrt:~# cat /etc/config/firewall
config redirect 'dns_53'
option src 'lan'
option proto 'tcp udp'
option src_dport '53'
option dest_port '53'
option target 'DNAT'
option name 'DNS, port 53'
option dest 'lan'
root@OpenWrt:~# cat /etc/config/https-dns-proxy
config main 'config'
option update_dnsmasq_config '*'
config https-dns-proxy
option resolver_url 'https://security.cloudflare-dns.com/dns-query'
option listen_addr '127.0.0.1'
option user 'nobody'
option group 'nogroup'
option listen_port '5053'
option bootstrap_dns '1.1.1.2,1.0.0.2'So I think I know why it isn't working - You guys are close when you're thinking about the NTP servers - you do need to make sure that the time is accurate in order for SSL to work. I think the issue is with the default DNS server setup within the DHCP and DNS interface. DNS HTTPS Proxy, when started, updates the forwarding address in DHCP to 127.0.0.1#???? where ?'s are your port number for the given DoH provider. In my case, I use Cloudflare at port 5054 so when DNS HTTPS Proxy starts it updates the DNS Forwardings address in DHCP and DNS to 127.0.0.1#5054. That probably isn't happening on boot correctly. I ended up having to stop the service, delete everything out of my DNS forwardings, then manually add 127.0.0.1#5054 using the + sign and while the DNS HTTPS Proxy was stopped. After I saved it, I started the DoH service again, tested, then rebooted the router. Voilà! DNS over HTTPS now works on router boot. I made sure that the advertised DNS servers weren't being used on my WAN connection before doing this so I know that my requests are going through the DNS over HTTPS service.
There was an issue in version 2021-01-17-4 with the race condition with dnsmasq -- if dnsmasq didn't start before https-dns-proxy, the latter needed to be restarted. It has been fixed in 2021-01-17-5.
1 Like
I still have the same issue with 2021-01-17-5. I'm having to run a cronjob to stop and start the service once every 30 minutes. I've even reinstalled dhcp and dnsmasq. It still does this on boot with the latest version if I don't manually set the dns forward using that method. I suspect that the service was always running but that dns started leaking to the advertised servers over the wan and that it worked until... it didn't... for some reason... at which point it then automatically forwarded requests through the wan port. If I were you, I would double check your wan interface and make sure that "Use DNS servers advertised by peer" is unchecked in LUCi under the advanced settings tab of the wan interface. If it stops working after you uncheck then you were leaking. I double checked this by running my own DNS service on another server and found requests when I manually pointed the dns server under that interface.
Can you try capturing /etc/config/dhcp on boot when things are NOT working?
Unless you intentionally want it this way, I would advise against doing this, as this way with https-dns-proxy stopped you'd have no DNS resolution on your router.
What's that? No DNS until https-dns-proxy is started? Perfect.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.