Tech on Welcome to my photography blog

Privacy by Routing DNS Traffic Through a VPN Tunnel

Sun, 17 May 2026 13:00:43 +0200

Privacy by routing DNS traffic through a VPN Tunnel on a Mikrotik router

Why DNS Privacy Still Matters in 2026

Most people think that when they browse the internet using HTTPS, their online activities are completely private. Unfortunately, that is not entirely true.

HTTPS encrypts the content of your communication with a website. Your internet provider cannot see the pages you read, the forms you submit, or the passwords you enter. However, before your browser can connect to a website, it first needs to know the IP address of that website.

This is where DNS comes into play.

DNS (Domain Name System) acts as the internet’s phonebook. When you visit a website such as www.example.com, your device performs a DNS query to find the corresponding IP address.

Traditionally, these DNS queries are sent in plain text over the internet. Anyone between you and the DNS server can potentially see which domains you are looking up.

The Privacy Problem

Even when all your web traffic is protected by HTTPS, DNS requests can reveal a surprising amount of information:

Websites you visit
Applications you use
Smart home devices in your network
Streaming services you access
Business services and cloud platforms you connect to

In many cases, DNS traffic creates a detailed profile of your online behavior.

Isn’t DNS over HTTPS the Solution?

DNS over HTTPS (DoH) is certainly an improvement.

Instead of sending DNS requests in plain text on port 53, DNS queries are encapsulated within HTTPS traffic on port 443.

This provides protection against:

Local network snooping
Public Wi-Fi monitoring
Basic ISP DNS inspection

However, DoH does not make you invisible.

Your ISP can still see:

The destination IP address you connect to
The DNS provider you use
Traffic patterns
Connection metadata

Depending on the implementation, technologies such as SNI (Server Name Indication) or traffic analysis may still reveal information about the services being accessed.

In short:

DNS over HTTPS encrypts the DNS query itself, but not necessarily all metadata surrounding the connection.

A Different Approach: Route DNS Through a VPN

A stronger privacy model is to route all DNS traffic through a VPN tunnel.

In this setup:

Internal DNS servers perform DNS lookups.
DNS traffic is marked by the router.
The marked traffic is sent through a WireGuard VPN tunnel.
The ISP only sees encrypted WireGuard traffic.
External DNS providers only see the VPN endpoint address.

This significantly reduces the visibility of DNS activity to your internet provider.

My Environment

I use:

MikroTik Router with RouterOS 7.20.6
WireGuard VPN
ProtonVPN (or other VPN provider)
Multiple Pi-hole DNS servers, running on my Proxmox homelab server

The goal is simple:

Only DNS traffic should travel through the VPN tunnel.

All normal internet traffic continues to use the regular WAN connection.

This approach provides additional privacy without forcing all users and applications through the VPN.

Step 1: Create an Address List

First, create an address list containing all internal DNS servers.

1
2
3


/ip/firewall/address-list
add address=192.168.1.10 comment=Pi-Hole1 list="DNS Servers"
add address=192.168.1.11 comment=Pi-Hole2 list="DNS Servers"

What does this do?

This creates a group called DNS Servers.

Instead of creating firewall rules for every DNS server individually, we can simply reference this address list.

Advantages:

Easier management
Better scalability
Cleaner configuration

Step 2: Mark DNS Traffic

The next step is to identify DNS traffic generated by these servers and mark it for special routing.

UDP Port 53

1
2
3
4
5
6
7


add action=mark-routing chain=prerouting \
 comment="DNS traffic (UDP) via WG-ProtonVPN" \
 dst-port=53 \
 new-routing-mark=to-ProtonVPN \
 passthrough=no \
 protocol=udp \
 src-address-list="DNS Servers"

Explanation

This rule says:

“If traffic originates from one of the DNS servers and uses UDP port 53, mark it with routing mark to-ProtonVPN.”

UDP 53 is the traditional DNS protocol.

The parameter:

1

passthrough=no

