Stop DNS Leaks in WireGuard — The Definitive Prevention Guide

Introduction

WireGuard has become the VPN technology of choice for performance and simplicity. However, misconfigured DNS behavior can undermine privacy and network policy guarantees. This guide provides comprehensive, practical steps to prevent DNS leaks when using WireGuard, with actionable configurations and diagnostic commands that system administrators, developers, and enterprise networks can use immediately.

Why DNS Leaks Happen with WireGuard

A DNS leak occurs when DNS queries bypass the VPN tunnel and are sent to a local or ISP resolver. With WireGuard, leaks typically arise from the interaction between the WireGuard interface and the host’s DNS resolver stack. Common causes include:

• OS resolver still using the pre-existing system DNS configuration after the tunnel is established.
• Systemd-resolved, NetworkManager, or resolvconf not being updated by WireGuard’s up/down scripts (wg-quick).
• Split-tunneling configurations or AllowedIPs that do not capture DNS traffic.
• IPv6 being left enabled, routing IPv6 DNS queries outside the tunnel.
• Applications performing DNS over DoH/DoT locally or binding to specific system resolvers.

Understand How Your OS Resolves DNS

Before changing anything, map the resolver behavior on your platforms. Different platforms integrate differently with WireGuard:

• Linux (systemd-resolved): Uses /run/systemd/resolve/stub-resolv.conf or 127.0.0.53. WireGuard must update systemd-resolved or use the stub with correct routing.
• Linux (resolvconf or /etc/resolv.conf): Many distributions rely on resolvconf scripts that must be run in wg-quick’s postUp.
• Windows: WireGuard for Windows updates the system DNS if set in the peer config. The interface metric and adapter priorities matter.
• macOS: Uses the per-network-set DNS settings; WireGuard Tunnelblick-like apps may set resolver domains per-interface.
• Android/iOS: Mobile OSes route DNS through the VPN adapter if the platform API is used correctly; some apps can bypass the system resolver.

Best Practices — WireGuard Config and Server Side

Apply defensive defaults on both client and server to ensure DNS stays inside the tunnel.

Client wg-quick tips

• In the client [Interface] section, set the DNS you want the client to use: DNS = 10.0.0.1 (or the server-side resolver IP). This instructs wg-quick to attempt to update resolv.conf or the OS resolver.
• Use AllowedIPs in the [Peer] to control traffic. If you route all traffic via the tunnel, include 0.0.0.0/0 and ::/0 to capture DNS queries. For split-tunnel scenarios, explicitly ensure DNS server IPs are included in AllowedIPs so DNS flows via the tunnel.
• Add reliable PostUp and PostDown scripts to update resolvers or firewall rules (iptables/nftables), and to restore state on disconnect.

Server-side considerations

• Offer an internal DNS resolver reachable through the WireGuard subnet (for example 10.0.0.1). This avoids relying on public resolvers that could be reached through other paths.
• Ensure that the VPN server network settings forward DNS queries and block leaks by firewalling non-tunnel DNS where needed.
• Provide clear documentation to clients about the DNS IPs and configuration required for your managed endpoints.

System-specific Strategies

Below are tailored approaches for common environments with sample actions you can take immediately.

Linux with systemd-resolved

systemd-resolved uses a per-link DNS setting. To bind the VPN DNS to the WireGuard interface:

• Use wg-quick’s DNS directive and configure PostUp to call resolvectl (or systemd-resolve in older versions):

Example action: run resolvectl to set DNS for the wg interface and set the search domains. On teardown, clear the settings.

• Alternatively, bypass the stub resolver by writing a custom /etc/resolv.conf pointing to an internal resolver IP reachable only through the tunnel. Ensure the tunnel is up before DNS resolution starts.

Linux with resolvconf

Make wg-quick invoke resolvconf to push DNS entries into the resolver stack. Include PostUp and PreDown hooks to add and remove DNS entries.

Windows

WireGuard for Windows sets DNS when specified in the interface config. To avoid leaks:

• Specify DNS in the interface block in the .conf used by the client UI.
• Ensure the adapter metric for the WireGuard interface is prioritized (lower metric = higher priority) so that DNS queries go over WireGuard.

macOS

