-
Notifications
You must be signed in to change notification settings - Fork 1k
Installation on OpenWrt
- Package installation
- Recommended tweaks
- Logging DNS queries with client IPs
- Verifying the configuration
The following instructions are for installing from the official OpenWrt repository but note that updates are at the discretion of the package maintainer so the version may not always be up to date.
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
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
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
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.
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 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
Accurate date/time is required for certificate validation, this is especially important for devices without a battery-backed RTC (Real Time Clock). An incorrect date/time may cause the server handshake to fail. This produces a "chicken and egg" situation where DNS queries cannot be resolved until an NTP server is accessed, but it can't because the NTP server hostname cannot be resolved through DNS. One simple solution is to add some IP addresses of well-established NTP servers so that DNS is not required at all.
In /etc/config/system
> config timeserver 'ntp'
, add these entries:
list server '216.239.35.0' # Google
list server '216.239.35.4' # Google
list server '216.239.35.8' # Google
list server '216.239.35.12' # Google
list server '162.159.200.123' # Cloudflare
list server '162.159.200.1' # Cloudflare
And restart the service /etc/init.d/sysntpd restart
Alternatively, if you only use DNSCrypt servers, consider the option cert_ignore_timestamp = true
in dnscrypt-proxy.toml
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'
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 addresses some common methods.
Add the following rules into /etc/config/firewall
:
# Redirect unencrypted DNS queries 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 dest 'lan'
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, port 853'
option src 'lan'
option dest 'wan'
option dest_port '853'
option proto 'tcp'
option target 'REJECT'
# Optional: Redirect queries for 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 dest 'lan'
option src_dport '5353'
option dest_port '53'
option target 'DNAT'
And reload Firewall: /etc/init.d/firewall reload
For advanced users, you can block access to IP addresses of known DoH servers with the package banIP. It has a built-in DoH blocklist or you can use the larger list by jpgpi250. Note that you must specify the DoH server(s) that you actually use in its allowlist otherwise dnscrypt-proxy will not be able to use DoH itself.
dnsmasq
can do DNS rebinding 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 or AdGuard, 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:
-
Enable DNS rebinding protection in
dnscrypt-proxy
then restartdnscrypt-proxy
- Disable DNS rebinding protection in
dnsmasq
by settingoption rebind_protection '0'
in/etc/config/dhcp
then restartdnsmasq
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.
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.
This will also detect if the server supports DNSSEC, print its real IP address, and check if it returns fake responses for nonexistent domains.
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.
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.
The following site can check if the resolver can connect to upstream servers using IPv6 IPv6 and does DNSSEC validation: https://en.internet.nl/connection/
Cloudflare also has a web page to check that you're using their resolvers: https://www.cloudflare.com/ssl/encrypted-sni/
In somecases if you want to run dnscrypt-proxy as a non-root user you'll get the error "[FATAL] listen udp 0.0.0.0:53: bind: permission denied"
to solve this problem you can run the following command and allow dnscrypt to have access to a low level port :
sudo setcap cap_net_bind_service=+ep $(which dnscrypt-proxy)
- Home
- Installation
- Configuration
- Checking that your DNS traffic is encrypted
- Automatic Updates
- Server sources
- Combining blocklists
- Public Blocklist and other configuration files
- Building from source
- Run your own DNSCrypt server in under 10 minutes
- DNS stamps specifications
- Windows Tips
- dnscrypt-proxy in the media
- Planned Features