means processing stops after the packet is marked.

UDP Port 853

1
2
3
4
5
6
7


add action=mark-routing chain=prerouting \
 comment="DNS traffic (UDP) via WG-ProtonVPN" \
 dst-port=853 \
 new-routing-mark=to-ProtonVPN \
 passthrough=no \
 protocol=udp \
 src-address-list="DNS Servers"

Explanation

Port 853 is commonly used by encrypted DNS technologies. This ensures those DNS requests are also routed through the VPN.

TCP Port 53

1
2
3
4
5
6
7


add action=mark-routing chain=prerouting \
 comment="DNS traffic (TCP) via WG-ProtonVPN" \
 dst-port=53 \
 new-routing-mark=to-ProtonVPN \
 passthrough=no \
 protocol=tcp \
 src-address-list="DNS Servers"

Explanation

Although most DNS traffic uses UDP, larger responses may fall back to TCP.

Examples include:

Large DNS responses
DNS zone transfers
Certain DNSSEC operations

This rule ensures TCP-based DNS traffic is also protected.

TCP Port 853

1
2
3
4
5
6
7


add action=mark-routing chain=prerouting \
 comment="DNSSEC traffic (TCP) via WG-ProtonVPN" \
 dst-port=853 \
 new-routing-mark=to-ProtonVPN \
 passthrough=no \
 protocol=tcp \
 src-address-list="DNS Servers"

Explanation

This captures encrypted ‘DNS of TLS’ (DoT) traffic using TCP on port 853.

Again, the traffic receives the routing mark and is directed toward the VPN.

TCP Port 443

1
2
3
4
5
6
7


add action=mark-routing chain=prerouting \
 comment="DNS-HTTPS traffic (TCP) via WG-ProtonVPN" \
 dst-port=443 \
 new-routing-mark=to-ProtonVPN \
 passthrough=no \
 protocol=tcp \
 src-address-list="DNS Servers"

Explanation

This is the rule that captures DNS over HTTPS (DoH).

Most DoH providers use HTTPS over TCP port 443.

Because the traffic originates from the DNS servers in our address list, we can reasonably assume this HTTPS traffic is DNS-related and should be sent through the VPN.

This prevents DNS-over-HTTPS requests from bypassing the privacy tunnel.

Step 3: Create a Dedicated Route

Now we create a routing table that uses the WireGuard tunnel.

1
2
3
4
5
6
7
8


/ip route
add disabled=no \
 distance=1 \
 dst-address=0.0.0.0/0 \
 gateway=wg2-ProtonVPN \
 routing-table=to-ProtonVPN \
 scope=30 \
 target-scope=10

Explanation

This route says:

“When traffic arrives with routing mark to-ProtonVPN, send it through the WireGuard interface wg2-ProtonVPN.”

Only marked traffic uses this route.

All other traffic follows the normal routing table.

This is what makes selective VPN routing possible.

Step 4: Routing Rule

1
2
3
4
5
6


/routing rule
add action=lookup \
 comment="Route DNS traffic over ProtonVPN" \
 disabled=no \
 routing-mark=to-ProtonVPN \
 table=to-ProtonVPN

Explanation

This rule tells RouterOS to perform a route lookup in the to-ProtonVPN routing table whenever packets carry the routing mark to-ProtonVPN.

On modern RouterOS versions, routing marks and routing tables often work directly together without requiring additional routing rules. Depending on your RouterOS design and version, this rule may not be necessary.

Always test routing behavior after enabling or disabling routing rules.

What Does My ISP See?

Without this setup:

1

DNS Server ---> Internet DNS Provider

The ISP can observe DNS traffic and metadata.

With this setup:

1

DNS Server ---> WireGuard Tunnel ---> VPN Provider ---> DNS Provider

The ISP only sees:

1

Encrypted WireGuard Traffic

The DNS requests themselves travel inside the VPN tunnel.

This significantly improves privacy.

Final Thoughts

