Skip to content

Installation on OpenWrt

Jump to bottom Edit New page
hugepants edited this page Jul 21, 2020 · 26 revisions

Which method to use?

The basic opkg package installation is for those looking for a simple no-frills installation, where updates are at the discretion of the package maintainer. Success is dependent upon the updated state of the package, it may not work if it goes stale. This is only available for OpenWrt 19.07+

The advanced manual installation offers more flexibility, and is the preferred method for the more competent users.

Whichever you choose, the additional tweaks are highly recommended.

Package installation (Basic)

Using the LuCI web interface

System > Software > Update lists...

Type dnscrypt-proxy2 in the Filter box then Install the desired package

Add 127.0.0.53 to Network > DHCP and DNS > General Settings > DNS forwardings

Save & Apply

Restart dnsmasq in System > Startup

Using the command line

opkg update
opkg install dnscrypt-proxy2
uci add_list dhcp.@dnsmasq[0].server='127.0.0.53'
uci commit dhcp
/etc/init.d/dnsmasq restart

Edit configuration

Use ssh or scp to edit the configuration file at /etc/dnscrypt-proxy2/dnscrypt-proxy.toml e.g:

vi /etc/dnscrypt-proxy2/dnscrypt-proxy.toml
/etc/init.d/dnscrypt-proxy restart

Backups

In a package installation, the configuration files are located in /etc/dnscrypt-proxy2/. To ensure all files here are backed up, in LuCI select System > Backup / Flash Firmware, click the Configuration tab and add the following line:

/etc/dnscrypt-proxy2/

Then click Save. Alternatively, you can add the line to /etc/sysupgrade.conf directly.

Manual installation (Advanced)

Download

Download the latest binary here. Get the right binary for your architecture. If you get a strange parse error later when trying to run the executable file, chances are that you didn't pick the right file for the CPU of your router. Here are some common examples:

Netgear R7800 - linux_arm
Ubiquiti EdgeRouter X - linux_mipsle

Optional: compress the executable

The dnscrypt-proxy file is quite large, but can be compressed for a massive reduction of its size, from ~12 MB down to ~2 MB.

In order to do so, use UPX on any platform (Windows, Linux, macOS...) with the following command:

upx --lzma dnscrypt-proxy

Tweak the example file

Rename example-dnscrypt-proxy.toml to dnscrypt-proxy.toml, and change at least the following line:

listen_addresses = ['127.0.0.1:53', '[::1]:53']

to (notice the IP address change):

listen_addresses = ['127.0.0.53:53']

Install the files on the router

Use scp to copy:

  • dnscrypt-proxy to /usr/sbin/
  • The modified dnscrypt-proxy.toml file to /etc/config/
  • This init.d file by @etam saved as /etc/init.d/dnscrypt-proxy

Then use ssh to log on the router and type:

chmod +x /usr/sbin/dnscrypt-proxy
chmod +x /etc/init.d/dnscrypt-proxy

Install the ca-bundle package on the router

The ca-bundle package is not installed by default in OpenWrt, which will cause issues if not installed.

opkg update
opkg install ca-bundle

Check that the proxy is properly installed

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

And watch for possible errors. Looks good? Start it for real:

/etc/init.d/dnscrypt-proxy enable
/etc/init.d/dnscrypt-proxy start

Configure dnsmasq

Edit /etc/config/dhcp to direct dns queries to dnscrypt-proxy

config dnsmasq
    # Upstream dnscrypt-proxy resolver to use for queries:
    list server '127.0.0.53'

Restart dnsmasq to switch to the new configuration and check for any errors reported:

/etc/init.d/dnsmasq restart
logread -l 100 | grep dnsmasq

It should report this: daemon.info dnsmasq[PID]: using nameserver 127.0.0.53#53

Make sure that the files you added are backed up

Using LuCI

In the System > Backup / Flash Firmware page, click the Configuration tab and add the list of files you uploaded and the automatically generated rc.d symlink to restore its enabled status after a sysupgrade:

/etc/init.d/dnscrypt-proxy
/usr/sbin/dnscrypt-proxy
/etc/rc.d/S18dnscrypt-proxy

Configuration files in /etc/config are automatically saved already.

Using the command line

Edit /etc/sysupgrade.conf to add files to be included in backups.

Recommended tweaks

Prevent DNS leaks outside of dnscrypt-proxy and disable dnsmasq cache

Warning: Before attempting the following, ensure that you have dnscrypt-proxy running and resolving DNS queries correctly because the following settings will disable the ISP's DNS.

Edit /etc/config/dhcp:

config dnsmasq
    # Ignore ISP's DNS by not reading upstream servers from /etc/resolv.conf
    option noresolv '1'
    # Ensures that /etc/resolv.conf directs local system processes to use dnsmasq and hence dnscrypt-proxy
    option localuse '1'
    # Disable because dnscrypt-proxy's block_undelegated already blocks RFC 1918 private addresses and RFC 6761 top level domains
    option boguspriv '0'
    # Disable dnsmasq cache because we don't want to cache twice and the dnscrypt-proxy cache is superior
    option cachesize '0'

