r38159 already? 2019's first!

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Marvell MVEBU based Hardware (WRT1900AC etc.)
Author Message
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 506
Location: Appalachian mountains, USA

PostPosted: Sun Jan 06, 2019 17:18    Post subject: Reply with quote
DaveI wrote:
I would greatly appreciate if you describe the steps necessary to add Quad9 as a DNSCrypt DNS resolver. I've been using Quad9 since last fall but was uncertain how to do the DNSCrypt since they're not in DD's list.


Hello DaveI! I always look for your post in a new-build thread. If you find the new build safe for the router model that we have in common, I am reassured that it may be worth a go. Good to meet you.

So, how to use Quad9 via DNSCrypt. Please excuse me if I get a bit pedantic here, but I'd like to also make this available for those less experienced than you are.

First, in GUI>Services>Services>ServicesManagement>DNSMasq, enable Cache DNSSEC data and Validate DNS Replies (DNSSEC), since Quad9 supports DNSSEC, but do NOT enable Encrypt DNS, as doing so would start up a dnscrypt-proxy process tied to a resolver from the drop-down menu, which does not contain Quad9. Then in Additional DNSMasq Options below those buttons, enter this.
Code:
no-resolv
server=127.0.0.1#30

I'm not an expert, but I believe no-resolv prevents DNSMasq from falling back to ISP-provided resolvers if getting through to Quad9 takes too long. The important line is the server= line, which tells DNSMasq to use loopback IP 127.0.0.1, port 30, as its DNS resolver. Note that where others use a colon to specify a port, DNSMasq uses the pound sign. Save the changes but do not apply, as at this point there is nothing on that server for DNSMasq to find.

Now go to GUI>Administration>Commands>Diagnostics>CommandShell. If you already have Startup Commands, hit its Edit button to move it to the Commands window. Otherwise proceed directly to the Commands window and add this:

Code:
( STARTED=/tmp/root/StartedDNSCrypt
  [[ -f $STARTED ]] && exit || touch $STARTED
  dnscrypt-proxy -d -S -a 127.0.0.1:30 \
  -r 9.9.9.9:8443 -N 2.dnscrypt-cert.quad9.net -k \
  67c8:47b8:c875:8cd1:2024:5543:be75:6746:df34:df1d:84c0:0b8c:4703:68df:821d:863e
)

Click Save Startup to save to Startup Commands. The next time you boot, DNSMasq should be using DNSCrypt, which should in turn be using Quad9 as its DNS resolver. The parentheses put all the action inside a subshell that can be exited before starting dnscrypt-proxy if this isn't the first time the code has been run. This early exit mechanism is needed because dd-wrt sometimes reruns the startup code.

The quick test, per Quad9's suggestion, is to visit dnsleaktest.com and use the extended test. It should show servers with ISP WoodyNet. You can also visit ipleak.net and notice the DNS Addresses section, which should show a few (2 to 14 or so in my experience so far) servers in a common location. I'm US-based and so far have seen servers in Illinois, Georgia, Virginia, and California in different experiments. Also, in the CLI you can do ps | grep dns and should see a dnsmasq process and a dnscrypt-proxy process, with the latter mirroring the above dnscrypt-proxy command (if your terminal is wide enough).

If you use the OpenVPN client with PBR to restrict it to subnet X, you have the option of going to GUI>Setup>Networking and finding that subnet's Optional DNS Target field and replacing your VPN provider's DNS server's IP with your subnet's gateway IP 192.168.X.1 in order to use (to "leak" to) Quad9's DNS servers when on subnet X. I do this to get Quad9's malware filtering, which my VPN provider's DNS server does not provide. If the subnet is for an unbridged wifi interface or virtual interface, you can instead set this in GUI>Wireless>BasicSettings in the section for that interface after checking Advanced Settings there and looking down near the end for Optional DNS Target. (I used the latter approach, so I'm only assuming you can change it under Networking.)

If you want a backup DNSCrypt server from our built-in list to cover you in the unlikely case that Quad9 is ever unavailable (which I gather is extremely unlikely), add a server=127.0.0.2#30 just before server=127.0.0.1#30 in the Additional DNSMasq Options above, and in Startup Commands add, say to use adguard-dns (malware filtering plus ad filtering),
Code:
 dnscrypt-proxy -d -S -a 127.0.0.2:30 \
  -R adguard-dns -L /etc/dnscrypt/dnscrypt-resolvers.csv