Privacy on the internet is not a single technology.

HTTPS protects website content.

DNS over HTTPS protects DNS queries.

WireGuard protects traffic between your router and the VPN endpoint.

By combining these technologies and routing DNS traffic through a dedicated WireGuard tunnel on MikroTik RouterOS, you create multiple layers of privacy.

The result is a simple but effective setup:

Internal DNS servers remain local.
DNS traffic is encrypted.
DNS traffic is hidden from the ISP.
Normal internet traffic can continue using the regular WAN connection.

For home labs and privacy-conscious MikroTik users, selective DNS routing over WireGuard offers an elegant balance between privacy, performance, and simplicity.

Building a High-Availability DNS Cluster on Debian

Fri, 08 May 2026 09:00:43 +0200

High-Availability DNS Cluster: Technitium + Keepalived (IPVS) on Debain LXC Container

Domain Name System (DNS) is the backbone of any network infrastructure. When your DNS servers go down, your entire network effectively stops functioning. While many network administrators simply deploy two separate DNS servers and list both in their DHCP scope, this approach does not provide true load balancing or instantaneous failover.

In this guide, we will build a production-grade, highly available DNS cluster using two Technitium DNS servers running inside Proxmox Linux Containers (LXC). We will leverage Keepalived and IPVS (IP Virtual Server) to achieve both seamless load balancing and intelligent failover over a single Virtual IP (VIP) address.

Why Standard Secondary DNS Isn’t Enough

Most home labs and enterprise environments deploy two DNS servers (Primary and Secondary). They hand out both IP addresses via DHCP. However, the client-side implementation of this is flawed:

Unpredictable Routing: Some operating systems (like Windows) stick to the primary server until it completely times out, causing severe delays during an outage. Other systems (like macOS/Linux) might query both semi-randomly, making traffic distribution unpredictable.
No Real Load Balancing: Traffic is rarely distributed evenly between the two servers.
Slow Failover: If the primary DNS server freezes but keeps its network link active, clients will waste precious seconds waiting for timeouts before trying the secondary server.

The Solution: Keepalived + IPVS

By introducing Keepalived with IPVS at Layer 4, we create a single Virtual IP (VIP). Your clients only ever talk to this one IP address.

Keepalived acts as an intelligent traffic director:

Load Balancing: It splits incoming UDP and TCP port 53 DNS queries evenly across both Technitium instances using a Round Robin algorithm.
Instant Failover: It continuously polls the health of each Technitium instance. If one container or DNS service crashes, Keepalived immediately removes it from the rotation.
Infrastructure Redundancy: Keepalived uses VRRP (Virtual Router Redundancy Protocol). If the primary load-balancing container dies entirely, the secondary container instantly assumes the VIP within milliseconds.

Schematic Overview

[ NETWERK CLIENTS ]
(Request DNS via VIP)
 │
 ▼
 ┌────────────────┐
 │ VIRTUEL IP │
 │ 192.168.1.10 │
 └───────┬────────┘
 │
 ┌──────┴──────┐ (Keepalived VRRP / IPVS)
 │ │ (Divide UDP/TCP requests via Round Robin)
 ▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ LXC Container 1 │ │ LXC Container 2 │
│ [MASTER] │ │ [BACKUP] │
│ 192.168.1.11 │ │ 192.168.1.12 │
├─────────────────┤ ├─────────────────┤
│ Technitium #1 │ │ Technitium #2 │
│ (lo: .1.10/32) │ │ (lo: .1.10/32) │
└────────┬────────┘ └────────┬────────┘
 │ │
 └──────────┬──────────┘
 │ (Direct Routing - DR Mode)
 ▼
 [ Direct Answer ]
 (Back to Clients)

Explanation of the data flow:

