How to properly configure dnsmasq for DNSCrypt v2 to prevent leaks to ISP

wind · July 3, 2019, 10:49am

Apperently, the dnsmasq had been updated after 18.06.2 release and that's where the handling of localuse option was fixed. So, please definitely have it updated:

opkg update; opkg upgrade dnsmasq

or just install all updates and restart the router:

opkg update; opkg list-upgradable | cut -d' ' -f1 | xargs --no-run-if-empty opkg upgrade

But that's not the only problem in your environment. When your DNSCrypt runs configuration checks, it exits with fatal error. You must fix its configuration and make sure that it starts up fine and listens on 127.0.0.53:53 TCP/UDP.

dnscrypt-proxy -config /etc/config/dnscrypt-proxy.toml -check

The remaining puzzling thing is what exactly your dnsmasq using for the server, since it should not be able to connect to the absent DNSCrypt, but you also said that the log shows many messages that it uses it. Is "127.0.0.53#53" really what your dnsmasq is using?

> logread | grep 'dnsmasq.*using nameserver'
Mon Jun 24 08:02:45 2019 daemon.info dnsmasq[8256]: using nameserver 127.0.0.53#53

oscar · July 4, 2019, 7:50am

First of all, thank you very much for helping me on this matter.

So I did an update to dnsmasq from v.2.80-1.2 to v2.80-1.4. Rebootet the entire system and ran the checks:

name resolution does not work, neither on router nor client PC

dnscrypt-proxy -resolve google.com
Resolving [google.com]
Domain exists: probably not, or blocked by the proxy
Canonical name: -
IP addresses: -
TXT records: -

dnscrypt configuration check with no errors.

dnscrypt-proxy -config /etc/config/dnscrypt-proxy.toml -check
[2019-07-04 07:03:01] [NOTICE] Network connectivity detected
[2019-07-04 07:03:01] [NOTICE] Source [public-resolvers.md] loaded
[2019-07-04 07:03:01] [NOTICE] Configuration successfully checked

localuse is recognised now

grep -c localuse /etc/init.d/dnsmasq
8

dnsmasq is using the proper server:

logread | grep 'dnsmasq.using nameserver' (asterix before using disappears in blockquote mode)
Thu Jul 4 09:08:08 2019 daemon.info dnsmasq[20021]: using nameserver 127.0.0.53#53

DNScrypt is NOT listening to anything

logread | grep dnscrypt | grep listening
niente, nada, rien, nothing, nichts, nic, ingenting

the /tmp/resolv.conf.auto file points to ISP name servers, while /tmp/resolv.conf and /etc/resolv.conf have the (identical) desired content

cat /etc/resolv.conf
search lan
nameserver 127.0.0.1

My interpretation is that dnscrypt-proxy is not running, or not using the modified toml file in /etc/config?

Cheers

oscar · July 4, 2019, 11:54am

I am wondering whether this is a matter of the cpu architecture. I spent several hours to find out whether my router is MIPS, ARM, something different?

cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 108.75
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

SoC is a Qualcomm Atheros IPQ4018, the device is described here.

From the releases page I selected '-linux-arm-' and installed it. I tested also '-freebsd-armv7-' and '-linux-mips-2.0-', which did not work for different reasons.

wind · July 5, 2019, 10:41am

@oscar, you picked the right CPU architecture and that's why "dnsmasq -check" runs fine and that's the important point to now check your configuration:

