r38159 already? 2019's first!

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

Joined: 04 Aug 2018
Posts: 1420
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.

Updated 18 Dec 2020 to clarify, to update URLs, to deal with newer dd-wrt builds, and to suggest a tcpdump test.

So, how to use Quad9 (https://quad9.net) 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, 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. Enable other options as you choose, as those choices are independent from what we are doing here.
  • Aside: Quad9 does support DNSSEC, but DNSSEC is only useful if the website you are visiting is equipped to support it also. Check that out for sites important to you here: https://dnssec-analyzer.verisignlabs.com/. Also note that dnsmasq will only use DNSSEC if every configured DNS provider supports it. If you add Adguard DNS as a second provider like I do below, you can no longer use DNSSEC, as Adguard does not support it.
Then in Additional DNSMasq Options below those buttons, enter this.
Here no-resolv (no "e") prevents DNSMasq from falling back to resolvers provided by your ISP and (for builds from late 2019 or later) through your VPN provider through your OpenVPN client. You can omit no-resolv and enable Query DNS in Strict Order if you want to fall back to accessing those resolvers on an unencrypted basis if Quad9 is taking too long to respond. The important line is the server= line, which tells DNSMasq to use loopback IP, port 30, as its DNS resolver. Note that where other software generally uses 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. If you already have something in the Startup Commands window, hit its Edit button to move it to the Commands window at the top. Otherwise proceed directly to the Commands window and add this:
( Started=/tmp/root/StartedDNSCrypt; [[ -f $Started ]] && exit || touch $Started
  dnscrypt-proxy -d -S -a -r -N 2.dnscrypt-cert.quad9.net -k \
The first and last lines (together) are optional and 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. That code may be totally unnecessary, but including it is certainly harmless.

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 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 one or two (or more?) 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 subnet X's gateway IP 192.168.X.1 in order to tell subnet X's clients to use dnsmasq, and hence Quad9, for DNS queries (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) or the more likely case that it's having a slow moment, enable Query DNS in Strict Order, add a server= just before (edit: or after, as of 48141) server= in the Additional DNSMasq Options above, and in Startup Commands add, say to use AdGuard DNS (malware filtering plus ad filtering as discussed at https://adguard.com/en/adguard-dns/overview.html),
 dnscrypt-proxy -d -S -a \
  -R adguard-dns-ns1 -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 (edit: no longer true as of 48141). Where I put adguard-dns-ns1 here, you can use adguard-dns-ns2 instead. In builds from mid-2019 or earlier, you'll need just adguard-dns. The general rule is you can use anything from the first of the comma-separated columns in dd-wrt's dnscrypt-server database file /etc/dnscrypt/dnscrypt-resolvers.csv. These values correspond in a fairly obvious way to the items in the Encrypt DNS (which we are not using) drop-down menu, and in the CLI the command awk -F, '{print $1}' dnscrypt-resolvers.csv will list them. Choose any one you like. Note that AdGuard has "family" options available there. Of course you can use this abbreviated form of the dnscrypt-proxy call in both places if the DNSCrypt providers you want are in the database file.

A decent test to make sure things are working, in this Quad9 + Adguard case, is to run tcpdump -i eth0 | grep -Ei 'quad9|adguard' in the CLI. Here eth0 is the WAN interface for the Linksys/Marvell routers. For other routers do ip route | awk '/^default/{print $NF}' to identify your WAN interface and use that instead. This tcpdump command will dump a line to the terminal for each packet going to or from quad9 or adguard sites. If needed, visit dnsleaktest.com in a browser and run the Standard Test to force some DNS action. When done with all this, control-C to exit the tcpdump.

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 has been superceded in the dnscrypt community with a new master dnscrypt server list, with resolver parameters encoded into a "stamp" format, at 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, DoT, etc. in the FAQ tab along with a tool in the DNS STAMPS tab 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;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 dd-wrt list, so we may have other options to experiment with as well.

Quad9 in particular announced their DNSCrypt support at blog post https://www.quad9.net/dnscryptlive/. There they link at the end 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 were identical as of a few days before this (original, unedited) post. That Quad9 blog post also says their public key can be obtained with command dig @ 2.dnscrypt-cert.quad9.net txt, which I tested in linux to verify that the public key is as above in the dnscrypt-proxy call.

Netgear XR500 and 4x Linksys WRT1900ACSv2 on 52955: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.

Last edited by SurprisedItWorks on Fri Jan 28, 2022 17:12; edited 5 times in total

Joined: 04 Dec 2007
Posts: 947

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
DD-WRT v3.0-r53469 std (09/08/23)
Gateway, AP, DNSMasq, Clock 2000MHz
VAP on wlan1 for internet devices
IPv4 & IPv6 (Prefix Delegation)
Static Leases & DHCP
CloudFlare, no QoS, SmartDNS
2.4GHz: Vanilla Firmware, Airtime Fairness Enabled, NG-Mixed, ACK Timing 3150, WPA2 w/AES
5GHz: Vanilla Firmware, Airtime Fairness Enabled, AC/N Mixed, ACK Timing 3150, WPA2 w/AES
Netgear AX1800 WiFi Mesh Extender
Xfinity 1.2Gbps/35Mbps

Joined: 06 Jul 2009
Posts: 333

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

Thank you very much for this. Excellent work.



Joined: 01 Jul 2018
Posts: 402

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 Index -> Marvell MVEBU based Hardware (WRT1900AC etc.) All times are GMT


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