Inbound traffic: Network clients send all their DNS requests exclusively to the Virtual IP (192.168.1.10).
Load Balancing: The container currently holding the MASTER role (Container 1) intercepts the traffic and distributes the requests across the two Technitium DNS backends using the Linux IPVS kernel module (Round Robin).
Direct Routing (DR): Thanks to the loopback configuration (lo: 192.168.1.10/32), both containers process the packets directly and send the response straight back to the client, bypassing the load balancer. This ensures minimal latency.
Failover: If Container 1 fails, Keepalived moves the VIP to Container 2 within a fraction of a second; from that point on, Container 2 handles the requests independently.

Architectural Overview

Virtual IP (VIP): 192.168.1.10 (The single DNS address given to your clients)
Technitium Container 1 (MASTER): 192.168.1.11
Technitium Container 2 (BACKUP): 192.168.1.12

Step 1: Preparing the Proxmox Host (Crucial for LXC)

Because LXC containers share the host’s Linux kernel, they cannot load kernel modules or manipulate network routing infrastructure by default. We must prepare the Proxmox host first.

1. Load IPVS Modules on the Host

Log into your Proxmox VE Host via SSH and run the following commands to load the required IPVS load-balancing kernel modules:

modprobe ip_vs
modprobe ip_vs_rr

To ensure these modules survive a Proxmox host reboot, append them to the host’s /etc/modules file:

echo "ip_vs" >> /etc/modules
echo "ip_vs_rr" >> /etc/modules

2. Adjust LXC Container Permissions

You must grant your containers permission to interact with the network stack. On your Proxmox host, open the configuration files for both containers (located at /etc/pve/lxc/YOUR_CONTAINER_ID.conf) and add these lines: Make sure the the LXC container are running in privilegded mode. Option “unprivileged: 0” in .conf

1
2
3
4
5
6


lxc.apparmor.raw: mount fstype=devpts,
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file
# SAFE Capabilties (let the console alive, but give networks rights)
lxc.cap.drop: 
lxc.cap.keep: sys_admin net_admin chown dac_override fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_raw ipc_owner sys_chroot sys_ptrace sys_tty_config

Restart both LXC containers after saving these changes.

Step 2: Configuring the Loopback Interface on the Containers

We will be using Direct Routing (DR) mode in IPVS. This is the fastest method of load balancing because incoming traffic goes through the load balancer, but the backend Technitium servers reply directly to the client.

For this to work, both containers must accept packets destined for the VIP (192.168.1.10), but they must not broadcast this IP to the local network to avoid IP conflicts. We solve this by binding the VIP to the local loopback (lo) interface.

Inside both Debian LXC containers, open /etc/network/interfaces:

nano /etc/network/interfaces

Modify the loopback configuration block to match the following:

auto lo
iface lo inet loopback
 up ip addr add 192.168.1.10/32 dev lo
 down ip addr del 192.168.1.10/32 dev lo

Apply the changes instantly without a reboot:

ifdown lo && ifup lo

Step 3: Installing and Configuring Keepalived

Now, log into both containers to install Keepalived and the IPVS administration utility:

apt update && apt install -y keepalived ipvsadm

1. Configuration for Container 1 (MASTER)

Create the configuration file /etc/keepalived/keepalived.conf on your first Technitium container:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66


global_defs {
 router_id dns_lb1
 enable_script_security
}

# 1. High Availability (VRRP Configuration)
vrrp_instance VI_1 {
 state MASTER
 interface eth0 # Replace with your actual network interface
 virtual_router_id 51
 priority 101 # Higher priority wins the VIP
 advert_int 1
 authentication {
 auth_type PASS
 auth_pass A_Secure_Cluster_Password
 }
 virtual_ipaddress {
 192.168.1.10/24 # Your Virtual IP (VIP)
 }
}

# 2. Load Balancing for DNS UDP (Port 53)
virtual_server 192.168.1.10 53 {
 delay_loop 6
 lb_algo rr # Round Robin distribution
 lb_kind DR # Direct Routing mode
 protocol UDP

 real_server 192.168.1.11 53 {
 weight 1
 MISC_CHECK {
 misc_path "/usr/bin/nc -zu -w 1 127.0.0.1 53" # Local health check
 misc_timeout 2
 }
 }

 real_server 192.168.1.12 53 {
 weight 1
 MISC_CHECK {
 misc_path "/usr/bin/nc -zu -w 1 192.168.1.12 53" # Remote health check
 misc_timeout 2
 }
 }
}

