Stubby-Installer-Asuswrt-Merlin

[Jack Yaz]

Can this be done in /jffs/configs/ ?

Yes add it to /jffs/configs/dnsmasq.conf.add

 

[skeal]

Bit of a tangent (ish), I wonder if that's what dnscrypt needs for dnssec...

EDIT: added, so far so good (apparently i had already proxy-dnssec to my dnsmasq but not yet re-enabled dnssec validation, oops)

Where are you selecting or coding dnssec validation? I'm confused a bit.

 

[john9527]

Bit of a tangent (ish), I wonder if that's what dnscrypt needs for dnssec...

EDIT: added, so far so good (apparently i had already proxy-dnssec to my dnsmasq but not yet re-enabled dnssec validation, oops)

I admit I haven't kept up with dnscrypt v2. As I understand it, the proxy-dnssec statement is telling dnsmasq it should pass on the dnssec results from upstream in it's responses. I don't know if dnscrypt is doing it's own dnssec validation that would need to be passed on.

 

[skeal]

Thanks guys, I got it working. How does one test for DoT if the cloudflare site fails?

 

[bbunge]

Thanks guys, I got it working. How does one test for DoT if the cloudflare site fails?

Currently there is no test for both. Test for DoT then turn on DNSSEC either in the gui or stubby.yml then check with dig.
See my post from two days back for my config.

Sent from my SM-T380 using Tapatalk

 

[skeal]

So to be clear there is no way to determine if they both work at the same time. I know their jobs are different but are they working is the question?

 

[john9527]

So to be clear there is no way to determine if they both work at the same time. I know their jobs are different but are they working is the question?

Outside of my fork, you can kill stubby, then restart it in the foreground with a loglevel of 7.....then you can watch the TLS negotiations take place (Beware....this generates LOTS of data )

 

[skeal]

Outside of my fork, you can kill stubby, then restart it in the foreground with a loglevel of 7.....then you can watch the TLS negotiations take place (Beware....this generates LOTS of data )

I'm a low traffic kind of guy. Just interested in security. I will take @john9527 advice that it is working, I have been following him for years now and never had bad advice. You rock @john9527

 

[DonnyJohnny]

I admit I haven't kept up with dnscrypt v2. As I understand it, the proxy-dnssec statement is telling dnsmasq it should pass on the dnssec results from upstream in it's responses. I don't know if dnscrypt is doing it's own dnssec validation that would need to be passed on.

With that proxy-dnssec enabled, be it our router/stubby has dnssec verification enabled or not, the ad flag is always there as cloudflare already done the validation and passed on to us.

So what it mean? We handed the dnssec validation to cloudflare? Will last mile from cf to us be attacked?

 

[john9527]

With that proxy-dnssec enabled, be it our router/stubby has dnssec verification enabled or not, the ad flag is always there as cloudflare already done the validation and passed on to us.

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)

 

[skeal]

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)

What does this command prove?

kdig -d @1.1.1.1 +dnssec +tls-ca +tls-host=cloudflare-dns.com  example.com

 

[skeal]

Figured it out, this command should look like this to show both dnssec and DoT working (note the flags):

kdig -d @1.1.1.1 +dnssec +tls-ca +tls-host=cloudflare-dns.com  example.com

 

[skeal]

Figured it out, this command should look like this to show both dnssec and DoT working (note the flags):

kdig -d @1.1.1.1 +dnssec +tls-ca +tls-host=cloudflare-dns.com  example.com

You can alter this command to look like this:

kdig -d @1.1.1.1 +dnssec +tls-ca +tls-host=cloudflare-dns.com  asuswrt-lostrealm.ca

Still works awesome.

 

[bbunge]

So what it mean? We handed the dnssec validation to cloudflare? Will last mile from cf to us be attacked?

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!

 

[skeal]

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!

The above command shows that both are working against the same site, this was run from a Ubuntu desktop Terminal.

 

[skeal]

Expected output: Right from cloudflare for rhis command

$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com  example.com
;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 170 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=CA,L=San Francisco,O=Cloudflare\, Inc.,CN=\*.cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA
;; DEBUG:      SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted.
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GC
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 58548
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1536 B; ext-rcode: NOERROR
;; PADDING: 408 B

