Self-host MasterDnsVPN on Netcup — a DNS-tunneling VPN on a 6 € VPS

Self-host MasterDnsVPN on a Netcup VPS to run a DNS-tunneling VPN that carries TCP traffic inside ordinary-looking DNS queries — the last transport that still works when everything else is filtered. MasterDnsVPN is a single-binary Go application that turns a domain you control into a covert tunnel: the client wraps data in DNS lookups, public resolvers forward them, and your server reassembles the stream and forwards it out. It needs almost no RAM, almost no disk, a real IPv4, and UDP port 53 — which is exactly what a cheap Netcup VPS gives you.

TL;DR: Running MasterDnsVPN on Netcup in 5 minutes

MasterDnsVPN is a research-grade DNS tunnel written in Go, MIT-licensed, maintained by the developer MasterkinG32, with rolling releases (the current build is dated June 2026). The server is a small static binary that listens on UDP/TCP 53, claims authority over a delegated subdomain via NS records, and forwards client traffic over SOCKS5. The client runs locally, exposes a SOCKS5 proxy on 127.0.0.1:18000, and pushes every byte through a pool of public DNS resolvers so no single path can be blocked.

• What it is: a self-hosted DNS VPN that encapsulates TCP inside DNS queries to beat deep packet inspection and bandwidth throttling.
• What it competes with: iodine, dnstt, dns2tcp — and, in spirit, any censorship-resistant proxy like Hysteria, Xray, or Shadowsocks when those are themselves blocked.
• Hosting profile: tens of megabytes of RAM at idle, negligible disk (config files only), CPU-light, but packet-heavy — DNS tunneling sends many tiny datagrams and duplicates them for resilience.
• Ports: UDP and TCP 53 on the server; TCP 18000 for the local SOCKS5 proxy on the client.
• Persistence: two small files — encrypt_key.txt and server_config.toml. No database, no Redis, nothing to back up nightly.
• License: MIT, no telemetry, no hosted tier to upsell you.

