DNSCrypt Proxy Server

DNSCrypt is deprecated in favor of DNS-TLS
Go to: DNS-TLS Proxy Server

AstLinux now supports the DNSCrypt (dnscrypt-proxy) package, a tool for securing communications between a client and a DNS resolver.

The dnscrypt-proxy local service functions as a DNS forwarder, used in conjunction with dnsmasq, encrypting and authenticating requests using the DNSCrypt protocol and passing them to an upstream DNS server.

Note: AstLinux 1.1.6 or later is required

Note: AstLinux 1.2.4.1 or later is required for Ephemeral Keys and Secondary Server support

Note: AstLinux 1.3.3 or later is required for Import sdns: Stamp support

Configuring DNSCrypt is as simple as it gets.

Select the Network Tab in the web interface.

Network Services:

By default DNSCrypt is disabled, to enable, select “enabled” from the menu and click Save Settings and then Restart DNSCrypt.

The use of “Ephemeral Keys” is disabled by default. “Ephemeral” or “short-lived” Keys implies that a new key is generated for each query to eliminate a method of tracking you, though keep in mind the server knows your IP address. The only downside of enabling “Ephemeral Keys” is the extra CPU resources required, on an Intel Atom, 1.8 GHz class CPU with many consecutive DNS lookups, 2.9% → 3.2% (peak) of the CPU is used, versus 0.1% → 0.2% (peak) with “Ephemeral Keys” disabled.

As the dialog's “Note” states, the default configuration is to use OpenDNS as the DNSCrypt provider.

Optionally, a secondary server proxy may be specified. No secondary server is enabled by default, the “Server Address” field must be specified to enable it. Any other empty fields use the OpenDNS defaults.

For example, if you want to add an additional OpenDNS server, you could specify under Secondary Server:

Server Address: 208.67.222.222:443

using the OpenDNS defaults for the remaining fields.

Alternatively, there is a growing number of DNSCrypt providers around the world, some of which may be closer to you.

Quad9 current list, using sdns: stamps
Quad9 DNS resolvers supporting DNSCrypt

Public, current list, using sdns: stamps
Public DNS resolvers supporting DNSCrypt

Using AstLinux 1.3.3 or later your can directly import an sdns: stamp to automatically fill in the three fields.

Optionally define the three Server/Provider fields using the table columns titled Resolver address, Provider name and Provider public key (⇒ scroll to the right edge).

For example the OpenDNS values automatically used are:

Server Address: 208.67.220.220:443
Provider Name: 2.dnscrypt-cert.opendns.com
Provider Key: B735:1140:206F:225D:3E2B:D822:D7FD:691E:A1C3:3CC8:D666:8D0C:BE04:BFAB:CA43:FB79

Reminder, no need to enter the above values, since that is the default used automatically.

Tip -> Some of you (you know who you are) may even want to be your own DNSCrypt provider. DNSCrypt-Wrapper is a server-side DNSCrypt proxy that works with any name resolver.

A quick glance of the Status tab's DNS entry will show if DNSCrypt is enabled.

Select the Status Tab in the web interface.

The DNS entry “DNSCrypt Proxy Server Enabled” indicates the status. If not, the standard upstream nameserver's will be shown, indicating DNSCrypt is disabled.

Tip -> If you are using OpenDNS as your DNSCrypt provider, from any UNIX command line that supports host or dig, issue the following command and you will see the TXT string “dnscrypt enabled (NNNNNNN)” if DNSCrypt is enabled upstream.

host -t txt debug.opendns.com

or

dig debug.opendns.com txt +short

By default, no changes to the Firewall settings are necessary for DNSCrypt to function.

Optionally, if AstLinux is acting as the router for your network, you may want to require all LAN devices get their DNS from the internal LAN interface(s) of AstLinux. This may be desired regardless if DNSCrypt is enabled or not. For example, custom web content filtering may be applied by using features of your DNS provider, to be effective you want to route all DNS via a specific server and block any other DNS requests.

Possibly even more important, malware has been known to change a local PC's DNS entries to point to a poisoned DNS server. One more reason to restrict DNS access to only trusted providers.

Therefore, if AstLinux is acting as the router for your network, the following firewall rule will prevent LAN devices from directly using public DNS servers:

Network tab → Firewall Configuration:

Click on Firewall Configuration

The above rule blocks forwarded DNS packets from the LAN to the External interface. The local LAN interface(s) will still be reachable for DNS lookups. Also note this rule does not effect Local→EXT DNS packets.

Note -> If you are using the DMZ interface, you may want to also add a Deny DMZ→EXT rule.

To determine if the above rule is blocking packets, look at your syslog for lines containing:

AIF:Host LAN->INET denied: ... SRC=x.x.x.x DST=y.y.y.y PROTO=UDP DPT=53

The SRC= entry will identify which LAN device is misconfigured.

In order to validate the DNSCrypt provider's certificate, the DNSCrypt client's system must have it's clock set to a reasonable time. Fortunately most AstLinux boards have a real time clock with battery backup so this is not a common problem, but if your board's CMOS battery is dead or such, and the system time is not reasonable at startup, this can be a problem when enabling DNSCrypt. Regardless, one of the first things AstLinux does at startup is to accurately set the system clock using the NTP protocol. If the specified NTP server is a numeric IP address or a locally resolved DNS name (via local /etc/hosts), no problem. But, if the specified NTP server was, say “us.pool.ntp.org”, we have the classic chicken-egg problem.

The solution is to configure dnsmasq to resolve a specific domain name with a specific server, where DNSCrypt is not used. For example to resolve all “*.pool.ntp.org” domain names with the OpenDNS server “208.67.222.222”, we can add the following line into the /mnt/kd/dnsmasq.static file:

server=/pool.ntp.org/208.67.222.222

Note -> Do not add this line unless required.

Fixed in AstLinux 1.1.7 and later: Another possible issue is the time it takes for dnscrypt-proxy to startup initializing the libsodium library. Using a 1.8 GHz dual core Atom board, this only takes 3 seconds, so no problem. Though a PC-Engines Alix board takes 18 seconds to start, this delay will cause DNS lookups using DNSCrypt to not succeed for that startup period of time. If this causes a problem, then the same dnsmasq solution as above may be used for any specific domain names required at startup. Fortunately, delayed DNS availability will be tolerated by most services.

Finally, DNSCrypt is optional.