Stubby-Installer-Asuswrt-Merlin

[DonnyJohnny]

Without the proxy-dnssec statement, the ad flag would be missing from dig output for example (at least it behaved that way in my testing)

Dont think so...

Here is some good bedtime reading: https://labs.ripe.net/Members/willem_toorop/sunrise-dns-over-tls-sunset-dnssec

As I read that article, DoT and DNSSEC are needed together. It does not seem to matter if you use DNSSEC with Stubby or with dnsmasq. The security results should be the same. I have Asus routers working both ways. One on Merlin 384.7_2 with Stubby Entware and two on John's 36E9. Interesting that John's fork works well with Quad9 and my home router on Merlin does not like Quad9. I suspect it is my lousy DSL service at home!
As for now the girls are happy and oblivious to the added security for DNS. As long as the network stays up I have a happy home!

Read the article. In this case the duty of dnssec validation is passed to our resolver (CF in this case) by using the proxy-dnssec.

Then we do not need to enable router/stubby/dnscrypt-proxy dnssec validation as it would be wasting of system resources because cloudflare already done the validation. (Not sure of proxy-dnssec will override the system dnssec validation if dnssec validation is also enabled)

You may experience yourself that with proxy-dnssec enable, off your dnssec validation. You will still get the ad flag.
If you disable both dnssec validation and proxy-dnssec, then you will not get the ad flag as there is not validation done.

Based on the articles, i assumed dot/dns has created a secured path for dns traffic. So Long as cloudflare verified the dns request (dnssec), mean the dns forward to us is definitely correct and clean since it is in a secured path?

 

[skeal]

If you disable both dnssec validation and proxy-dnssec, then you will not get the ad flag as there is not validation done.

I'm not sure I follow you. I have added proxy-dnssec in my setup what else am I missing here. Is there another command to enable validation? Or is that handled by the added instruction in the.yml file?

 

[DonnyJohnny]

I'm not sure I follow you. I have added proxy-dnssec in my setup what else am I missing here. Is there another command to enable validation? Or is that handled by the added instruction in the.yml file?

What I am saying is when u have proxy-dnssec enabled, you don’t need to enable the stubby dnssec extension nor Merlin dnssec validation. You will still get the ad flag as dnssec validation is passed to cloudflare (resolver that support dnssec) to do the final validation.

By the way, when u use kdig or dig, you don’t need to specify the IP address or host name for the resolver. If u do that, you are not testing if stubby/dnscrypt-proxy is working as the test bypass them and use the resolver itself (ie cloudflare for your case). You may just specify the ip as 127.0.0.1 as this will pass the dns request to stubby/dnscrypt-proxy and push to cloudflare via dot/doh

 

[skeal]

To be certain again...we do not require this

dnssec_return_status: GETDNS_EXTENSION_TRUE

in the .yml if we have proxy-dnssec enabled in dnsmasq?

 

[DonnyJohnny]

To be certain again...we do not require this

dnssec_return_status: GETDNS_EXTENSION_TRUE

in the .yml if we have proxy-dnssec enabled in dnsmasq?

Yes and don’t need Merlin dnssec validation too.
You should still see the ad flag with just proxy-dnssec.

What is proxy-dnssec
--proxy-dnssec
Copy the DNSSEC Authenticated Data bit from upstream servers to downstream clients and cache it. This is an alternative to having dnsmasq validate DNSSEC, but it depends on the security of the network between dnsmasq and the upstream servers, and the trustworthiness of the upstream servers.

http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

Assuming cloudflare is secured and not hacked and allow hacker to edit the dns request? I believed they are good and more secured. Both I don’t trust other dns resolvers made by volunteers. Do take note especially those auto use multiple dns resolvers with dnscrypt-proxy.

 

[skeal]

Yes and don’t need Merlin dnssec validation too.
You should still see the ad flag with just proxy-dnssec.