# 3. Load Balancing for DNS TCP (Port 53)
virtual_server 192.168.1.10 53 {
 delay_loop 6
 lb_algo rr
 lb_kind DR
 protocol TCP

 real_server 192.168.1.11 53 {
 weight 1
 TCP_CHECK {
 connect_timeout 3
 }
 }

 real_server 192.168.1.12 53 {
 weight 1
 TCP_CHECK {
 connect_timeout 3
 }
 }
}

2. Configuration for Container 2 (BACKUP)

Create the exact same file on your second Technitium container, but change the vrrp_instance configuration block to reflect its backup status and lower priority:

 state BACKUP
 priority 100 # Lower than the MASTER server

3. Enable and Start Keepalived

Run this command on both containers to start the service and ensure it launches automatically at boot:

systemctl enable --now keepalived

Step 4: Verification and Testing

Your high-availability cluster is now live! Let’s verify that everything is working perfectly.

1. Check IP Allocation

On Container 1 (MASTER), run:

ip addr show eth0

You should see both its local IP (192.168.1.11) and the VIP (192.168.1.10). If you run the same command on Container 2, the VIP should not be present.

2. Inspect the Load Balancing Table

Run the following command on the container that is currently acting as the MASTER:

ipvsadm -ln

You will see a clean routing matrix mapping your VIP to both backend servers across TCP and UDP protocols.

3. Simulating a Failure

To test the failover capability, stop the Keepalived service on Container 1:

systemctl stop keepalived

If you run ip addr show eth0 on Container 2, you will notice that it has gracefully assumed control of the VIP (192.168.1.10) in a fraction of a second. Your network clients will experience zero downtime, and DNS queries will keep resolving seamlessly.

4. Monitoring Real-Time Traffic Distribution

Once your high-availability DNS cluster is running, you will want to see it in action. The best way to monitor how Keepalived and IPVS are distributing traffic between your Technitium servers is by using the following debugging command:

watch -n 0.5 ipvsadm -Ln

What it does

This command combines two powerful Linux utilities. The ipvsadm -Ln command lists the current IP Virtual Server kernel routing table in a clean, numeric format (-n), skipping slow DNS lookups. By wrapping it in watch -n 0.5, the terminal automatically refreshes the output every half-second, providing a near-real-time view of your live network traffic.

How to interpret the output When you run this on the active MASTER container, you will see an output structured like this:

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheduler Flags
 -> RemoteAddress:Port Forward Weight ActiveConn InActConn
UDP 192.168.1.10:53 rr
 -> 192.168.1.11:53 Route 1 0 142 
 -> 192.168.1.12:53 Route 1 0 139

Key metrics to look out for:

UDP/TCP … rr: Confirms that IPVS is listening on your Virtual IP (VIP) on port 53 and using the Round Robin (rr) scheduler.
Forward (Route): Indicates that Direct Routing (DR) is working properly.
Weight: A value of 1 means the server is healthy. If Keepalived detects that a Technitium instance is down, this weight will immediately drop to 0, removing it from rotation.
InActConn (Inactive Connections): Since DNS over UDP is stateless, queries do not stay open. Instead, they quickly register as inactive connections. Watch these numbers increment evenly on both rows as clients make requests—this is visual proof that your load balancer is dividing the work perfectly!

Conclusion

By coupling Technitium DNS with Keepalived and IPVS, you eliminate the classic pitfalls of primary/secondary DNS configurations. You get an enterprise-grade setup that guarantees absolute uptime, linear traffic distribution, and instantaneous failover management—all running within lightweight, low-overhead Proxmox LXC containers.