# on the server, with UDP 53 free and a delegated subdomain ready
bash <(curl -Ls https://raw.githubusercontent.com/masterking32/MasterDnsVPN/main/server_linux_install.sh)
# the script generates encrypt_key.txt and starts the systemd service
dig @ns.example.com v.example.com A   # verify your NS delegation resolves

Primary pick: VPS 500 G12 — 2 vCPU, 4 GB RAM, 128 GB NVMe, around 5.91 €/month. A DNS tunnel for one person or a small group never touches the ceiling of this tier; the binary idles in the tens of megabytes and the workload is network packets, not memory or storage.

• 5 € off any order: 36nc17718015542
• Second code: 36nc17718015546
• Third code: 36nc17718015547

Introduction

Every circumvention tool eventually meets a network that blocks it. WireGuard handshakes get fingerprinted, QUIC on UDP 443 gets throttled, TLS-based proxies get caught by SNI filtering. But almost no network blocks DNS outright, because blocking DNS breaks the network itself — captive portals, corporate gateways, and even national firewalls leave UDP 53 open so that name resolution keeps working. DNS tunneling exploits exactly that gap: if you can resolve a hostname, you can move data, however slowly.

MasterDnsVPN is the tool people reach for when the situation is genuinely hostile — it was built and proven during Iran's 88-day blackout, when roughly 99% of international bandwidth was severed and conventional VPNs simply stopped passing packets. It is not a daily-driver VPN for streaming 4K; it is a survival transport for when the alternatives are dead. That framing matters for hosting, because it tells you what to optimise for: reliability and a clean IPv4 with open port 53, not raw throughput.

This is a self-hosted tool by necessity. A DNS tunnel needs a server that is authoritative for a subdomain you own, so public resolvers forward your queries to it. You cannot get that from a shared SaaS proxy — you need your own box, your own domain, and control over the NS records. Netcup fits the job: data centres in Nuremberg and Vienna on owned hardware, a real dedicated IPv4 on every tier, NVMe storage even on the cheapest plan, and a generous included-traffic allowance that absorbs the inherent overhead of DNS tunneling without a surprise bill.

By the end of this article you will have a MasterDnsVPN server answering DNS queries for your subdomain on a Netcup VPS, a hardened box that survives reboots, a client connected through it over SOCKS5, and a clear answer to which tier matches your user count.

What is MasterDnsVPN?

MasterDnsVPN is an open-source DNS-tunneling VPN written in Go and distributed under the MIT license. It ships as two separate static binaries — a server and a client — with no runtime dependencies, no interpreter, and no database. The client encrypts your traffic, fragments it into chunks small enough to fit inside DNS query labels, and sends those queries to a rotating pool of public resolvers. Those resolvers, following standard DNS rules, forward the queries to the authoritative nameserver for your subdomain — which is your server. The server reassembles the stream, forwards it to its real destination, and returns the response the same way, packed into DNS answer records.

The project lives in the same problem space as older tunnels like iodine, dnstt, and dns2tcp, but it makes different engineering bets. It runs a custom ARQ (Automatic Repeat reQuest) layer for reliable delivery over a fundamentally lossy channel, balances traffic across many resolvers with eight selectable strategies, duplicates packets to survive drops, and keeps protocol overhead down to roughly 5–7 bytes per packet — which is where its throughput advantage over older tools comes from. None of that changes the basic physics: DNS tunneling is slow and packet-dense. It changes how gracefully the tunnel degrades when the network is fighting you.

Architecture

A deployment is a Go binary plus a TOML config plus a shared key file. The server binds UDP and TCP on port 53 (UDP_HOST = "0.0.0.0", UDP_PORT = 53), receives tunneled queries, and either acts as a SOCKS5 proxy choosing the destination per connection or forwards everything to one fixed target in TCP mode. Encryption is selectable per deployment — 0 none, 1 XOR, 2 ChaCha20, 3–5 AES-GCM variants — and the client and server must agree on both the method and the shared key. The official Linux installer drops the binary, generates encrypt_key.txt, and registers a systemd service.

How big does it get

Tiny. The state the server keeps is in-memory session and stream tables plus an optional DNS cache; on disk there is nothing but config. There is no media library to grow, no index to bloat, no write amplification. What scales with usage is packet rate and bandwidth, not storage — every active stream is a stream of small DNS exchanges, and with packet duplication enabled (the default duplicates each packet three times) the network footprint is several times the payload. This is the one resource line to watch, and it is the one Netcup handles well with included traffic.

How to use MasterDnsVPN

Day to day, MasterDnsVPN is a two-sided tool: an always-on server on your Netcup box, and a client you launch on whatever device needs to escape the filtered network. The mental model is closer to a SOCKS proxy than to a system-wide VPN — nothing is captured at the kernel routing layer by default. You point individual applications, or a whole browser, at the client's local SOCKS5 endpoint.

Core concepts

There are four nouns to understand. A domain (really a delegated subdomain like v.example.com) is the tunnel's address — the client builds DNS queries under it, and your server is authoritative for it. Resolvers are the public DNS servers the client bounces queries through; the more you list, the more redundant paths you have. The encryption key is the shared secret in encrypt_key.txt that both ends must match. And the SOCKS5 listener on 127.0.0.1:18000 is where your applications actually connect.

Day-to-day workflow

You start the server once and leave it running under systemd. On the client device you edit client_config.toml with three things — the domain, the encryption key, and the encryption method — populate client_resolvers.txt with a list of public DNS resolvers, and run the client binary. It validates resolvers, probes MTU, and opens the local proxy. From there you set your browser's SOCKS5 host to 127.0.0.1 port 18000 and traffic flows through the tunnel. If a resolver goes bad, the client detects the failure and reroutes automatically; you do not babysit it.

Integrations and extensibility

The client speaks standard SOCKS5, including UDP Associate, so anything SOCKS-aware works: browsers, curl --socks5, and proxy-chaining tools. For phones, the common pattern is to bind the client to 0.0.0.0 on a machine on your LAN and point the phone's SOCKS5 settings at it, or to chain the tunnel as an outbound in a panel like 3X-UI. The server can also forward to an upstream SOCKS5 proxy (USE_EXTERNAL_SOCKS5 = true) if you want the tunnel to be one hop in a longer chain.

Backup and operational reality

Backup is trivial because there is almost nothing to back up. The two files that matter are encrypt_key.txt and server_config.toml; copy them somewhere safe and you can rebuild the server in minutes. The thing that is not reproducible is your DNS delegation — the A and NS records at your registrar — so document those. Everything else, including the binary, comes back from a single install command.

Quick Start Guide

This walks through a full server deployment on a fresh Netcup VPS running Debian, plus a Linux client. Five to seven minutes of work, most of it waiting for DNS to propagate.

1. Provision the box

Sign up for the VPS 500 G12 at netcup.com using coupon 36nc17718015541 for 5 € off the order. Drop your SSH public key in during creation, then SSH in and lock the box down before anything else:

# /etc/ssh/sshd_config.d/00-hardening.conf
PasswordAuthentication no
PermitRootLogin prohibit-password

sudo systemctl reload ssh

Note the server's IPv4 address — you will point DNS at it in the next step.

2. Delegate a subdomain to the server

The tunnel needs your server to be the authoritative nameserver for a subdomain. At your registrar or DNS provider, create two records. First an A record giving your nameserver a name, then an NS record delegating the tunnel subdomain to that name:

# DNS zone for example.com
ns.example.com.   A    203.0.113.10      ; your VPS IPv4
v.example.com.    NS   ns.example.com.   ; delegate the tunnel subdomain

Keep the subdomain short — every character spent on the domain is a byte stolen from the tunnel payload. If you use Cloudflare, the ns A record must be set to DNS only (grey cloud); a proxied record will not work, and NS records cannot be proxied at all.

3. Free up port 53

Debian's systemd-resolved often holds a stub listener on port 53, which collides with the tunnel server. Check, then disable the stub:

sudo ss -lunp 'sport = :53'          # see what owns UDP 53
sudo sed -i 's/^#\?DNSStubListener=.*/DNSStubListener=no/' /etc/systemd/resolved.conf
sudo systemctl restart systemd-resolved

If /etc/resolv.conf was pointing at the stub, repoint it at a real resolver (echo 'nameserver 1.1.1.1' | sudo tee /etc/resolv.conf) so the box can still resolve names for the install step.

4. Install the server

Run the official installer. It fetches the binary, prompts for your delegated subdomain, generates the shared key, and registers a systemd service:

bash <(curl -Ls https://raw.githubusercontent.com/masterking32/MasterDnsVPN/main/server_linux_install.sh)

When it finishes, print the generated key — you will need it verbatim on the client:

cat encrypt_key.txt

If you prefer not to pipe a script into bash, download the prebuilt Linux server binary from the project's releases, drop a server_config.toml next to it with your DOMAIN, and run it under a systemd unit yourself. Set DATA_ENCRYPTION_METHOD = 2 in that file rather than leaving the default XOR.

5. Open the firewall

The tunnel listens on UDP and TCP 53. Netcup does not put an external firewall in front of your VPS by default, but if you run a host firewall, allow both:

sudo ufw allow 53/udp
sudo ufw allow 53/tcp
sudo ufw status

6. Verify the delegation

Before touching the client, confirm the world can reach your server as a nameserver. Querying your subdomain directly against your nameserver should return an answer from the tunnel process, not a timeout:

dig @ns.example.com v.example.com A +short
dig v.example.com A          # resolved via the public resolver chain

DNS delegation can take anywhere from a minute to a few hours to propagate depending on your provider's TTLs. If the direct @ns.example.com query works but the second one does not, you are waiting on propagation, not misconfigured.

7. Configure and run the client

On the client device, download the Linux client, unzip it, and edit the config. The three lines that must match the server are the domain, the encryption method, and the key:

sudo apt update && sudo apt install -y unzip
unzip MasterDnsVPN_Client_Linux_AMD64.zip
chmod +x MasterDnsVPN_Client_Linux_AMD64
nano client_config.toml

# client_config.toml — the parts that must match the server
DOMAINS = ["v.example.com"]
DATA_ENCRYPTION_METHOD = 2          # ChaCha20, same as the server
ENCRYPTION_KEY = "paste-the-contents-of-encrypt_key.txt-here"
PROTOCOL_TYPE = "SOCKS5"
LISTEN_IP = "127.0.0.1"
LISTEN_PORT = 18000

Put a handful of public resolvers in client_resolvers.txt (one per line, IP or IP:port), then launch the client and point a browser's SOCKS5 proxy at 127.0.0.1:18000:

printf '8.8.8.8\n1.1.1.1\n9.9.9.9\n' > client_resolvers.txt
./MasterDnsVPN_Client_Linux_AMD64

The client probes each resolver, drops the dead ones, and opens the local proxy. Test it end to end with curl --socks5 127.0.0.1:18000 https://ifconfig.co — the address returned should be your Netcup VPS.

Choosing the Right Netcup Server for cheap MasterDnsVPN hosting

The server's resource appetite is small and flat: a Go binary with no database, idling in tens of megabytes, with CPU work that only shows up under heavy encryption and high packet rates. So the question is not "how much RAM" — even the cheapest tier has an order of magnitude more than you need — but "how many concurrent users, and how much sustained packet processing." Here are four tiers that bracket the realistic choices.

VPS 500 G12 — recommended for a personal tunnel

Specs: 2 vCPU, 4 GB RAM, 128 GB NVMe, traffic included. Around 5.91 €/month (verify on netcup.com).

For one person, or a household sharing the proxy, this is all you need. The tunnel never approaches 4 GB of RAM, the disk is irrelevant, and two shared vCPUs handle ChaCha20 plus ARQ for a single user without breaking a sweat. The €5-off coupon applies to any order, including this tier:

• 36nc17718015544
• 36nc17718015543
• 36nc17718015540

VPS 1000 G12 — headroom for a small group

Specs: 4 vCPU, 8 GB RAM, 256 GB NVMe, traffic included. Around 10.37 €/month (verify on netcup.com).

If you are sharing the tunnel with friends or a small team, the extra two vCPUs matter more than the RAM. Each active session means continuous small-packet encryption and ARQ bookkeeping, and packet duplication multiplies the work. Four cores keep response latency low when a dozen streams are live at once.

• 5799nc17774618550
• 5799nc17815136860
• 5799nc17815136863

VPS 2000 G12 — many concurrent sessions

Specs: 8 vCPU, 16 GB RAM, 512 GB NVMe, traffic included. Around 19.25 €/month (verify on netcup.com).

When you are running the tunnel for a wider circle — dozens of simultaneous sessions, each duplicating packets across multiple resolvers — the bottleneck is packet processing per second, and eight vCPUs give you the parallel DNS workers to absorb it. This is the tier for a community relay rather than a personal escape hatch.

• 5800nc17802654091
• 5800nc17718015232
• 5800nc17718015233

RS 1000 G12 — dedicated cores when consistency matters

Specs: 4 dedicated AMD EPYC 9645 cores, 8 GB RAM, 256 GB NVMe, traffic included. Around 12.79 €/month (verify on netcup.com).

A DNS tunnel under real censorship pressure is a latency-sensitive, contention-sensitive workload — the difference between a stream that holds and one that stalls is often a few hundred milliseconds of scheduling delay. Dedicated EPYC cores remove the noisy-neighbour variable entirely, which is worth paying for if you are providing the tunnel to people who depend on it, not just experimenting.

• 5159nc17718015444
• 5159nc17718015440
• 5997nc17809735221

Which one should you pick? If you are setting up a tunnel for yourself, take the VPS 500 G12 — it is the cheapest box that does the job, and the job is not demanding. If you are putting it in front of a small group, step up to the VPS 1000 G12 for the extra cores that concurrent encryption needs. And if people are relying on this tunnel to stay online during an actual blackout, the RS 1000 G12 with dedicated cores removes the one variable — scheduling jitter under contention — that you cannot otherwise control. Shared web hosting is not an option here: this needs a daemon bound to port 53 and authority over a DNS zone, which no shared plan allows.

Conclusion

You now have a self-hosted DNS-tunneling VPN running on a Netcup VPS: a server authoritative for your subdomain on port 53, a client exposing a local SOCKS5 proxy, ChaCha20 between them, and a systemd service that comes back after a reboot. On the recommended VPS 500 G12, that is around 5.91 €/month — and your first month effectively comes down further with the €5-off-any-order coupon 36nc17718015545 applied at checkout.

Two things deserve an eye once you are running. First, watch your traffic graph rather than your CPU or RAM — DNS tunneling with packet duplication is bandwidth-dense, and while Netcup's included allowance is generous, a tunnel left wide open to others can move more than you expect. Second, keep a copy of encrypt_key.txt and your DNS delegation written down somewhere off the box; the binary reinstalls in one command, but a lost key and undocumented NS records turn a five-minute rebuild into an afternoon. Beyond that, this is a tool you stand up and forget until the day the rest of the internet stops working — which is exactly the day you will be glad it is already there.