What is proxy-dnssec
--proxy-dnssec
Copy the DNSSEC Authenticated Data bit from upstream servers to downstream clients and cache it. This is an alternative to having dnsmasq validate DNSSEC, but it depends on the security of the network between dnsmasq and the upstream servers, and the trustworthiness of the upstream servers.

http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

Assuming cloudflare is secured and not hacked and allow hacker to edit the dns request? I believed they are good and more secured. Both I don’t trust other dns resolvers made by volunteers. Do take note especially those auto use multiple dns resolvers with dnscrypt-proxy.

Wow! This makes the https://1.1.1.1/help page work and yes I've done digs from the router and the "ad" flag is there. Thanks @DonnyJohnny !!

 

[bbunge]

Well, I was just about to call a foul on DonnyJohnny but decided to try it out. I commented out
dnssec_return_status: GETDNS_EXTENSION_TRUE from the stubby.yml and did a dig to my 1.1.1.1 resolver and got the ad flag. I enabled DNSSEC in the Asus LAN DHCP Server gui and got the ad flag. Disabled that and switched to Quad9 resolvers, did a dig and got the ad flag. Switched the NTP server back to ntp.pool.org rebooted the router. Yes, everything connected and Quad9 finally seems to be working for me.
And skeal, I too got the same results from Cloudflare help page!

Now, do we need to worry about why just proxy-dnssec works?

 

[john9527]

Now, do we need to worry about why just proxy-dnssec works?

I need to think about this a bit more...but right now I'm worried about this solution. For DNSSEC to be fully effective, the DNSSEC validation needs to be performed at the origin of the dns request (in this case at the router with either stubby or dnsmasq). Otherwise, you could be subject to a DNS hijack.

As far as why Cloudfare causes problems, they are using an unusual encryption, ECDSA-P256-SHA256, which they have 'customized' for speed. I'm thinking that the standard crypto libraries of OpenSSL and nettle may be having problems with it.

 

[bbunge]

From the dnsmasq man page:
--proxy-dnssec
Copy the DNSSEC Authenticated Data bit from upstream servers to downstream clients and cache it. This is an alternative to having dnsmasq validate DNSSEC, but it depends on the security of the network between dnsmasq and the upstream servers, and the trustworthiness of the upstream servers.
My read on this is that the "ad" bit is retieved from the resolver with proxy-dnssec set but no validation is done.
Does enabling DoT in stubby provide enough security that we do not have to do the DNSSEC validation?
Me thinks...no. DoT with DNSSEC validation should be used. It should not matter if you use DNSSEC in dnsmasq or stubby. But use it you should.

 

[skeal]

Its looking like stubby won't run with dnsmasq handling dnssec. I enable the options in the webui and run stubby and I have no dns. The validation setting is the culprit. So right now something is resolving dnssec signatures for stubby. Stubby is not truly handling dnssec at the source as we want.

 

[john9527]

Its looking like stubby won't run with dnsmasq handling dnssec.

My fork ran with stubby/dnsmasq dnssec up until the latest release when I switched to stubby dnssec. It does work.

 

[skeal]

My fork ran with stubby/dnsmasq dnssec up until the latest release when I switched to stubby dnssec. It does work.

What I did was removed the dnssec line from the .yml file and removed proxy-dnssec in the conf.add and instead enabled the two options in the webui. It broke the dns.

 

[skeal]

The only way to make it work was to back out of the settings.

 

[john9527]

It's probably a timing issue (especially if you are testing with a reboot).

AFAIK, TLS amd DNSSEC won't work without a valid system time, so you have to initially start stubby in 'opportunistic' mode without DNSSEC, then restart stubby using TLS 'strict' mode with DNSSEC after the clock is sync'ed. Not sure how the stubby script handles this.

EDIT: You might try installing fake-hwclock and see if that fixes the problem.

EDIT2: Come to think about it, this may also be the reason that some people have problems with the dynamic dnssec anchors being loaded correctly with stubby dnssec.

 

[skeal]

It's probably a timing issue (especially if you are testing with a reboot).