Make sure that /etc/init.d/dnscrypt-proxy file looks like this: https://raw.githubusercontent.com/etam/DNS-over-HTTPS-for-OpenWRT/master/dnscrypt-proxy, so it properly passes the configuration file "/etc/config/dnscrypt-proxy.toml" to the daemon.
Make sure that the configuration file "/etc/config/dnscrypt-proxy.toml" has the syslog option enabled (since it's off by default), so you can see the output of the daemon in the syslog and figure out its health:
```
use_syslog = true
```
Restart the daemon and make sure that the process was started with proper config file:
```
/etc/init.d/dnscrypt-proxy restart; ps w | grep dnscrypt
```
the output of "ps" should look like this: "/usr/sbin/dnscrypt-proxy -config /etc/config/dnscrypt-proxy.toml -child"

oscar · July 5, 2019, 3:11pm

Hello @wind
'1.' & '2.' are as described. syslog = true is already set in the example file
'3.' does not return the "-child" whatever. The entire output is:

/etc/init.d/dnscrypt-proxy restart; ps w | grep dnscrypt
11899 root      783m R    /usr/sbin/dnscrypt-proxy -config /etc/config/dnscrypt-proxy.toml
11900 root      1164 R    /bin/sh /etc/rc.common /etc/init.d/dnscrypt-proxy running
11905 root      1064 S    grep dnscrypt

The trigger for no-DNS-servers-at-all/ISP-DNS-servers is the noresolv option in /etc/config/dhcp. '0' will block all DNS resolutions.

oscar · July 5, 2019, 3:23pm

You may have seen my alternative approach, which also failed. I remain interested in getting dnscript-proxy running.

wind · July 5, 2019, 3:31pm

Hmmm ... I guess the "-child" option is used by the process to switch credentials from root to the user configured in user_name option. You're probably not using it.

So, we need to make DNSCrypt to produce some output information about its progress/status. So, do this for now:

Stop the daemon: /etc/init.d/dnscrypt-proxy stop
Comment out syslog option from the toml-file
Run DNSCrypt on the command line to see its output: /usr/sbin/dnscrypt-proxy -config /etc/config/dnscrypt-proxy.toml -loglevel 3 (change the logging level higher if you need to. "2" is the default)

oscar · July 5, 2019, 9:10pm

UPDATE: initially I got the error message, but today I reinstalled the whole system, recoverd the configurations from backup, and then did the check again, this time it seems to almost work!

/usr/sbin/dnscrypt-proxy -config /etc/config/dnscrypt-proxy.toml -loglevel 2
[2019-07-06 13:55:35] [NOTICE] Network connectivity detected
[2019-07-06 13:55:35] [NOTICE] Source [public-resolvers.md] loaded
[2019-07-06 13:55:35] [NOTICE] dnscrypt-proxy 2.0.25
[2019-07-06 13:55:35] [NOTICE] Loading the set of blocking rules from [blacklist.txt]
[2019-07-06 13:55:35] [NOTICE] Now listening to 127.0.0.53:53 [UDP]
[2019-07-06 13:55:35] [NOTICE] Now listening to 127.0.0.53:53 [TCP]
[2019-07-06 13:55:36] [NOTICE] [cloudflare] OK (DoH) - rtt: 15ms
......followed by dozens of servers.....
[2019-07-06 13:56:10] [NOTICE] Sorted latencies:
yeah.....
[2019-07-06 13:56:10] [NOTICE] dnscrypt-proxy is ready - live servers: 67
^C[2019-07-06 14:01:29] [NOTICE] Stopped.

And then finally, started dnscrypt-proxy, tested it as per Wiki and tadam, everything but DNSsec resolver test fine (No, your DNS resolver does NOT validate DNSSEC signatures)

Whatever I made wrong, I kept all modified files from the beginning, a typo can therefore be excluded.

Initial reply, obsolete...
/usr/sbin/dnscrypt-proxy -config /etc/config/dnscrypt-proxy.toml -loglevel 2
[2019-07-05 21:07:26] [NOTICE] Network connectivity detected
[2019-07-05 21:07:26] [NOTICE] Source [public-resolvers.md] loaded
[2019-07-05 21:07:26] [NOTICE] dnscrypt-proxy 2.0.25
[2019-07-05 21:07:26] [NOTICE] Loading the set of blocking rules from [blacklist.txt]
[2019-07-05 21:07:26] [FATAL] listen udp 127.0.0.1:53: bind: address already in use

No idea what the last line means, but it does not sound to good....

fantom-x · July 5, 2019, 10:00pm

That means that something else took the address and port. Run this to find out:

netstat -nap | grep LISTEN

That would probably be dnsmasq. You connote have both dnscrypt-proxy and dnsmasq using the same address and port. Have your dnscrypt-proxy use

listen_addresses = ['127.0.0.55:5555']

And then configure dnsamasq forward to

list server '127.0.0.55#5555'

oscar · July 6, 2019, 2:12pm

Thank you @wind for your patience and advice.

@fantom-x I shall keep your netstat command in mind for future changes/improvement of my router configuration.

Cheers
Oscar

wind · July 6, 2019, 2:20pm

No worries! If you have any problems - this is what the forum is for.

oscar · July 6, 2019, 2:38pm

I had to edit my reply, the DNSsec validation test failed. Newbie question: is it essential?

wind · July 6, 2019, 3:21pm

That's totally up to you, if you want to only use DNS servers that support DNSSEC. Personally, I use the following filtering in DNSCrypt to narrow down the list of servers:

require_dnssec = true
require_nolog = true
require_nofilter = true

oscar · July 7, 2019, 8:47am

Now I also understand jedisct1 reply to your answer regarding filtering. Thank you again, nice tutorial session this was.

BTW, I am using 18.06.3, dnsmasq is already included in the version supporting 'localuse', no need for manual updating any longer.

Oscar

slim0287 · September 23, 2019, 12:03pm

In the guide for installing dnscrypt-proxy v2 on OpenWrt (https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Installation-on-OpenWRT) there is a "cryptic" paragraph at the end discussing what to do if one has issues on reboot (it starts with "In case having issues resolving dns after a reboot..."). Unfortunately it is not very clear. For example, I think it is telling us to modify /etc/config/dhcp to the following:

config dnsmasq
    ...
    # Ignore ISP's DNS:
    option noresolv '1'
    # Change /etc/resolv.conf to direct local router processes to use local dnsmasq:
    option localuse '1'
    list server '127.0.0.53'
    /pool.ntp.org/208.67.222.222

However I am not clear if this is correct. I would like to know, because somewhere along the line I found advice to put the following into the local startup script (/etc/rc.local) in order to deal with dns reboot issues:

# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

for i in {1..60}; do ping -c1 -W1 99.192.182.100 &> /dev/null && break; done

/etc/init.d/dnsmasq restart
/etc/init.d/dnscrypt-proxy restart

exit 0

I don't actually know if this script protects me from reboot issues because it's been long enough such that I can't find the original recommendation that led me to this script. So, I'd prefer to use the dnscrypt-proxy v2 guide advice instead, but as I wrote above it is hard to understand as written.

wind · September 24, 2019, 12:17am

@slim0287, there is no such paragraph or even mention of word "reboot" on the latest DNSCrypt v2 Installation on OpenWRT wiki page. There might've been a footnote long on the page time ago, but it is no longer there because it is not necessary to worry about.

I'm guessing that you're converting from DNSCrypt v1 (described on OpenWRT wiki ) and mixing them up. So, I can assure you that DNSCrypt v2 was a complete rewrite of the utility in Go language, which not only eliminated many pitfalls of the old implementation, but was also a huge step forward in terms of flexibility and performance. Definitely go and use it in your environment!

Regarding the old dns issue in v1 - the problem is described on the old wiki page:

/pool.ntp.org/208.67.222.222 adds an exception for pool.ntp.org, which will be resolved through the standard unencrypted DNS channel. DNSCrypt requires precise time, otherwise it will not resolve any domain, including pool.ntp.org. So if your device's time was incorrect, it could never update its time, and therefore DNSCrypt would never work. So we set this exception so that pool.ntp.org queries will always bypass DNSCrypt and resolve with the standard unencrypted OpenDNS method.

Hope this helps

slim0287 · September 24, 2019, 12:38am

I'll be darned, I must have been looking at a cached version of the page or something. When I looked at the wiki page last night, that note was there and I'm confident I wasn't hallucinating And I really don't believe I was looking at the v1 page. But it is not there now, no question.

I'm not converting from DNSCrypt v1, so no risk there.

Thanks for pointing this all out. I am going to remove my /etc/rc.local script as well.

hellion86 · November 15, 2019, 4:28am

Hello community!

Can some one help me? I don`t understand what archive i need mips or arm ( https://github.com/DNSCrypt/dnscrypt-proxy/releases) . My hardware archer c7 v2

wind · November 15, 2019, 8:56pm

There is no harm in trying to execute either of the files (mips or arm). The kernel is going to accept it or refuse it. Just test it with "dnscrypt-proxy --help".

If you really want to make sure that you pick the file with the proper architecture first, then load Linux utility "file" (through "opkg update && opkg install file") and see which architecture you need by comparing it with /bin/busybox. For example:

root > file /bin/busybox dnscrypt-proxy
/bin/busybox:   ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter ...
dnscrypt-proxy: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped

hellion86 · November 20, 2019, 3:09pm

Many thanks!
it works now