Stubby-Installer-Asuswrt-Merlin

[cmkelley]

My guess would be because only one server is defined by default (1.1.1.1). I am unsure as to why the secondary 1.0.0.1 isn't also defined but I didn't generate the initial config.

I did some research and its recommended for performance to enable this. So I've done ahead and pushed a commit enabling the feature and also enabling the secondary cloudflare servers.


As usual, to apply this update you will need to run the "Update Stubby Configuration" option from the main menu.

IIRC, at some point in the past, 1.0.0.1 was determined not to support DoT. I'm at work, can someone try making 1.0.0.1 the only DNS server and make sure it supports DoT?

 

[Adamm]

IIRC, at some point in the past, 1.0.0.1 was determined not to support DoT. I'm at work, can someone try making 1.0.0.1 the only DNS server and make sure it supports DoT?

I double checked setting 1.0.0.1 as the only resolver. All tests passed.

 

[skeal]

Nice job again @Adamm !! Works awesome!

 

[Jack Yaz]

My guess would be because only one server is defined by default (1.1.1.1). I am unsure as to why the secondary 1.0.0.1 isn't also defined but I didn't generate the initial config.

I did some research and its recommended for performance to enable this. So I've done ahead and pushed a commit enabling the feature and also enabling the secondary cloudflare servers.


As usual, to apply this update you will need to run the "Update Stubby Configuration" option from the main menu.

Didn't @john9527 find there was an issue with RR not working reliably? Though I read that some time ago...

 

[skeal]

Didn't @john9527 find there was an issue with RR not working reliably? Though I read that some time ago...

If I remember right it was the setting of "1" or "0" he recommended not "0"

 

[bbunge]

Didn't @john9527 find there was an issue with RR not working reliably? Though I read that some time ago...

The issue was with Ordered (round_robin_upstreams: 0) not always switching to the next server. Using "round_robin_upstreams: 1" has prevented this issue as well as slightly improving performance (my observation). This is supposed to be fixed in the new version of Stubby/GetDNS.

 

[Xentrk]

My guess would be because only one server is defined by default (1.1.1.1). I am unsure as to why the secondary 1.0.0.1 isn't also defined but I didn't generate the initial config.

I did some research and its recommended for performance to enable this. So I've done ahead and pushed a commit enabling the feature and also enabling the secondary cloudflare servers.


As usual, to apply this update you will need to run the "Update Stubby Configuration" option from the main menu.

I think that sounds like the reason. Since I was only using a primary DNS and not a secondary, there was no reason to turn it on. I also recall reading about an issue with it on @john9527 thread. I think @bbunge captured it.

Also, when I specify the primary DNS of 1.1.1.1 with no secondary DNS, when I do an ipleak.net test, 13 DNS appear. So, there is already redundancy built into 1.1.1.1 by default. So I did not view having a secondary DNS as necessary. It is my understanding that having more DNS can impact performance as the router has to then spend the extra time querying all of the servers. So more not always better. I would have to go back and find the reference though to back this up. There is also some caveats with round_robin that Cloudflare covers here https://www.cloudflare.com/learning/dns/glossary/round-robin-dns/

Good read!

 

[DonnyJohnny]