AFAIK, TLS amd DNSSEC won't work without a valid system time, so you have to initially start stubby in 'opportunistic' mode without DNSSEC, then restart stubby using TLS 'strict' mode with DNSSEC after the clock is sync'ed. Not sure how the stubby script handles this.

Gotcha!!

 

[DonnyJohnny]

I need to think about this a bit more...but right now I'm worried about this solution. For DNSSEC to be fully effective, the DNSSEC validation needs to be performed at the origin of the dns request (in this case at the router with either stubby or dnsmasq). Otherwise, you could be subject to a DNS hijack.

As far as why Cloudfare causes problems, they are using an unusual encryption, ECDSA-P256-SHA256, which they have 'customized' for speed. I'm thinking that the standard crypto libraries of OpenSSL and nettle may be having problems with it.

that's what I trying to say, the first and last mile between us (dnsmasq/stubby) and resolver.
Now I am assuming that with dot/doh creating the secured path, it should not be hijack? And we rely on cloudflare security to prevent any hijack between them and the root server.

 

[skeal]

It's probably a timing issue (especially if you are testing with a reboot).

AFAIK, TLS amd DNSSEC won't work without a valid system time, so you have to initially start stubby in 'opportunistic' mode without DNSSEC, then restart stubby using TLS 'strict' mode with DNSSEC after the clock is sync'ed. Not sure how the stubby script handles this.

EDIT: You might try installing fake-hwclock and see if that fixes the problem.

Time shouldn't be an issue as my setting for time is an IP not "pool.ntp.org" and I have no issues with the boot.

 

[john9527]

that's what I trying to say, the first and last mile between us (dnsmasq/stubby) and resolver.
Now I am assuming that with dot/doh creating the secured path, it should not be hijack? And we rely on cloudflare security to prevent any hijack between them and the root server.

It's my understanding that the TLS encryption and DNSSEC perform two distinctly different functions, and while it would be harder to do, it would be possible for someone to hijack the dns and still create a valid encrypted path. Maybe I'm mistaken....

 

[bbunge]

I tested John's latest release overnight and it worked very well with Stubby and DNSSEC enabled. The ability to make changes to upstream resolvers in the GUI is great for the average user.
I decided to go back to Merlin 384.7_2 with the Entware Stubby add on because of a couple of "extras" that are included in the firmware.
I also wanted to try a different location for the trust anchors. The default location is on the USB drive which is not really a fast read/write. I had mentioned a while back that I tested using the /jffs to store the trust anchors and got loads of grief about wearing out the NAND. Thinking about where elst that is fast I decided to try the /dev/shm as in most Linux distros this is tmpfs or, for the old guys, RAM drive. Asus probably does not have a lot of space there to use but with three files of 7KB total it should work. And it does quite well.
In the stubby.yml change to:

appdata_dir: "/dev/shm"

Some of you will quickly point out that tmpfs is wiped on restart and those three files will be lost forever. So what? Stubby will download fresh trust anchors the first time a DNS request is made.
Oh, I have set the NTP Server to an IP address of a time server.
Am also successfully using the CleanBrowsing Security resolvers.

 

[Xentrk]

It's probably a timing issue (especially if you are testing with a reboot).

AFAIK, TLS amd DNSSEC won't work without a valid system time, so you have to initially start stubby in 'opportunistic' mode without DNSSEC, then restart stubby using TLS 'strict' mode with DNSSEC after the clock is sync'ed. Not sure how the stubby script handles this.

EDIT: You might try installing fake-hwclock and see if that fixes the problem.

EDIT2: Come to think about it, this may also be the reason that some people have problems with the dynamic dnssec anchors being loaded correctly with stubby dnssec.

I did create an issue with the Stubby Developers and DNSSEC trust anchor files. I am monitoring the issue here https://github.com/getdnsapi/getdns/issues/408.

Unfortunately, My laptop is in the shop which is preventing further testing on my end for the next several weeks.