;; QUESTION SECTION:
;; example.com.             IN  A

;; ANSWER SECTION:
example.com.            2347    IN  A   93.184.216.34

;; Received 468 B
;; Time 2018-03-31 15:20:57 PDT
;; From 1.1.1.1@853(TCP) in 12.6 ms

I modified the command to include two things. I included a known site that has dnssec with full support. And include the +dnssec flag in the command
The return is excellent, asuswrt-lostrealm.ca has working and maintained dnssec support. My kdig command queries the TLS server and returns the successful results above. The only unusual part is that our routers only support TLS 1.2 at this point and will soon adopt 1.3.
This test shows both working at the same time.

The up to date command is:

kdig -d @1.1.1.1 +dnssec +tls-ca +tls-host=cloudflare-dns.com  asuswrt-lostrealm.ca

 

[skeal]

Check for "ad" flag...

 

[bbunge]

Check for "ad" flag...

Try it again without asuswrt-lostrealm.ca
Since you are interested in communication with a resolver only use a resolver in the dig test.

Sent from my SM-T380 using Tapatalk

 

[skeal]

Try it again without asuswrt-lostrealm.ca
Since you are interested in communication with a resolver only use a resolver in the dig test.

Sent from my SM-T380 using Tapatalk

You are right sir:

 kdig -d @1.1.1.1 +dnssec +tls-ca +tls-host=cloudflare-dns.com
;; DEBUG: Querying for owner(.), class(1), type(2), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 133 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=CA,L=San Francisco,O=Cloudflare\, Inc.,CN=*.cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA
;; DEBUG:      SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted.
;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 52206
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 14; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 1452 B; ext-rcode: NOERROR
;; PADDING: 215 B

;; QUESTION SECTION:
;; .                           IN    NS

;; ANSWER SECTION:
.                       6014    IN    NS    c.root-servers.net.
.                       6014    IN    NS    d.root-servers.net.
.                       6014    IN    NS    e.root-servers.net.
.                       6014    IN    NS    f.root-servers.net.
.                       6014    IN    NS    g.root-servers.net.
.                       6014    IN    NS    h.root-servers.net.
.                       6014    IN    NS    i.root-servers.net.
.                       6014    IN    NS    j.root-servers.net.
.                       6014    IN    NS    k.root-servers.net.
.                       6014    IN    NS    l.root-servers.net.
.                       6014    IN    NS    m.root-servers.net.
.                       6014    IN    NS    a.root-servers.net.
.                       6014    IN    NS    b.root-servers.net.
.                       6014    IN    RRSIG    NS 8 0 518400 20181114170000 20181101160000 2134 . p4c0G2IIb6Yq7Vwj3vJ7JQnRHfkNQ6oBFmio3gRspgIHfRi5nluTq5P8HUB2QljeBaTB+YIjjAzMCWqmDF8edaRLHwOrFHerhUUlQuUNskg1CxR8eqdInCNchKGMoZ9qeaP51mT93DtvnbvsQFuLYEhgX169VzUzcWPDYaUeHwxJd4fQ2IH9qf7J5EEf+LXvDbuU3DVpuYNafzXI2BS7huJfjJt+tKblnGH1YRrwn6/C8NsYZ6XutVi+9pCe4mhKSAqxRhrGcJ67c79GY3nH57KVVWyr4Tt5J/g38DEmFCRCGseES15It59SRCiFdHn4COsg9yWQM+APARq4DC95ww==

;; Received 936 B
;; Time 2018-11-01 20:23:43 CST
;; From 1.1.1.1@853(TCP) in 22.1 ms

 

[Xentrk]

yes....and you also need to add
proxy-dnssec
to /etc/dnsmasq.conf with an add or postconf script

Interesting! I saw that setting in the OpenWRT tutorial I used as a guide for implementing on Asuswrt Merlin. But I thought it was a setting specific to OpenWRT. I can easily update the installer to include it. I can only monitor how testing goes for everyone right now. I am hindered from making changes as my laptop is in the shop for repair.