I lost power last night (California isn't designed to deal with rain), and I'm at work today. Trying both CF DNS servers was next on my list. Since DoT is more of a gee-whiz for me (I'm not a political dissident in a totalitarian country), I'd like to avoid proxy-dnssec, since it somewhat defeats the purpose of DoT.

I think there is already a lot of post and article explaining dot and dnssec and they serve different purpose. There is no conflict in using proxy-dnssec with dot. As many posts and articles already states, they complement each other. In simple understanding, dnssec is like ensuring the queries(lookup) is verified from root all the way to you but the queries data is not encrypt. Encryption of these queries data is by dot/doh protocol.
Now, noted that when dns providers states that they are dnssec enabled. It mean from root zone to them the dns is secured (verified) however, from them to us, if dnssec is not enabled (router), we will fail the dnssec test as the test is done by your side(router). However sites like
http://en.conn.internet.nl/connection/ and https://dnssec.vs.uni-due.de/
They are testing between the dns provider u used and the root zone.
Site like 1.1.1.1/help are testing between you (router) and the site script used.

Now the difference between dnssec and dnssec-proxy is enabling dnssec without the proxy mean dnsmasq/stubby do the dnssec validation but with dnssec-proxy, it enabled dnssec validation on your router side by trusting dns provider’s own dnssec validation and forward the validation result to you and used as if you verified. That’s why the dnsmasq man (http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html)
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.
Meaning you need to trust the dns providers in their validation. I would assume those big dns providers players like Google/cloudflare/quad9 should be trustable compare to those private dns provider.

 

[skeal]

I think there is already a lot of post and article explaining dot and dnssec and they serve different purpose. There is no conflict in using proxy-dnssec with dot. As many posts and articles already states, they complement each other. In simple understanding, dnssec is like ensuring the queries(lookup) is verified from root all the way to you but the queries data is not encrypt. Encryption of these queries data is by dot/doh protocol.
Now, noted that when dns providers states that they are dnssec enabled. It mean from root zone to them the dns is secured (verified) however, from them to us, if dnssec is not enabled (router), we will fail the dnssec test as the test is done by your side(router). However sites like
http://en.conn.internet.nl/connection/ and https://dnssec.vs.uni-due.de/
They are testing between the dns provider u used and the root zone.
Site like 1.1.1.1/help are testing between you (router) and the site script used.

Now the difference between dnssec and dnssec-proxy is enabling dnssec without the proxy mean dnsmasq/stubby do the dnssec validation but with dnssec-proxy, it enabled dnssec validation on your router side by trusting dns provider’s own dnssec validation and forward the validation result to you and used as if you verified. That’s why the dnsmasq man (http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html)
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.
Meaning you need to trust the dns providers in their validation. I would assume those big dns providers players like Google/cloudflare/quad9 should be trustable compare to those private dns provider.

Thank you @DonnyJohnny for a clear analysis of the issue most people are worried about. I believe that DoT with proxy-dnssec is safe for the average user.

 

[cmkelley]

Thank you @DonnyJohnny for a clear analysis of the issue most people are worried about. I believe that DoT with proxy-dnssec is safe for the average user.

I'm gonna stick with @john9527's advice and not use it (see https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/page-7#post-441554). If you're legit worried about DNS hijack (i.e. the actual reason for DNSSEC), then using proxy-dnssec is self-defeating. I've not seen a competent argument as to why he's wrong (and I don't think he is). I really think proxy-dnssec is only useful for the case where you actually control the upstream DNS. Certainly, CloudFlare, Quad9, etc. are trustworthy, but that doesn't help in the case where their DNS servers have been somehow compromised without their knowledge.

Let's be honest, most average users in non-totalitarian countries don't need any of this stuff. They can just point their DNS at CloudFlare or even Google and be perfectly fine. If you're a user in say China, then you need all of it (and probably then some), and proxy-dnssec is dangerous. I mess with this stuff because it's interesting to me, not because I think there's a real issue I should be worried about. If you're like me, and it's all kinda just fun and games, then sure, proxy-dnssec is fine. But I choose to go all in or not at all.

(I wrongly stated in msg #697 that proxy-dnssec defeated the purpose of DoT. I should have said it defeats the purpose of DNSSEC. I regret the error.)

 

[dave14305]

I understand proxy-dnssec to just accept the validation provided by its immediate upstream resolver. In the context of this thread, that would be Stubby on your router. If you do not enable DNSSEC in Stubby to validate responses from your external upstream resolver, then I think having dnsmasq blindly trust the external reply can be risky. But I see no concern if you have dnsmasq trust Stubby's validation of DNSSEC as long as it's configured to do so.

I am also of the opinion that no external website can tell you if your clients are getting validated DNS responses. You have to do that locally with a dnssec-aware tool like dig or drill.

 

[preacher65]

Hrmmm. I have no stubby log anywhere on the filesystem.

However htop confirms it is being executed with "-g -v 5 -C /opt/etc/stubby/stubby.yml 2>/opt/var/log/stubby.log" per the S61stubby file.

That’s ok. Stubby logging sucks at the moment.

Sorry for replying to such an old post it just came up when I was searching.

I recently read through as many Stubby and DoT related posts as I could find in the thread for @john9527's fork and noticed that some users there were posting their Stubby logs. Much like @cmkelley (and doubtless others) I haven't been able to find any log files on the version we're discussing here - has anyone got it working? Is the problem just with certain models such as the HND routers?

 

[dave14305]

Sorry for replying to such an old post it just came up when I was searching.

I recently read through as many Stubby and DoT related posts as I could find in the thread for @john9527's fork and noticed that some users there were posting their Stubby logs. Much like @cmkelley (and doubtless others) I haven't been able to find any log files on the version we're discussing here - has anyone got it working? Is the problem just with certain models such as the HND routers?

John added his own custom logging code to stubby before compiling it into his firmware. Not yet available in vanilla Stubby.

 

[preacher65]

John added his own custom logging code to stubby before compiling it into his firmware. Not yet available in vanilla Stubby.

Thanks, at least that explains the difference.

 

[dave14305]

Neat tool to test DoH servers and options:
https://www.getdnsapi.net/query/

Not sure it has any practical applications other than nerding out.

 

[DonnyJohnny]

I'm gonna stick with @john9527's advice and not use it (see https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/page-7#post-441554). If you're legit worried about DNS hijack (i.e. the actual reason for DNSSEC), then using proxy-dnssec is self-defeating. I've not seen a competent argument as to why he's wrong (and I don't think he is). I really think proxy-dnssec is only useful for the case where you actually control the upstream DNS. Certainly, CloudFlare, Quad9, etc. are trustworthy, but that doesn't help in the case where their DNS servers have been somehow compromised without their knowledge.

Let's be honest, most average users in non-totalitarian countries don't need any of this stuff. They can just point their DNS at CloudFlare or even Google and be perfectly fine. If you're a user in say China, then you need all of it (and probably then some), and proxy-dnssec is dangerous. I mess with this stuff because it's interesting to me, not because I think there's a real issue I should be worried about. If you're like me, and it's all kinda just fun and games, then sure, proxy-dnssec is fine. But I choose to go all in or not at all.

(I wrongly stated in msg #697 that proxy-dnssec defeated the purpose of DoT. I should have said it defeats the purpose of DNSSEC. I regret the error.)

Regarding dns hijack, that’s where dot/doh comes in. The queries itself is encrypted between you and dns providers. Using those dns providers already mean you are trusting them.

If you are so afraid of dns hijack in the first place, you should not be using these dns providers and you need to set up and use your own dns resolving server and not third party like Google/cloudflare/quad9.

Therefore I don’t see any issue with proxy-dnssec with these major dns providers if we are already trusting them with resolving our dns queries in the first place.

In any case, for dnssec to work, For DNSSEC to work, the top-level domains need to be signed, and the registrars also need to support signing of DNSSEC keys. The security must flow down from the root keys in an unbroken chain to the record sets and hosts listed for a domain; any break in continuity and the DNS records cannot be validated.

Unfortunately while top-level domains are mostly dnssec ready https://www.internetsociety.org/blog/2018/07/tracking-dnssec-see-the-deployment-maps/ but not for registrars and we already see many sites not dnssec ready.

 

[cmkelley]

So the part I don't get then is, if you trust your upstream DNS enough to feel safe using proxy-dnssec, why bother using DNSSEC at all? What exactly does it get you?

 

[DonnyJohnny]

So the part I don't get then is, if you trust your upstream DNS enough to feel safe using proxy-dnssec, why bother using DNSSEC at all? What exactly does it get you?

It is something like telling the upstream to send you only validated queries back to you. If you don’t have that dnssec-proxy, upstream will not do the dnssec validation.
That’s why when dig test ( eg.
dig pir.org +dnssec +multi ), you will not see the ad flag if dnssec-proxy (upstream) or dnssec (router side) is not enabled.

 

[skeal]

It is something like telling the upstream to send you only validated queries back to you. If you don’t have that dnssec-proxy, upstream will not do the dnssec validation.
That’s why when dig test ( eg.
dig pir.org +dnssec +multi ), you will not see the ad flag if dnssec-proxy (upstream) or dnssec (router side) is not enabled.

So in fact they compliment each other?

 

[bbunge]

It is something like telling the upstream to send you only validated queries back to you. If you don’t have that dnssec-proxy, upstream will not do the dnssec validation.
That’s why when dig test ( eg.
dig pir.org +dnssec +multi ), you will not see the ad flag if dnssec-proxy (upstream) or dnssec (router side) is not enabled.

I am using iOS and android Dig apps. When I enabled proxy-dnssec I was able to get the AD flag on the apps. Yes, there are a lot of opinions on DoT/DoH and DNSSEC. There is a link in a prior post that has a good article on the topic

Edit link https://blog.apnic.net/2018/08/17/sunrise-dns-over-tls-sunset-dnssec/

Sent from my SM-T380 using Tapatalk