Use the official WireGuard macOS client or set resolver settings per interface. Confirm per-interface DNS via:

• networksetup -getdnsservers [networkservice] or scutil –dns

Android/iOS

Mobile OSes typically route DNS through the VPN adapter created by the official WireGuard apps. To reduce leaks:

• Disable VPN bypass for specific apps if using per-app VPN.
• Use the app’s built-in DNS setting and prefer an in-tunnel resolver.

Firewall Measures to Force DNS Through the Tunnel

When resolver updates are unreliable, enforce DNS routing at the packet level. The following approach applies to Linux servers and clients that support iptables/nftables.

• Redirect outbound port 53 UDP/TCP to the in-tunnel DNS IP or to the WireGuard interface using NAT/REDIRECT. This captures any accidental queries sent to the default gateway or ISP resolver.
• Block all outbound DNS (port 53) to non-tunnel interfaces while allowing the internal resolver. This prevents applications that perform raw DNS from bypassing the tunnel.

Important: Ensure your iptables/nftables rules run in wg-quick PostUp and are undone in PreDown to avoid leaving systems locked out when the tunnel is down.

IPv6: Don’t Forget It

IPv6 is a common leak vector because many admins only control IPv4 settings. Approaches:

• Include ::/0 in AllowedIPs if you want to tunnel IPv6 traffic through WireGuard.
• If you don’t plan to route IPv6 via the VPN, explicitly disable IPv6 on the client or firewall outbound IPv6 DNS (UDP/TCP 53) to prevent leaks.

DNS Privacy Hardenings

Even when DNS is routed through the tunnel, you can add layers of privacy:

• Use an in-tunnel DoT or DoH resolver that the server runs (e.g., unbound with DNS-over-TLS, or a DoH proxy reachable only through the tunnel).
• Run a caching resolver (unbound, dnsmasq) on the WireGuard server to minimize upstream queries that could reveal client activity.
• Consider DNSSEC validation on your resolver to protect integrity.

Testing for DNS Leaks — Tools and Commands

Validate your setup before declaring victory. Useful checks include:

• Use external web leak testers (from within the tunnel): for example, visit an IP/DNS leak tester or run web-based DNS leak sites (be cautious in enterprise environments).
• Linux diagnostic commands:
  • dig +short @ whoami.akamai.net — to check which resolver and path is used
  • tcpdump -i port 53 — to see live DNS traffic and interfaces used
  • resolvectl status or systemd-resolve –status — to confirm active DNS on the wg interface
• Windows:
  • nslookup and route print to verify the adapter used and DNS server responses

Run these tests with and without the tunnel active and after making any DNS-related firewall changes.

Example Minimal wg-quick Workflow

Use the following checklist on client machines when deploying WireGuard at scale:

• Set DNS in the [Interface] block to the in-tunnel resolver.
• Include full-routing AllowedIPs (0.0.0.0/0, ::/0) or at minimum include your resolver IPs in AllowedIPs for split-tunnel.
• Add PostUp to update the OS resolver and set iptables/nftables rules to redirect DNS if necessary.
• Confirm via tcpdump/dig/resolvectl that DNS queries traverse the wg interface.
• Automate testing in your endpoint provisioning pipeline to catch misconfigurations.

Troubleshooting Checklist

If DNS still leaks, walk through these common causes:

• Resolver was cached on the client before wg-quick applied changes — restart the resolver service or flush caches.
• Local firewalls or security agents intercept DNS and redirect it — identify and adjust rules.
• Third-party VPN/antivirus clients competing for network stack control — ensure the WireGuard client has priority or disable conflicting clients.
• IPv6 enabled but not tunnelled — block or tunnel IPv6 DNS.

Conclusion

DNS leaks can silently undermine the privacy and security benefits of WireGuard, but they are preventable with a combination of correct configuration, resolver integration, firewall enforcement, and validation testing. Implementing per-interface DNS, prioritizing the WireGuard adapter, redirecting or blocking non-tunnel DNS at the firewall, and running an in-tunnel resolver are the most robust strategies.

For deploys across many endpoints, codify these steps into your install scripts and configuration management (Ansible, Puppet, Chef) so that DNS protection is enforced consistently.

For more in-depth guides and template configurations tailored for enterprise deployments, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.