Restart dnsmasq to switch to the new configuration and check for any errors reported:

/etc/init.d/dnsmasq restart
logread -l 100 | grep dnsmasq

Note: If you're using an OpenWrt version built before 23 February 2019, you need to update dnsmasq, since its option localuse was added on 23 Feb 2019:

opkg update; opkg upgrade dnsmasq

Optional: Completely disable ISP's DNS servers

For the perfectionists, add this option to /etc/config/network to prevent the ISP's DNS servers from being used anywhere:

config interface 'wan'    # or 'wan6'
    option peerdns '0'

Prevent DNS queries to other local zones

In order to prevent leakage of queries from these local zones (such as 168.192.in-addr.arpa) to upstream resolvers, ensure that you're running version 2.0.36 or later with this line present (it is now enabled by default in dnscrypt-proxy.toml):

block_undelegated = true

Force LAN clients to send DNS queries to dnscrypt-proxy

By default most clients will use the DNS server assigned by DHCP which is the device running dnscrypt-proxy. However there are many ways a client can bypass this with an alternative DNS server. The following firewall rules outlines some common workarounds but it is not possible to thwart every approach, like local DoH on port 443 or servers running on non-standard ports.

Add the following rules into /etc/config/firewall:

# Redirect unencrypted DNS requests to dnscrypt-proxy
# This will thwart manual DNS client settings and hardcoded DNS servers like in Google devices
config redirect
    option name 'Divert-DNS, port 53'
    option src 'lan'
    option proto 'tcp udp'
    option src_dport '53'
    option dest_port '53'
    option target 'DNAT'

# Block DNS-over-TLS over port 853
# Assuming you're not actually running a DoT stub resolver
config rule
    option name 'Reject-DoT'
    option src 'lan'
    option dest 'wan'
    list proto 'tcp udp'
    option dest_port '853'
    option target 'REJECT'

# Optional: Redirect queries to DNS servers running on non-standard ports. Can repeat for 9953, 1512, 54. Check https://github.com/parrotgeek1/ProxyDNS for examples.
# Warning: can break stuff, don't use this one if you run an mDNS server
config redirect
    option name 'Divert-DNS, port 5353'
    option src 'lan'
    option proto 'tcp udp'
    option src_dport '5353'
    option dest_port '53'
    option target 'DNAT'

And reload Firewall: /etc/init.d/firewall reload

Optional: Use dnscrypt-proxy for DNS rebind protection

dnsmasq can do DNS rebind protection, but it can be useful to perform this in dnscrypt-proxy instead. For example, if you use a filtered DNS service like Cloudflare Security, responses from blocked domains are 0.0.0.0 which causes dnsmasq to fill the system log with possible DNS-rebind attack detected messages. Using dnscrypt-proxy keeps the system log clean and can still optionally log to a separate file (e.g. ip-blocked.log). Steps as follows:

  1. Enable DNS rebind protection in dnscrypt-proxy then restart dnscrypt-proxy
  2. Disable DNS rebind protection in dnsmasq by setting option rebind_protection '0' in /etc/config/dhcp then restart dnsmasq

Logging DNS queries with client IPs

dnscrypt-proxy can log queries, but in this OpenWrt configuration it cannot log the requesting client IP address because dnsmasq is forwarding the request to dnscrypt-proxy. It can be helpful to know the requesting client IP in order to identify which device is making a particular DNS query. This can be achieved by enabling query logging in dnsmasq via /etc/config/dhcp:

config dnsmasq
    # equivalent to --log-queries=extra in dnsmasq
    option logqueries '1'
    # where to write log file to
    option logfacility '/tmp/dnsmasq_queries.log'
/etc/init.d/dnsmasq restart

Note: These logs accumulate quickly so it is recommended to write to an external share or storage device as embedded devices have limited flash write cycles and storage space.

Verifying the configuration

Check that you are not using your ISP resolver any more:

openwrt > dnscrypt-proxy -resolve google.com

Resolver IP should not belong to your ISP. You can verify whose network an IP address is on IPtoASN.

Check that processes on the router use dnsmasq:

openwrt > cat /etc/resolv.conf
search lan
nameserver 127.0.0.1

The above value for nameserver must be 127.0.0.1, which is the dnsmasq server.

Note: These entries might only show when dhcp option localuse is enabled as instructed above.

3rd party DNS tests

The DNS leak test and DNS randomness test show the actual IP of your DNS server(s).

You should make sure that any reported name or IP is NOT associated with the ISP you are using.

If you see the ISP presence in the test results, something is wrong with the configuration, since it's bypassing your dnscrypt-proxy provider.

DNSSEC resolver test determines whether your DNS resolver validates DNSSEC signatures.

You can also use this site to test both your IPV4 & IPV6 & DNSSEC settings: https://en.internet.nl/connection/

Are these instructions not clear? Wrong? Insufficient? This documentation page is a Wiki, so you can contribute by improving it!

Clone this wiki locally