More Private DNS and Ad Blocking: NextDNS CLI and WireGuard on Your Own Server

A custom WireGuard tunnel with the NextDNS CLI local client can filter ads and trackers on all your devices when they’re connected to the server. However, this isn’t “absolute privacy,” and it won’t work without the WireGuard app installed on your devices. This guide shows you how to set it up, what it actually protects, and where its limitations lie.

What You Get and What You Don't

DNS filtering blocks domains used for ads, telemetry, and tracking. It works at the network level, so it also protects applications where you can’t install a browser extension. Part of the reason this is interesting is the change to extensions in Chromium-based browsers (Manifest V3), which has limited the capabilities of some ad blockers. However, it is not a complete replacement for them:

• Ads from the same domain: If both the ad and the content come from the same domain, DNS cannot distinguish between them. Therefore, DNS blocking will not cover all video ads, for example.
• Cosmetic filters: DNS cannot hide the empty space left by a blocked ad.
• The DNS provider sees your queries: NextDNS sees the domains you query. You can disable logs or choose where they’re stored, but trust is still required.
• It doesn’t hide traffic: The tunnel is used only for DNS, so your ISP can still see which servers you’re connecting to.

To be more precise: it’s about a more private and cleaner DNS, not anonymity.

Architecture

• WireGuard is running on a Linux server with the address 10.8.0.1.
• The NextDNS CLI listens only on this address and sends queries to NextDNS via encrypted DNS over HTTPS (DoH).
• Clients connect via WireGuard and use it as their DNS 10.8.0.1.
• Only DNS traffic goes through the tunnel. The rest of the internet traffic goes through directly, so you don’t need packet forwarding or NAT.

You need the WireGuard client on every device. On Linux, it’s part of the kernel; on other systems, there are applications available. The claim that filtering works “without additional applications” is therefore not true.

Step 1: WireGuard server

The script is for Debian or Ubuntu. Run it as root and read it before using it. The parameters are the server address and the client name. The script will not run a second time to avoid overwriting existing keys.

#!/usr/bin/env bash
set -euo pipefail

ENDPOINT="${1:?Použitie: sudo ./wg-setup.sh VEREJNA_IP_ALEBO_DOMENA}"
SERVER_IP="10.8.0.1"
CLIENT_IP="10.8.0.2"
PORT=51820

if [ -f /etc/wireguard/wg0.conf ]; then
  echo "wg0.conf už existuje, končím." >&2
  exit 1
fi

apt-get update
apt-get install -y wireguard

umask 077
mkdir -p /etc/wireguard
cd /etc/wireguard

wg genkey | tee server.key | wg pubkey > server.pub
wg genkey | tee client1.key | wg pubkey > client1.pub
wg genpsk > client1.psk

cat > wg0.conf <<EOF
[Interface]
Address = ${SERVER_IP}/24
ListenPort = ${PORT}
PrivateKey = $(cat server.key)

[Peer]
PublicKey = $(cat client1.pub)
PresharedKey = $(cat client1.psk)
AllowedIPs = ${CLIENT_IP}/32
EOF

systemctl enable --now wg-quick@wg0

cat > client1.conf <<EOF
[Interface]
PrivateKey = $(cat client1.key)
Address = ${CLIENT_IP}/32
DNS = ${SERVER_IP}

[Peer]
PublicKey = $(cat server.pub)
PresharedKey = $(cat client1.psk)
Endpoint = ${ENDPOINT}:${PORT}
AllowedIPs = ${SERVER_IP}/32
PersistentKeepalive = 25
EOF

echo "Klientsky súbor: /etc/wireguard/client1.conf"

The important line is AllowedIPs = 10.8.0.1/32 in the client configuration. It means that only communication with the DNS server will go through the tunnel. The file client1.conf contains a private key, so transfer it securely (for example, via a QR code from a tool qrencode or via SSH) and delete it from any locations where it is not needed.

Step 2: NextDNS CLI

First, create a configuration profile on the NextDNS website and make a note of its ID. Then run the official installer according to the project documentation. The installer will ask for settings when it runs, so don’t run it unattended. It’s best to download the script from the internet and read through it before running it. After installation, configure listening only on the tunnel address:

sudo nextdns config set -profile=TVOJE_ID -listen=10.8.0.1:53 -cache-size=10MB -report-client-info=true -setup-router=false
sudo nextdns restart

Two things are essential here. The address 10.8.0.1 must exist before NextDNS starts, otherwise it won’t be able to listen on it. Ensure this by configuring services in systemd, for example with a file /etc/systemd/system/nextdns.service.d/override.conf:

[Unit]
[email protected]
[email protected]

Then run sudo systemctl daemon-reload && sudo systemctl restart nextdns. And don’t let the service listen on all interfaces; otherwise, the server would function as a public DNS resolver.

Step 3: Firewall

Allow only UDP port 51820 from the Internet. Allow DNS only from the tunnel interface:

sudo ufw allow 51820/udp
sudo ufw allow in on wg0 to any port 53
sudo ufw enable

If you use SSH, enable it before you turn on the firewall.

Step 4: Make sure it works

• On the server: dig @10.8.0.1 example.com it should return a response.
• On the client, after connecting the tunnel, open the test page on NextDNS. The protocol should be DoH and the profile should be yours.
• Test a known advertising domain from the blocklist that you’ve enabled in your profile. It should be blocked.

Cache Boost and CNAME flattening

You can find both features in your profile settings on the NextDNS website, not in the CLI:

• According to available descriptions, Cache Boost enforces a minimum time-to-live (TTL) of five minutes for responses. Clients then make requests less frequently, which speeds up response times. Do not confuse it with the CLI cache (cache-size), which is a separate feature.
• CNAME flattening resolves the chain of CNAME records to the final IP address on the service side, thereby reducing the number of queries. This can cause issues with some services, such as email services, and may interfere with certain blocklists. Enable it only if you don’t mind occasional troubleshooting.

Protection against trackers hidden behind CNAME records (CNAME cloaking) is a separate feature in the security settings. Flattening is not a substitute for it.

Security Checklist

• Update the server and secure SSH access with keys.
• The DNS resolver must not be accessible from the public Internet. Verify this from an external network.
• Each device receives its own key and address. This way, you can easily remove a lost device from the server.
• In your NextDNS profile, configure whether you want query logs, how long they’re retained, and where.
• Keep in mind that if the tunnel is not running, the device will use the connection provider’s standard DNS.

What to Take Away From This

Setting up your own WireGuard with the NextDNS CLI is a good way to ensure consistent filtering of queries on both your mobile device and laptop when you’re outside your home network. It’s a step toward a more private DNS, but it doesn’t guarantee perfect privacy. You’ll see the greatest improvement when you combine this with additional layers—such as a browser-based blocker—and remain aware of what this approach doesn’t address.