dnscrypt-proxy 2.1.20

Option A: AWS Marketplace console

• Open the SecureAnyCloud Hardened WireGuard VPN & VPN, Proxy and Remote Access AMIs listing on AWS Marketplace, choose View purchase options, and then choose Subscribe. One subscription covers every version in the listing.
• When the subscription is active, choose Launch your software.
• Choose One-click launch from AWS Marketplace (or Launch from EC2 Console for the full launch wizard). In Version, choose dnscrypt-proxy 2.1.20 on Ubuntu 24.04, and then choose your Region.
• Pick an instance type (m5.large is recommended, and the software charge is $0.04 per vCPU per hour) and your key pair.
• Configure the security group. The listing's default group allows SSH (22) only, so restrict SSH to your own IP address. You open DNS to your VPC in Step 6.
• Choose the VPC whose clients will use the resolver and a subnet with outbound HTTPS. Leave the metadata defaults, because the image already requires IMDSv2. Then choose Launch.

Option B: AWS CLI

Run these commands on your own workstation. They create a security group that allows SSH from your management address and DNS from the VPC, and then launch the instance. Replace the AMI ID with the one shown for your Region on the Marketplace launch page, and replace the VPC, subnet, key pair and CIDR ranges with your own:

SG=$(aws ec2 create-security-group --group-name dnscrypt-proxy \
  --description "dnscrypt-proxy encrypted DNS resolver" --vpc-id vpc-0123456789abcdef0 \
  --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 22 --cidr <your-mgmt-cidr>
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol udp --port 53 --cidr <your-vpc-cidr>
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 53 --cidr <your-vpc-cidr>
aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids "$SG" \
  --subnet-id subnet-0123456789abcdef0 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=dnscrypt-proxy}]'

You do not need --metadata-options, because the AMI already makes IMDSv2 required.

Connect as ubuntu with the key pair you chose:

ssh -i ~/.ssh/my-key-pair.pem ubuntu@<public-ip>

First boot finishes within a minute or two of launch. It writes the client allow-list from your VPC's CIDR blocks, generates the dashboard password, downloads and checks the signed resolver list, starts dnscrypt-proxy, and points the instance's own DNS at it.

The details are in /root/dnscrypt-proxy-credentials.txt, which only root can read. This command shows everything except the dashboard password:

sudo grep -v '^MONITORING_UI_PASSWORD=' /root/dnscrypt-proxy-credentials.txt

# dnscrypt-proxy 2.1.20 - generated on first boot by dnscrypt-proxy-firstboot.service.
# The monitoring dashboard ships DISABLED. Its basic-auth password below was generated on this instance and no
# other instance shares it. To use the dashboard, enable it in /etc/dnscrypt-proxy/dnscrypt-proxy.toml and reach
# it through an SSH tunnel (see the guide). Keep this file private. MONITORING_UI_URL=http://127.0.0.1:8080/ MONITORING_UI_USER=admin DNS_LISTEN=[::]:53 (UDP and TCP) DNS_PRIVATE_ADDRESS=172.31.92.201 ALLOWED_CLIENTS=172.31.0.0/16 (+ loopback; /etc/dnscrypt-proxy/allowed-clients.txt) INSTANCE_HOSTNAME=ip-172-31-92-201.ec2.internal CONFIG=/etc/dnscrypt-proxy/dnscrypt-proxy.toml SELF_TEST=sudo dnscrypt-proxy-selftest GUIDE=https://secureanycloud.com/stacks/dnscrypt-proxy-2-1-20/

DNS_PRIVATE_ADDRESS is the address your clients use. Your values differ from the example output.

Confirm that dnscrypt-proxy and the allow-list are active and that first boot has completed. dnscrypt-proxy owns port 53 over UDP and TCP on every interface (* is IPv4 and IPv6):

systemctl is-active dnscrypt-proxy.service sac-dnscrypt-acl.service dnscrypt-proxy -version sudo ss -Htulnp 'sport = :53' | awk '{print $1, $5}'

active active 2.1.20 udp *:53 tcp *:53

The shipped self-test checks the resolver end to end from the instance itself. It confirms the following:

• dnscrypt-proxy runs as its own user.
• The allow-list is loaded.
• A name resolves over UDP and TCP.
• Encrypted upstreams are in use.
• The instance resolves through its own resolver.
• Query logging is off.
• The instance metadata service is unreachable from inside dnscrypt-proxy, while the Amazon resolver answers there.

Run the self-test:

sudo dnscrypt-proxy-selftest

ok: dnscrypt-proxy is active (pid 2925, user dnscrypt-proxy) ok: port-53 allow-list loaded: 172.31.0.0/16 (+ loopback) ok: example.com resolves over UDP and TCP on 127.0.0.1:53 (172.66.147.243) ok: encrypted upstreams in use: 313 ] OK (DNSCrypt); 155 ] OK (DoH); ok: this instance resolves through its own encrypted resolver (/etc/resolv.conf -> 127.0.0.1) ok: query logging and NX logging are off ok: metadata: 169.254.169.254 is unreachable from inside dnscrypt-proxy; the Amazon resolver answers there SELFTEST_OK

Names resolve over UDP and TCP. A name whose DNSSEC signature is deliberately broken (dnssec-failed.org) is refused with SERVFAIL, because only DNSSEC-validating resolvers are used. Check the log to see which encrypted resolver answered fastest at start-up:

dig +short @127.0.0.1 example.com A dig +tcp +short @127.0.0.1 example.com A dig @127.0.0.1 dnssec-failed.org A | grep -o 'status: [A-Z]*'
sudo journalctl -u dnscrypt-proxy.service --no-pager | grep -a 'lowest initial latency' | tail -1 | sed 's/^.*\]: //'

172.66.147.243 104.20.23.154 172.66.147.243 104.20.23.154 status: SERVFAIL [2026-10-27 00:15:46] [NOTICE] Server with the lowest initial latency: quad9-dnscrypt-ip4-nofilter-pri (rtt: 0ms), live servers: 336

The allow-list already contains your VPC's CIDR blocks, and the security group decides whether DNS traffic reaches the instance at all. Open UDP and TCP 53 to your VPC (or to the subnets of your clients) in the instance's security group, and never to 0.0.0.0/0:

aws ec2 authorize-security-group-ingress --group-id <your-sg> --protocol udp --port 53 --cidr <your-vpc-cidr>
aws ec2 authorize-security-group-ingress --group-id <your-sg> --protocol tcp --port 53 --cidr <your-vpc-cidr>

Then, from any instance in the VPC, query the resolver's private address (DNS_PRIVATE_ADDRESS from Step 2):

dig +short @<instance-private-ip> example.com A

To make every instance in the VPC use the resolver, create a DHCP options set with domain-name-servers set to the resolver's private address, and associate it with the VPC. For resilience, use two resolvers in different Availability Zones. Alternatively, set the address in each client's resolver configuration. Keep the Amazon resolver for anything that needs it, because this image already sends AWS names there (Step 8).

A client outside the allow-list gets no answer at all, even if the security group lets its packets in. The instance drops and counts its queries. Show the current list and the drop counter:

sudo grep -v '^#' /etc/dnscrypt-proxy/allowed-clients.txt
sudo dnscrypt-proxy-acl show

172.31.0.0/16 table inet sac_dns { set allow4 { type ipv4_addr flags interval elements = { 127.0.0.0/8, 172.31.0.0/16 } } set allow6 { type ipv6_addr flags interval elements = { ::1 } } chain input { type filter hook input priority filter - 10; policy accept; iifname "lo" accept meta l4proto { tcp, udp } th dport 53 ip saddr @allow4 accept meta l4proto { tcp, udp } th dport 53 ip6 saddr @allow6 accept meta l4proto { tcp, udp } th dport 53 counter packets 2 bytes 160 drop } }

Clients outside the VPC range (a VPN pool, a peered VPC, an on-premises network over Direct Connect) need their range on the allow-list. Add one CIDR per line and apply it. The change is atomic and needs no restart:

echo '10.8.0.0/24' | sudo tee -a /etc/dnscrypt-proxy/allowed-clients.txt
sudo dnscrypt-proxy-acl apply

dnscrypt-proxy-acl refuses 0.0.0.0/0 and ::/0, which would turn the instance into an open resolver. Allow the same range in the security group as well.

EC2 host names (*.internal) and AWS service endpoints (amazonaws.com) are forwarded to the Amazon VPC resolver, so instance names, Systems Manager and VPC interface endpoints with private DNS resolve exactly as they do without dnscrypt-proxy. The rules are in /etc/dnscrypt-proxy/forwarding-rules.txt. The following command resolves the instance's own private name through dnscrypt-proxy:

sudo grep -v '^#' /etc/dnscrypt-proxy/forwarding-rules.txt
TOKEN=$(curl -s -X PUT -H 'X-aws-ec2-metadata-token-ttl-seconds: 60' http://169.254.169.254/latest/api/token)
LH=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/local-hostname)
echo "$LH"; dig +short @127.0.0.1 "$LH" A

internal 169.254.169.253 amazonaws.com 169.254.169.253 ip-172-31-92-201.ec2.internal 172.31.92.201

If your VPC uses Route 53 private hosted zones, add one line per zone. For example, corp.example.internal 169.254.169.253 is already covered by internal, while example.com 169.254.169.253 would send a whole private zone to the VPC resolver. Then restart dnscrypt-proxy:

echo 'example.com 169.254.169.253' | sudo tee -a /etc/dnscrypt-proxy/forwarding-rules.txt
sudo systemctl restart dnscrypt-proxy

After first boot, the instance resolves through its own encrypted resolver and keeps the VPC search domain:

grep -v '^#' /etc/resolv.conf

nameserver 127.0.0.1 options edns0 trust-ad search ec2.internal

To send the instance's own lookups to the VPC resolver again, run sudo ln -sfn /run/systemd/resolve/resolv.conf /etc/resolv.conf. dnscrypt-proxy keeps serving your clients either way.

dnscrypt-proxy has a built-in monitoring dashboard (query counts, cache hit rate, resolver latencies). It is disabled on this image. To use it, set enabled = true in the [monitoring_ui] section of /etc/dnscrypt-proxy/dnscrypt-proxy.toml, and restart dnscrypt-proxy.

The dashboard listens on 127.0.0.1:8080 only. Reach it through an SSH tunnel from your workstation, and open http://127.0.0.1:8080/:

sudo sed -i '/^\[monitoring_ui\]/,/^\[/ s/^enabled = false/enabled = true/' /etc/dnscrypt-proxy/dnscrypt-proxy.toml
sudo systemctl restart dnscrypt-proxy ssh -i ~/.ssh/my-key-pair.pem -L 8080:127.0.0.1:8080 ubuntu@<public-ip>

Sign in as admin with the password that was generated on your instance. Read it on the instance with:

sudo grep '^MONITORING_UI_PASSWORD=' /root/dnscrypt-proxy-credentials.txt | cut -d= -f2-

On this image the dashboard shows aggregate figures only and keeps no list of recent queries (privacy_level = 2, enable_query_log = false). Keep it on 127.0.0.1.

dnscrypt-proxy cannot reach the instance metadata service. The Amazon resolver (169.254.169.253) is deliberately not blocked:

systemctl show -p IPAddressDeny dnscrypt-proxy.service

IPAddressDeny=168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128

dnscrypt-proxy.service runs only when first boot's ready marker exists and only together with the allow-list unit. Every start runs a check as root first, which confirms that the allow-list is loaded, the configuration parses, the dashboard password is a real one, and no forwarding rule points at the metadata service. Only root or the service can read the files that hold per-instance data:

systemctl cat dnscrypt-proxy.service | grep -E '^(ConditionPathExists|Requires|ExecStartPre|ExecStart|User|AmbientCapabilities)='
sudo stat -c '%a %U:%G %n' /root/dnscrypt-proxy-credentials.txt /etc/dnscrypt-proxy/dnscrypt-proxy.toml /etc/dnscrypt-proxy/allowed-clients.txt

Requires=sac-dnscrypt-acl.service ConditionPathExists=/var/lib/sac/data/dnscrypt-proxy-ready User=dnscrypt-proxy ExecStartPre=+/usr/local/sbin/dnscrypt-proxy-preflight ExecStart=/usr/local/bin/dnscrypt-proxy -config /etc/dnscrypt-proxy/dnscrypt-proxy.toml AmbientCapabilities=CAP_NET_BIND_SERVICE 600 root:root /root/dnscrypt-proxy-credentials.txt 640 root:dnscrypt-proxy /etc/dnscrypt-proxy/dnscrypt-proxy.toml 644 root:root /etc/dnscrypt-proxy/allowed-clients.txt

• Keep SSH open only to your management addresses. Open UDP and TCP 53 only to the networks the resolver serves, never to 0.0.0.0/0.
• Run two resolvers in different Availability Zones if your VPC depends on them, and list both in the DHCP options set.
• Leave query logging off unless you need it. If you turn it on, treat the log as sensitive and rotate it.
• Leave the dashboard off, or on 127.0.0.1 behind an SSH tunnel.
• Leave unattended security upgrades on. dnscrypt-proxy is a single binary in /usr/local/bin/dnscrypt-proxy, and SecureAnyCloud ships updated versions as new versions of this listing.