How does your router connect to your ISP? Via another router/modem? USB modem? Does it obtain the address vi DHCP?
rc.local, the startup script is executed after all system init is done. So something like getting a DHCP lease occurs before rc.local runs.
Many thanks. It is a router / modem all-in-one and connects directly via the Phone line, ADSL / PPoA.
Looking in /etc/rc.d I notice that stubby is S50, but S97 is dsl_control. Does this mean the dsl connection is made after stubby starts?
Yes, that's exactly what it means.
If I'm not mistaken, rc.local is started by S95done, which might explain the issue. Your dsl_control is starting after rc.local is executed and it will wait until rc.local finishes, so that explains why sleep doesn't make a difference.
If you change stubby to S98 you won't need to have it restarting on rc.local.
Ok so we are finally getting somewhere!
I'll give it a try and report back tomorrow (will have to wait a while before I can reboot)
Yeah, just rename S50... to S98...
1 Like
@Specimen
ok, so after much fiddling, it's still not working!
I've changed around rc.d so that by the time rc.local is running, there is internet (I checked with a ping) and stubby is running (checked via ps | grep stubby), but the line sh /etc/init.d/stubby restart in rc.local doesn't seem to restart stubby. Or at least not in a way that downloads the DNSSEC certificates. I am at a loss what to try next.
The changes in the start sequence that I suggested are for stubby to start as a service automatically after the DSL connection is up and running, if that works you shouldn't need sh /etc/init.d/stubby restart and this should be the preferred way.
However, because rc.local is run via S95done and the dsl only comes up after that, /etc/init.d/stubby restart will NEVER run with an available internet connection., in that case you would have to change dsl control from S97 to S94.
@Specimen.
I am running dsl_control at S40.
Internet is up by the time S95done / rc.local is run. Stubby is also running (stubby is S50). But no certs are downloaded, and when rc.local runs, stubby restart doesn't download the certs. Which is why I am at a loss to explain the results.
Check the logs with logread, maybe set the verbosity when starting stubby to check for any errors.
You can always disable the service and start stubby in rc.local (after dsl_control) via sh /usr/sbin/stubby -g instead.
Ok thanks for the suggestion. No luck yet, but I've noticed some strange behaviour. When restarting stubby manually the 3 cert files will download fine, in particular root.key. But after an hour or so the root.key file becomes zero bytes in size. Is that supposed to happen?
AFAIK, root.key is generated automatically from the other two files.
Ok I have a weird situation going on.
I've disabled dnssec validation in stubby, i.e. I've removed the lines:
dnssec_return_status: GETDNS_EXTENSION_TRUE
appdata_dir: "/certs"
and yet dnssec validation is still working. I know its not stubby doing the dnssec validation because if I delete the certificates directory line only, then dnssec doesn't work i.e. stubby needs a writable directory for certificates and the default directory (/root), is non-writable by stubby.
So what is doing the dnssec validation?
The reason I turned off dnssec validation in stubby was because I was going to try doing dnssec with dnsmasq instead, but in order to do that I had to install dnsmasq-full and add a couple of lines to the dnsmasq section of /etc/config/dhcp.
But before I had done any of that, dnssec validation was working by itself, just by removing the option to enable it in stubby!
Does anyone have any idea what is going on and who or what is performing the dnssec validation? Many thanks!
The immediate thing that comes to mind is caches.
I thought similar. But it happens even after reboot. Even after re-flashing firmware. Even after restarting pc. Even in multiple browsers. Even with multiple methods of checking dnssec including using dig. I'm completely baffled.
Just an update, I figured out that the browsers were unreliable for testing DNSSEC in that they would always pass even if DNSSEC was not set up on router. The only time they would fail would be if stubby was set up to do DNSSEC but wasn't working (e.g. due to being unable to store certificates). If I turned off DNSSEC in stubby and didn't activate it in dnsmasq then all browser tests would still pass DNSSEC testing. I'm not sure if it was the browsers or OS doing that.
The most reliable way to see if DNSSEC is working seems to be to use dig on the router itself. That told me definitively that it wasn't working (when I had turned it off in stubby and hadn't yet set it up in dnsmasq), despite the fact that all browsers in both linux & windows were passing all DNSSEC tests.
I've now switched to doing DNSSEC with dnsmasq as the certificates issue proved too flakey in stubby, where as dnsmasq just works out of the box.
My setup is pretty much along the lines of here:
https://candrews.integralblue.com/2018/08/dnssec-on-openwrt-18-06/
https://candrews.integralblue.com/2018/08/dns-over-tls-on-openwrt-18-06/
In the version 18 and later builds of OpenWRT step 9A should be modified as follows to keep from having two IPv6 DHCP servers running:
A - opkg install dnsmasq-full --download-only && opkg remove odhcpd-ipv6only && opkg remove dnsmasq && opkg install dnsmasq-full --cache . && rm *.ipk
Dear Jbrossard,
Hello and I hope that you are well. I changed the step 9A as you informed everyone. Thanks for the heads up.
Peace
directnupe
@All
@ directnupe Thank you for your time&effort to write this comprehensive tutorial.
I am using OpenWRT 18.06.2 and a logread shows nasty warnings from dnsmasq:
daemon.warn dnsmasq[13761]: possible DNS-rebind attack detected: cmp.faktor.mgr.consensu.org
daemon.warn dnsmasq[13761]: reducing DNS packet size for nameserver 127.0.0.1 to 1280
daemon.warn dnsmasq[13761]: possible DNS-rebind attack detected: cmp.faktor.mgr.consensu.org
daemon.warn dnsmasq[13761]: Insecure DS reply received, do upstream DNS servers support DNSSEC?
I did a netstat -pln on my router:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:5453 0.0.0.0:* LISTEN 13821/stubby
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1250/uhttpd
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 13761/dnsmasq
tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN 13761/dnsmasq
tcp 0 0 192.168.8.100:53 0.0.0.0:* LISTEN 13761/dnsmasq
tcp 0 0 192.168.2.250:53 0.0.0.0:* LISTEN 13761/dnsmasq
tcp 0 0 0.0.0.0:2008 0.0.0.0:* LISTEN 678/dropbear
tcp 0 0 :::12865 :::* LISTEN 845/netserver
tcp 0 0 ::1:5453 :::* LISTEN 13821/stubby
tcp 0 0 :::80 :::* LISTEN 1250/uhttpd
tcp 0 0 ::1:53 :::* LISTEN 13761/dnsmasq
tcp 0 0 fe80::7ad2:94ff:fea8:2829:53 :::* LISTEN 13761/dnsmasq
tcp 0 0 fe80::7ad2:94ff:fea8:2828:53 :::* LISTEN 13761/dnsmasq
tcp 0 0 fe80::7ad2:94ff:fea8:2828:53 :::* LISTEN 13761/dnsmasq
tcp 0 0 fe80::7ad2:94ff:fea8:2829:53 :::* LISTEN 13761/dnsmasq
tcp 0 0 fe80::7ad2:94ff:fea8:282b:53 :::* LISTEN 13761/dnsmasq
tcp 0 0 fe80::506e:54ff:feb9:66b9:53 :::* LISTEN 13761/dnsmasq
tcp 0 0 fe80::7ad2:94ff:fea8:282a:53 :::* LISTEN 13761/dnsmasq
udp 0 0 127.0.0.1:53 0.0.0.0:* 13761/dnsmasq
udp 0 0 192.168.1.1:53 0.0.0.0:* 13761/dnsmasq
udp 0 0 192.168.8.100:53 0.0.0.0:* 13761/dnsmasq
udp 0 0 192.168.2.250:53 0.0.0.0:* 13761/dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:* 13761/dnsmasq
udp 0 0 127.0.0.1:5453 0.0.0.0:* 13821/stubby
udp 0 0 0.0.0.0:1234 0.0.0.0:* -
udp 0 0 :::546 :::* 1443/odhcp6c
udp 0 0 ::1:53 :::* 13761/dnsmasq
udp 0 0 ::1:5453 :::* 13821/stubby
It looks like dnsmasq is opening port 53, 67 on my router. Is this expected behaviour?