either before or after the earlier call to dnscrypt-proxy (but stay inside the parens). Order matters only for the server= lines, because DNSMasq apparently uses the last one first.

Background and References

The /etc/dnscrypt/dnscrypt-resolvers.csv file just above appears to match the one at https://svn.dd-wrt.com/browser/src/router/dnscrypt/dnscrypt-resolvers.csv, with each line specifying a resolver. This format appears to have been superceded in the dnscrypt community with a new master dnscrypt server list, with resolver parameters encoded into a new "stamp" format, at https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md which is pointed to by https://github.com/DNSCrypt/dnscrypt-resolvers/blob/master/v2/public-resolvers.md. The postings at https://dnscrypt.info are noteworthy, especially the checklists of features of DNSCrypt, DoH, DoTLS, etc. along with https://dnscrypt.info/stamps, a tool that you can use to decode stamps to get the three key parameters used in our Quad9 call to dnscrypt-proxy following -r, -N, and -k. You can add the colons to the public key by hand or run it through sed -e 's/..../&:/g' -e 's/:$//' to do it if you are like me and are linux based and either don't trust your fingers near a keyboard or want to do it for lots of stamps. The master dnscrypt server list above seems to contain many DNS resolvers not in our list, so we may have other options to experiment with as well.

Quad9 in particular announced their new DNSCrypt support at https://www.quad9.net/privacy-dnscrypt-testing/. There they link to file quad9-resolvers.md, which contains the DNS-resolver stamp for dnscrypt-ip4-filter-pri, the option I configured above. That stamp is also in the master dnscrypt server list above. I verified that they are identical as of a few days ago.

Edit Aug 2019: At https://quad9.net/dnscryptlive/ Quad9 says their public key can be obtained with command dig @9.9.9.9 2.dnscrypt-cert.quad9.net txt, which I just tested in linux and verified that the public key is as above in the dnscrypt-proxy call.

_________________
Six Linksys WRT1900ACSv2 (38159, r39144, 40009, 40784):
VLANs, multiple VAPs, NAS, QoS, client-mode travel router, OpenVPN client/PBR (old=NordVPN, new=AirVPN), two DNSCrypt servers (incl Quad9) routed through vpn.


Last edited by SurprisedItWorks on Mon Dec 09, 2019 18:34; edited 2 times in total
Sponsor
MLandi
DD-WRT User


Joined: 04 Dec 2007
Posts: 170

PostPosted: Sun Jan 06, 2019 19:50    Post subject: Reply with quote
Flashed from the GUI. No issues at all and everything running properly.
_________________
Netgear R9000 X10
DD-WRT v3.0-r41686 std (12/10/19)
AP, DNSMasq, Local DNS
CloudFlare DNS
QoS using HFSC w/CAKE
Static Leases & DHCP
2.4GHz: 3 + 7 (2422 MHz HT40)
5GHz: 161 + 155 (5805 MHz VHT80)
Xfinity 1Gbps/35Mbps
DaveI
DD-WRT User


Joined: 06 Jul 2009
Posts: 304

PostPosted: Sun Jan 06, 2019 20:23    Post subject: Reply with quote
SurprisedItWorks,

Thank you very much for this. Excellent work.

DaveI

_________________
WRT1900ACSv2
Monza
DD-WRT User


Joined: 01 Jul 2018
Posts: 121

PostPosted: Mon Jan 07, 2019 14:32    Post subject: Reply with quote
Updated WRT1200AC v1 from r37837 to r38159 with no reset, no issues using Firefox 64.0. Up-time 2+ hours. Usual OpenVPN client yellows in syslog but one of the cleanest syslogs I've had in a while. OpenVPN client and DNSMasq working as expected. Browser seems to have a faster response time site to site??

Kernel Version Linux 4.9.148 #691 SMP Wed Jan 2 01:54:17 CET 2019 armv7l

Previous two releases had good wired connections but would not allow connection to any of my wireless devices on 2.4 or 5 GHz due to "Authentication Error". This release (r38159) connects immediately.

**** 1/9/19 Reverted to r37837 after several OpenVPN client disconnects over a 48 hour period. Worked well for me other than unstable OpenVPN client.
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Marvell MVEBU based Hardware (WRT1900AC etc.) All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum