Jede Domain, die Ihre Geräte nachschlagen, ist eine Zeile mit Zeitstempel in der Datei von jemand anderem — der Ihres ISPs oder der eines kostenlosen öffentlichen Resolvers. Sechs Schritte, um diese Datei auf eine Maschine zu verlagern, die Ihnen gehört: Unbound, das vom Root auflöst, AdGuard Home, das davor filtert, verschlüsseltes DNS auf einem echten Zertifikat, und Port 53, der dem Internet nie ausgesetzt ist. Die Maschine kostet $3.90 im Monat. Getestet unter Debian 12.
Variante
Rekursiv, nicht weiterleitend
Schließen
Port 53, bevor er sich öffnet
Auflösen
Unbound, validierend
Filtern
AdGuard Home, DoH, DoT
Erreichen
Zuerst der Tunnel, dann die Clients
Verifizieren
Lecks, DNSSEC, Uptime
Die Platte verschlüsseln, den Traffic tunneln, in Monero bezahlen, sich ohne E-Mail anmelden — und dann den Laptop einen Resolver fragen lassen, über den man nie nachgedacht hat, damit er jeden Hostnamen übersetzt, den er berührt, eine Abfrage nach der anderen, im Klartext, den ganzen Tag. Die Namensauflösung ist der Teil des Stacks, den man zuletzt härtet, und es ist der Teil, der die sauberste Aufzeichnung dessen erzeugt, was jemand tatsächlich tut.
Es lohnt sich, genau zu sein, was diese Aufzeichnung enthält, denn „DNS leakt Ihr Browsing" ist zugleich wahr und bequem. Ein Abfrageprotokoll ist eine Liste von Domainnamen mit Zeitstempeln, zugeordnet der IP-Adresse, die gefragt hat. Es sind nicht die Seiten, die Sie lesen, und meist nicht einmal die genaue URL. Es ist etwas Leiseres und, fürs Profiling, Besseres: die Form eines Lebens. Die Bank. Der Arbeitgeber. Die Dating-App, die alle vier Minuten anklopft. Die Gesundheitsseite, einmal um 02:00 Uhr besucht. Die drei Domains, die nur zusammen auftauchen, weil sie zum selben Messaging-Client gehören. Niemand braucht die Inhalte, wenn der Index so gut ist.
Vier Parteien können diesen Index halten, und Self-Hosting verlagert ihn von den ersten beiden zur vierten:
| Einrichtung | Wer jede Ihrer Abfragen sieht | Auf der Leitung sichtbar | Anonymitätsmenge |
|---|---|---|---|
| ISP-Resolver, Klartext (der Standard) | Ihr ISP, namentlich und mit Konto | Alles, für jeden auf dem Weg | Deren Abonnenten |
| Öffentlicher Resolver, verschlüsselt (DoH/DoT) | Dieses eine Unternehmen, gebunden an Ihre IP | Nichts außer dem Ziel | Millionen |
| Ihr eigener Resolver, der an einen Upstream weiterleitet | Der von Ihnen gewählte Upstream — unverändert | Nichts außer dem Ziel | Eins |
| Ihr eigener Resolver, rekursiv vom Root aus | Niemand — jede Zone sieht nur ihre eigenen Namen | Nichts außer dem Ziel | Eins, auf einer IP, die nicht Sie sind |
Zeile drei ist die Zeile, die Leute hereinlegt. Einen Resolver auf dem eigenen Server zu installieren und ihn dann alles an 1.1.1.1 weiterleiten zu lassen, ändert genau eine Sache: Ihre Abfragen kommen jetzt von einer anderen IP-Adresse bei Cloudflare an. Das Protokoll existiert weiterhin, es gehört weiterhin jemand anderem, und Sie haben sich im Austausch für nichts eine zu pflegende Maschine aufgeladen.
Die letzte Spalte ist der ehrliche Preis, und dieser Leitfaden kommt zweimal darauf zurück. Ein von einem Haushalt genutzter Resolver ist ein Resolver, dessen Abfragen unzweifelhaft dem Haushalt gehören. Was den Tausch lohnenswert macht, ist, dass die fragende IP ein gemieteter nordischer Server ist, hinter dem kein Ausweisdokument steht — kein Festnetzanschluss mit Abonnentennamen, und kein Hyperscaler-Konto mit hinterlegter Karte. Die Anonymitätsmenge schrumpft; die Verbindung zu einer Person ist es, die tatsächlich bricht.
Hinter dem Ausdruck „mein eigener DNS-Server" verbergen sich zwei völlig unterschiedliche Maschinen, und fast jedes Tutorial baut die falsche. Entscheiden Sie das, bevor Sie irgendetwas installieren, denn es ist der Unterschied zwischen einem Datenschutz-Werkzeug und einem Proxy für die Datenschutzrichtlinie von jemand anderem.
Ein Forwarder nimmt Ihre Abfrage entgegen und reicht sie an einen anderen Resolver weiter — typischerweise Cloudflare, Google, Quad9 oder Ihren ISP —, und cacht dann, was zurückkommt. Das ist einfach, das ist schnell, und es übergibt Ihren gesamten Abfragestrom an einen einzigen Dritten. Jede Anleitung, die mit „jetzt Ihren Upstream auf 1.1.1.1 setzen" endet, hat genau das gebaut.
Ein rekursiver Resolver erledigt die Arbeit selbst. Um mail.example.com zu finden, fragt er einen Root-Server, wer .com betreibt, fragt die .com-Server, wer example.com betreibt, und fragt dann example.coms eigene Nameserver nach dem Eintrag. Drei oder vier kurze Gespräche mit drei oder vier verschiedenen Betreibern, von denen keinem etwas über die anderen mitgeteilt wird. Mit eingeschalteter QNAME-Minimierung geht es noch weiter: Der Root wird nur nach .com gefragt, und die .com-Server nur nach example.com. Der vollständige Name wird genau einer Partei offenbart — derjenigen, die den Namen hostet und die Ihre Verbindung ohnehin dreißig Millisekunden später erhalten hätte.
| Eigenschaft | Unbound, rekursiv | Beliebiger Forwarder | AdGuard Home allein |
|---|---|---|---|
| Einzelne Partei sieht jede Abfrage | Nein | Ja | Ja — sein Upstream |
| DNSSEC lokal validiert | Ja | Vertraut dem Upstream | Vertraut dem Upstream |
| Blocklisten und geräteweise Regeln | Nur über lokale Zonen | Hängt vom Daemon ab | Ja, mit Weboberfläche |
| DoH-/DoT-Listener für Clients | DoT nativ, DoH über einen Proxy | Hängt vom Daemon ab | Beides, eingebaut |
| Kaltstart-Latenz | 3–4 Round Trips | 1 Round Trip | 1 Round Trip |
| Richtige Antwort | Die Datenschutz-Hälfte des Stacks | Nur als bewusster Fallback | Die Filter-Hälfte, davor |
Die beiden rechten Spalten sind keine Konkurrenten — sie sind die zwei Hälften desselben Aufbaus. AdGuard Home besitzt Port 53, wendet die Blocklisten an und terminiert die verschlüsselten Transporte; Unbound sitzt dahinter auf Loopback und übernimmt die Auflösung. Keine der beiden Hälften erledigt die Aufgabe der anderen gut, und die Kette benötigt insgesamt etwa hundert Megabyte RAM.
Wenn Sie nur eine Sache von dieser Seite mitnehmen, dann diese: Ein Resolver, der an einen öffentlichen DNS-Anbieter weiterleitet, hat Ihr DNS nicht privat gemacht. Er hat das Protokoll um einen Hop verschoben und Ihrer Wartungsliste einen Server hinzugefügt. Die Rekursion ist der ganze Sinn der Sache.
Bestellen Sie zuerst die Maschine. Im Panel: Order → VPS → Sentinel, Image Debian 12, in der Bastion, die den Geräten am nächsten ist, die ihn nutzen werden — Helsinki, Stockholm, Oslo oder Reykjavík. Für die Kontoeröffnung ist keine E-Mail-Adresse nötig, und die Rechnung wird in Monero, Bitcoin, Lightning oder jedem anderen unterstützten Asset beglichen, was hier mehr zählt als sonst: Der gesamte Wert eines persönlichen Resolvers beruht darauf, dass die fragende IP-Adresse nicht zu einem Namen zurückverfolgbar ist.
Gehen Sie dann die Härtungs-Checkliste für die erste Stunde durch — nur SSH-Schlüssel, kein Passwort-Login, unbeaufsichtigte Updates —, denn alles Folgende setzt eine Maschine voraus, die nicht bereits kompromittiert ist.
Ein rekursiver Resolver, der dem ganzen Internet antwortet, heißt offener Resolver, und internetweite Scanner finden ihn innerhalb von Stunden nach dem Öffnen des Ports. DNS läuft über UDP, UDP-Quelladressen sind trivial zu fälschen, und eine 60-Byte-Abfrage kann eine um ein Vielfaches größere Antwort erzeugen — ein offener Resolver ist also ein kostenloser Verstärker für einen Denial-of-Service-Angriff gegen Dritte. Die darauffolgende Abfolge ist immer dieselbe: Der Traffic beginnt, die Missbrauchsmeldungen treffen ein, und die IP wird per Null-Routing lahmgelegt. Es ist die mit Abstand häufigste Art, wie ein erster DNS-Server endet. Zwei Regeln verhindern das vollständig: in der Resolver-Konfiguration standardmäßig ablehnen, und in der Firewall niemals 53/udp von 0.0.0.0/0 erlauben.
Die Firewall kommt daher zuerst, solange noch nichts lauscht. Die folgenden Regeln setzen einen WireGuard-Tunnel auf 10.8.0.0/24 voraus — falls Sie noch keinen gebaut haben: Der am Ende dieser Seite verlinkte WireGuard-Leitfaden ist ein Umweg von fünfzehn Minuten, und er ist der Transport, mit dem sich dieses gesamte Design am wohlsten fühlt.
ufw default deny incoming
ufw allow 22/tcp # or your moved SSH port
ufw allow 51820/udp # WireGuard
ufw allow in on wg0 to any port 53 proto udp
ufw allow in on wg0 to any port 53 proto tcp
ufw enable
# DNS is NOT opened to the world. Confirm it:
ufw status numbered | grep 53
Beachten Sie, was absichtlich fehlt: Es gibt keine Regel, die 53 auf dem öffentlichen Interface öffnet. Port 53 existiert nur auf wg0 und auf Loopback. Falls Sie später DNS-over-TLS oder DNS-over-HTTPS hinzufügen, sind das TCP 853 und TCP 443, sie werden durch ein Zertifikat authentifiziert und bekommen in Schritt 05 ihre eigenen Regeln — der Klartext-UDP-Port bleibt unabhängig davon geschlossen.
Jetzt den Port freiräumen. Unter Ubuntu — und unter jedem Debian, auf dem jemand es aktiviert hat — lauscht systemd-resolved bereits auf 127.0.0.53:53, und Unbound wird den Start mit einem Bind-Fehler verweigern, den Leute zwanzig Minuten lang falsch deuten. Prüfen Sie zuerst, deaktivieren Sie dann nur den Stub-Listener und behalten Sie systemd-resolved als lokales clientseitiges Interface bei:
ss -lunp 'sport = :53' # who owns UDP/53 right now?
mkdir -p /etc/systemd/resolved.conf.d
cat > /etc/systemd/resolved.conf.d/no-stub.conf <<'EOF'
[Resolve]
DNSStubListener=no
EOF
systemctl restart systemd-resolved
ss -lunp 'sport = :53' # should now be empty
Auf einem sauberen Debian 12 gibt der erste Befehl nichts aus, und es gibt nichts zu tun. Führen Sie ihn trotzdem aus — er dauert eine Sekunde, und die Alternative ist, „address already in use" gegen einen Dienst zu diagnostizieren, von dem Sie nicht wussten, dass er läuft.
Unbound ist ein validierender, rekursiver, cachender Resolver von NLnet Labs. Er ist überall paketiert, ein großer Teil des Internets betreibt ihn bereits, und von Haus aus rekursiert er — man muss sich extra Mühe geben, um ihn in einen Forwarder zu verwandeln. Installieren Sie ihn zusammen mit dem Root-Hints-Paket, damit er weiß, wo die Root-Server sind, ohne irgendwo eine Liste abzurufen:
apt update && apt install -y unbound dns-root-data
unbound -V | head -2
Das Paket dns-root-data installiert die Root Hints unter /usr/share/dns/root.hints und den DNSSEC-Root-Trust-Anchor unter /usr/share/dns/root.key und hält beide über den normalen Paketkanal aktuell. Das ist der langweilige, korrekte Weg, sie zu bekommen; root.hints per Cronjob von einer URL herunterzuladen, ist der Weg, der irgendwann stillschweigend scheitert.
/etc/unbound/unbound.conf.d/nb-resolver.conf
server:
# ---- Who may ask. Deny first, allow narrowly.
interface: 127.0.0.1@5335
interface: 10.8.0.1
access-control: 0.0.0.0/0 refuse
access-control: ::0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: 10.8.0.0/24 allow
# ---- Privacy of the recursion itself.
qname-minimisation: yes
qname-minimisation-strict: no
hide-identity: yes
hide-version: yes
rrset-roundrobin: yes
# ---- DNSSEC. The anchor is maintained by the dns-root-data package.
auto-trust-anchor-file: "/var/lib/unbound/root.key"
root-hints: "/usr/share/dns/root.hints"
harden-dnssec-stripped: yes
harden-glue: yes
harden-below-nxdomain: yes
harden-large-queries: yes
harden-short-bufsize: yes
aggressive-nsec: yes
val-clean-additional: yes
# ---- Do not be a reflector, even by accident.
refuse-any: yes
ratelimit: 1000
ip-ratelimit: 200
edns-buffer-size: 1232
# ---- Cache. This is where the 4 GB actually earns its keep.
msg-cache-size: 128m
rrset-cache-size: 256m
cache-min-ttl: 60
cache-max-ttl: 86400
prefetch: yes
prefetch-key: yes
serve-expired: yes
serve-expired-ttl: 3600
# ---- Never chase a name that has no business being on the internet.
private-address: 10.0.0.0/8
private-address: 172.16.0.0/12
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: fd00::/8
private-address: fe80::/10
num-threads: 2
so-reuseport: yes
verbosity: 0
logfile: ""
remote-control:
control-enable: yes
control-interface: /run/unbound.ctl
Vier dieser Zeilen leisten die eigentliche Arbeit und verdienen je einen Satz.
Beachten Sie die zwei Listener. Loopback auf Port 5335 ist das, was AdGuard Home im nächsten Schritt nutzen wird; 10.8.0.1 ist die Tunneladresse, damit Clients im VPN Unbound direkt abfragen können, falls Sie sich entscheiden, die Filterschicht zu überspringen. Falls Sie noch kein WireGuard betreiben, lassen Sie diese zweite Interface-Zeile vorerst weg — Unbound startet nicht mit einer Adresse, die auf der Maschine nicht existiert.
Starten Sie ihn und beweisen Sie, dass er funktioniert:
unbound-checkconf
systemctl restart unbound && systemctl enable unbound
apt install -y dnsutils
dig @127.0.0.1 -p 5335 nordbastion.com +short
# DNSSEC: the first must come back with the "ad" flag set,
# the second must FAIL — its signatures are deliberately broken.
dig @127.0.0.1 -p 5335 dnssec-tools.org +dnssec | grep -E 'flags:|status:'
dig @127.0.0.1 -p 5335 dnssec-failed.org | grep 'status:'
Das ad-Flag bei der ersten Antwort bedeutet, dass Unbound die Signaturkette vom Root bis zum Eintrag geprüft hat und sie hielt. SERVFAIL bei der zweiten bedeutet, dass die Validierung eine manipulierte Antwort verworfen hat, statt sie an Sie weiterzugeben. Liefert die zweite stattdessen eine Adresse, ist die Validierung nicht aktiv, und der Trust Anchor ist das Erste, was Sie sich ansehen sollten.
Dieser Schritt ist im strengen Sinn optional — Unbound allein ist bereits ein privater Resolver —, und trotzdem will ihn fast jeder. AdGuard Home liefert Ihnen Blocklisten, clientweise Richtlinien, ein lesbares Abfrageprotokoll beim Debuggen und, am nützlichsten, native DNS-over-TLS- und DNS-over-HTTPS-Listener, damit Telefone und Browser Ihren Resolver auch aus Netzwerken erreichen können, in denen ein VPN nicht praktikabel ist.
Der Aufbau ist eine Kette, und die Ports richtig zu setzen ist der ganze Trick: AdGuard Home besitzt 53 und ist den Clients zugewandt, Unbound sitzt auf 127.0.0.1:5335 und ist dem Internet zugewandt. Sonst lauscht nichts auf der Maschine auf 53.
curl -fsSL https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v
# Web interface: http://<vps>:3000 — reach it over the SSH tunnel below,
# never by opening 3000 to the internet.
ssh -N -L 3000:127.0.0.1:3000 root@<vps>
Führen Sie den Ersteinrichtungs-Assistenten über diesen Tunnel durch. Setzen Sie den Admin-Listener auf 127.0.0.1 oder auf die Tunneladresse, niemals auf 0.0.0.0, und vergeben Sie ein langes Passwort — dieses Interface kann jeden Namen umschreiben, den Ihr Netzwerk auflöst, was es so sensibel macht wie den Resolver selbst.
Setzen Sie dann genau einen Upstream: unter Settings → DNS settings, löschen Sie die Standardliste und tragen Sie Ihre Unbound-Instanz ein. Eine Zeile, sonst nichts. Bleibt ein öffentlicher Resolver in diesem Feld stehen, ist alles aus Schritt 01 wieder rückgängig gemacht.
127.0.0.1:5335
Lassen Sie „Parallel requests" ausgeschaltet — mit einem einzigen Upstream verdoppelt das nur den Traffic, sonst nichts — und schalten Sie „Use private reverse DNS resolvers" aus, sofern Sie nicht tatsächlich eine interne Zone betreiben. Setzen Sie die Bootstrap-Server auf etwas, dem Sie vertrauen; sie werden nur genutzt, um die Hostnamen von Upstream-Servern aufzulösen, und bei einem reinen IP-Upstream werden sie überhaupt nie konsultiert.
Blocklisten: eng anfangen. Der Instinkt sagt, alles auf der Listenseite zu aktivieren und sich am Zähler zu erfreuen. Widerstehen Sie dem. Jede Liste ist eine Sammlung von Ermessensentscheidungen, die jemand anderes darüber getroffen hat, was Ihre Geräte erreichen dürfen, und die Ausfälle sind leise und verwirrend — eine halb geladene Seite, ein Button, der nichts tut, eine Bank-App, die sich weigert zu öffnen. Beginnen Sie mit dem AdGuard-Standardfilter oder mit einem einzigen gut gepflegten Aggregat wie OISD, leben Sie zwei Wochen damit, und fügen Sie erst dann weitere hinzu. Führen Sie eine Positivliste und nutzen Sie sie ohne schlechtes Gewissen.
Sie haben gerade eine Maschine gebaut, deren Zweck es ist, jemand anderen davon abzuhalten, eine Liste jedes Namens zu führen, den Ihre Geräte auflösen — und das Erste, was AdGuard Home tut, ist, genau diese Liste zu führen, standardmäßig aktiviert, neunzig Tage lang. Sie ist wirklich nützlich, während Sie Blocklisten feinabstimmen, und sie ist die mit Abstand sensibelste Datei auf dem Server. Entscheiden Sie bewusst: 24 Stunden reichen, um „was hat dieses Gerät gerade angefragt?" zu beantworten, null ist die ehrliche Einstellung, sobald die Feinabstimmung fertig ist, und neunzig Tage sind eine Entscheidung, die niemand treffen sollte, indem er einfach einen Standardwert stehen lässt. Settings → General → Query log, und stellen Sie dort gleich die Statistik-Aufbewahrung ein.
Richten Sie die Firewall auf den neuen Aufbau aus — AdGuard Home besitzt jetzt Port 53 auf dem Tunnel-Interface, und Unbound ist nur noch über Loopback erreichbar. Am öffentlichen Interface ändert sich nichts: Dort liegt weiterhin überhaupt kein DNS.
Ein Resolver, den niemand erreichen kann, ist nutzlos, und ein Resolver, den jeder erreichen kann, ist der Fehlerfall aus Schritt 02. Es gibt genau zwei gute Antworten, und die meisten Leute betreiben am Ende beide — den Tunnel zu Hause und auf dem Laptop, verschlüsseltes DNS auf dem Telefon und in Netzwerken, in denen UDP gefiltert wird.
Option A — über WireGuard. Die bessere der beiden, und der Grund, warum dieser Leitfaden immer wieder auf den WireGuard-Leitfaden verweist. Port 53 bleibt für das Internet unsichtbar, die Abfrage selbst durchquert in keiner Form ein nicht vertrauenswürdiges Netzwerk, und es gibt kein Zertifikat zu erneuern. Ist der VPS bereits Ihr VPN-Exit, ist das eine Zeile in der Konfiguration jedes Peers:
# On the client, in the [Interface] section of the peer config:
DNS = 10.8.0.1
Eine Feinheit, die Leute ärgert: Unter Linux setzt wg-quick diese Adresse über resolvconf oder systemd-resolved, und ist keines von beiden installiert, tut es stillschweigend nichts, während der Tunnel trotzdem einwandfrei hochkommt. Prüfen Sie mit resolvectl status oder indem Sie nach dem Hochfahren des Tunnels /etc/resolv.conf lesen — ein funktionierender Tunnel, bei dem noch der alte Resolver konfiguriert ist, ist genau das Leck, um das es bei dieser ganzen Übung geht.
Option B — DNS-over-TLS und DNS-over-HTTPS. Nötig, wenn das Gerät nicht immer im Tunnel sein kann. Beide werden durch ein Zertifikat authentifiziert, was einen Hostnamen bedeutet: Richten Sie einen A-Record auf den VPS, und lassen Sie dann entweder AdGuard Home das Zertifikat direkt halten oder stellen Sie es hinter einen Reverse-Proxy, der TLS bereits für Sie terminiert. Die Listener sind 853/tcp für DoT und 443/tcp für DoH.
ufw allow 853/tcp # DNS-over-TLS
ufw allow 443/tcp # DNS-over-HTTPS
# 53/udp is still NOT open on the public interface. It never will be.
ufw status
Geben Sie dem DoH-Endpunkt einen nicht erratbaren Pfad — AdGuard Home lässt Sie ihn unter /dns-query/<random> ausliefern, und ein unterschiedlicher Pfad pro Person bedeutet, dass der Zugriff einzeln widerrufen werden kann, ohne für alle anderen etwas zu rotieren. Das ist keine Authentifizierung im starken Sinn, aber es bewahrt einen öffentlichen Listener davor, ein offener Resolver mit ein paar Extraschritten zu sein.
| Client | Wo die Einstellung liegt | Welchen Transport es spricht |
|---|---|---|
| Android 9 und neuer | Einstellungen → Netzwerk → Privates DNS → Hostname | Nur DNS-over-TLS |
| iOS und macOS | Ein signiertes .mobileconfig-DNS-Profil | DoH oder DoT, systemweit |
| Windows 11 | Einstellungen → Netzwerk → DNS-Serverzuweisung | DoH, pro Adapter |
| Firefox | Einstellungen → Datenschutz → DNS over HTTPS → Benutzerdefiniert | DoH, nur Browser |
| Router (gesamtes Netzwerk) | WAN-DNS, oder DHCP-Option 6 | Reines DNS — also tunneln |
Die Router-Zeile ist die, über die man nachdenken sollte. Den Resolver per DHCP zu verteilen, deckt auf einen Schlag jedes Gerät im Haus ab, auch die ohne Einstellungsbildschirm — aber der Hop vom Router zum VPS ist dann reines DNS über das offene Internet, genau das, was Sie eigentlich verhindern wollten. Betreiben Sie den Tunnel auf dem Router selbst, oder akzeptieren Sie, dass die letzte Meile unverschlüsselt bleibt, und lassen Sie die Rekursion den Gewinn sein.
Eine letzte Konfiguration, die man kennen sollte: Ein Browser mit aktiviertem DNS-over-HTTPS nutzt seinen eigenen Resolver und ignoriert die Systemeinstellung stillschweigend, Tunnel hin oder her. Firefox und Chrome liefern das in manchen Regionen beide standardmäßig aktiviert aus. Richten Sie entweder auch den Browser auf Ihren Endpunkt aus, oder schalten Sie sein DoH aus, damit er dem Betriebssystem folgt.
1. Ist er für das Internet offen? Führen Sie das von einer Maschine aus, die nicht im Tunnel ist — ein Telefon mit Mobilfunkdaten, ein anderer VPS, irgendetwas. Ein Timeout ist die korrekte und wünschenswerte Antwort. Eine tatsächliche Antwort bedeutet, dass auch jeder Scanner im Internet ihn finden wird, und Sie sollten sofort zu Schritt 02 zurückkehren.
dig @<public-ip-of-vps> +timeout=3 example.com
# Expected: ";; connection timed out; no servers could be reached"
2. Nutzt das Gerät ihn wirklich? Das ist die Prüfung, die am häufigsten scheitert, und der Ausfall ist unsichtbar: Der Tunnel steht, die Einstellung sieht richtig aus, und das Betriebssystem fragt immer noch den Resolver, den das Café ihm per DHCP mitgegeben hat. Fragen Sie den Resolver selbst, für wen er Sie hält, und bestätigen Sie es dann von der anderen Seite.
# On the client — which resolver is the system actually using?
resolvectl status | grep -A2 'Current DNS' # Linux
scutil --dns | grep nameserver # macOS
# On the server — does the query actually arrive?
tail -f /var/log/syslog | grep -i unbound &
unbound-control stats_noreset | grep total.num.queries
Laden Sie dann eine der öffentlichen DNS-Leak-Testseiten auf dem Gerät und lesen Sie das Ergebnis. Nennt sie Ihren VPS-Anbieter, stimmt der Pfad. Nennt sie Ihren ISP oder einen großen öffentlichen Resolver, antwortet noch immer etwas oberhalb des Tunnels.
3. Ist die Validierung tatsächlich aktiv? Wiederholen Sie die beiden dig-Befehle aus Schritt 03, diesmal durch die gesamte Kette — Client, AdGuard Home, Unbound — statt direkt gegen Unbound. Ein Name mit defekter Signatur muss auch hier scheitern. Falls AdGuard Home irgendwo in seinen Einstellungen noch einen zweiten Upstream stehen hat, zeigt sich das genau hier.
4. Erfüllt der Cache seinen Zweck? Nach einem Tag normaler Nutzung sollte die Trefferquote irgendwo zwischen siebzig und neunzig Prozent liegen. Deutlich niedriger bedeutet meist, dass der Cache zu klein ist oder cache-min-ttl ignoriert wird, weil alles vorgelagert eine sehr kurze TTL hat; deutlich höher in einem stark genutzten Netzwerk ist ein erfreuliches Zeichen dafür, dass prefetch funktioniert.
unbound-control stats_noreset | grep -E 'total.num.(queries|cachehits)'
# hit rate = cachehits / queries
Und dann die zwei betrieblichen Entscheidungen. Erstens: was passiert, wenn diese Maschine neu startet. Jedes darauf zeigende Gerät verliert die Namensauflösung, was jeder im Haushalt als kaputtes Internet melden wird. Stellen Sie den Dienst so ein, dass er bei Fehlern neu startet und beim Booten startet, starten Sie den VPS dann einmal absichtlich neu und beobachten Sie, wie er zurückkommt. Zweitens: ein Fallback. Tragen Sie entweder einen öffentlichen Resolver als sekundären auf Ihren Clients ein und akzeptieren Sie, dass diese Abfragen während eines Ausfalls Ihre Kontrolle verlassen, oder betreiben Sie eine zweite Instanz auf einem zweiten VPS in einer anderen Bastion. Beides ist vertretbar. Die Frage um 23:00 Uhr an einem Sonntag zu entdecken, ist es nicht.
systemctl enable unbound AdGuardHome
systemctl show unbound -p Restart -p RestartUSec
reboot # then, from a client: dig nordbastion.com +short
Ein privater Resolver ist eine echte Verbesserung, und er ist kein Tarnumhang. Wer ihn als solchen verkauft, verkauft etwas anderes. Hier ist die Liste dessen, was sichtbar bleibt, nachdem alles oben Beschriebene erledigt ist, denn die Form der verbleibenden Angriffsfläche zu kennen, ist der Unterschied zwischen einer Verteidigung und einer Wohlfühldecke.
Die Verbindung findet trotzdem statt. Eine Millisekunde nach der Abfrage öffnet Ihr Gerät eine TCP-Verbindung zu der Adresse, die es gerade erfahren hat. Jeder, der Ihre Leitung beobachtet, sieht diese Adresse. Bei einer Seite mit eigener IP ist die Adresse die Seite. Verschlüsseltes DNS entfernt die Frage; es entfernt nicht die Antwort.
Der TLS-Handshake nennt die Seite meist beim Namen. Server Name Indication wird am Anfang fast jeder HTTPS-Verbindung im Klartext gesendet, sodass ein passiver Beobachter den Hostnamen ohnehin liest. Encrypted Client Hello behebt das und ist ungleichmäßig verbreitet — wo sowohl Browser als auch Seite es unterstützen, ist der Name verborgen, wo nicht, ist er es nicht. Gehen Sie nicht davon aus, dass es aktiv ist.
Der Resolver-Betreiber sind jetzt Sie, und Sie sind eine einzelne Person. Jeder autoritative Server, mit dem Ihr Resolver spricht, sieht eine einzelne IP-Adresse, die nach seiner Zone fragt. Über viele Zonen hinweg hat diese IP ein unverwechselbares Muster, und das Muster ist ein Haushalt. Das ist der Anonymitätsmengen-Preis aus dem ersten Kapitel, und das Einzige, was ihn abschwächt, ist, dass die IP nicht zu einem Namen zurückverfolgbar ist — ein KYC-freier, mit Krypto bezahlter VPS — und, im Idealfall, dieselbe IP zu sein, aus der Ihr Traffic ohnehin schon austritt.
Der Provider kann die Pakete sehen, wie immer. Der VPS läuft auf der Hardware von jemandem, in dessen Rechenzentrum. NordBastion untersucht den Kundenverkehr nicht, und der Transparenzbericht und die Warrant Canary beschreiben, was passieren würde, wenn man gefragt würde — aber die ehrliche architektonische Aussage ist, dass eine gemietete Maschine eine Maschine ist, die jemand anderes physisch erreichen kann. Was Self-Hosting ändert, ist, dass es kein Abfrageprotokoll auf Produktebene gibt, keine Analytics-Pipeline und keine Datenschutzrichtlinie, die geändert werden kann; es gibt nur einen Prozess, der einen Cache im RAM hält, von Ihnen konfiguriert, in einer Jurisdiktion, die Sie bewusst gewählt haben.
Was Sie tatsächlich gekauft haben, genau genommen: Die mit Abstand reichhaltigste und billigste Quelle von Verhaltensdaten über Sie wird nicht mehr von einer Partei gesammelt, deren Geschäftsmodell genau darin besteht, sie zu sammeln. Das ist eine eng gefasste Behauptung, und es ist eine wahre. Nichts auf dieser Seite ersetzt Tor, wenn das Bedrohungsmodell Tor verlangt — und dafür ist der Onion-Service-Leitfaden weiter unten die ehrliche nächste Lektüre.
| Stufe | Monatlich | Ressourcen | Was sie komfortabel stemmt |
|---|---|---|---|
| Sentinel | $3.90 | 2 vCPU · 4 GB · 120 GB | Resolver + WireGuard für einen Haushalt. Die richtige Antwort. |
| Garrison | $7.90 | 4 vCPU · 8 GB · 240 GB | Dasselbe, plus ein Vaultwarden, ein SearXNG und ein Backup-Ziel |
| Ravelin | $16.90 | 8 vCPU · 16 GB · 480 GB | Ein kleines Team, fünfundzwanzig Tunnel-Peers, weitere Dienste daneben |
| Ein zweiter Sentinel | $3.90 | In einer anderen Bastion | Der Fallback-Resolver, damit ein Ausfall kein Internetausfall ist |
Nichts in dieser Tabelle ist wegen DNS gewählt. Ein Resolver für dreißig Geräte nutzt einige hundert Megabyte Cache und einen Bruchteil eines Kerns und bewegt einige hundert Megabyte Traffic im Monat. Wählen Sie die Stufe nach den WireGuard-Peers, den anderen Diensten und der Festplatte — dann läuft der Resolver kostenlos mit.
Eine Firewall-Regel zu viel, oder eine access-control-Zeile, die auf allow stehen geblieben ist. Scanner finden den Port innerhalb von Stunden, der Verstärkungs-Traffic beginnt, die Missbrauchsmeldung trifft ein, die IP verstummt. Standardmäßig ablehnen, nur den Tunnel erlauben, und von außerhalb des Netzwerks testen.
AdGuard Home installiert, Upstream auf der Standardliste belassen, alles läuft wunderbar — und das Abfrageprotokoll sammelt sich weiterhin bei einem Unternehmen an, dessen Name im Einstellungsfeld steht. Setzen Sie einen Upstream, und machen Sie ihn zu Ihrem Unbound.
wg-quick konnte die DNS-Einstellung nicht durchsetzen, weil resolvconf nicht installiert ist, oder ein Browser macht sein eigenes DNS-over-HTTPS. Alles sieht korrekt aus, und jede Abfrage geht weiterhin an das Netzwerk, in dem Sie gerade sitzen. Prüfen Sie es von der Seite des Resolvers, nicht vom Einstellungsbildschirm des Clients.
Nichts kündigt sich als DNS-Fehler an — eine Seite lädt nur halb, ein Button tut nichts. Sechs aggressive Listen, die gleich am ersten Tag aktiviert wurden, machen das unauffindbar. Beginnen Sie mit einer, ergänzen Sie langsam, führen Sie eine Positivliste, und behalten Sie genug Abfrageprotokoll, um die Frage zu beantworten.
Der ganze Aufbau existiert, um zu verhindern, dass jemand diese Liste führt, und die Filterschicht führt sie von Haus aus, auf der Festplatte, drei Monate lang. Stellen Sie die Aufbewahrung bewusst ein — 24 Stunden während der Feinabstimmung, danach null — und denken Sie daran, dass das jeden im Netzwerk betrifft, nicht nur Sie.
Ein Resolver ist Infrastruktur, sobald andere Menschen sich auf ihn verlassen. Aktivieren Sie beide Dienste beim Booten, setzen Sie Restart=on-failure, starten Sie einmal absichtlich neu, um es zu beweisen, und entscheiden Sie den Fallback, bevor Sie ihn brauchen, statt währenddessen.
Elf Fragen, die beim Bauen aufkommen — darunter die beiden, die entscheiden, ob es sich überhaupt lohnt, das zu bauen.
Es ist anders, und zwar auf die Weise besser, die am meisten zählt — aber die ehrliche Antwort hat zwei Hälften. Was Sie gewinnen: Bei einem rekursiven Resolver sieht niemand jemals Ihren vollständigen Abfragestrom. Die Root-Server erfahren, dass jemand nach .com gefragt hat, die .com-Server erfahren, dass jemand nach example.com gefragt hat, und nur der Betreiber von example.com erfährt den vollständigen Namen — und keiner von ihnen sieht die nächsten tausend Namen, die Sie nachschlagen. Ein öffentlicher Resolver dagegen sieht jede einzelne Abfrage, der Reihe nach, mit Zeitstempel, für immer, und seine Datenschutzrichtlinie ist das Einzige, was zwischen dieser Liste und jemand anderem steht. Was Sie verlieren: Ein persönlicher Resolver hat eine Anonymitätsmenge von eins. Abfragen, die einen großen öffentlichen Resolver verlassen, vermischen sich mit denen von Millionen anderer Menschen; Abfragen, die Ihren verlassen, sind unzweifelhaft Ihre. Dieser Tausch lohnt sich, wenn die IP-Adresse des Resolvers nicht mit Ihrer Identität verknüpft ist — genau das liefert Ihnen ein KYC-freier, mit Krypto bezahlter VPS, und genau das liefert ein Hyperscaler mit Ihrer hinterlegten Karte nicht. Stellen Sie den Resolver hinter denselben VPS, aus dem Ihr VPN ohnehin austritt, und die Anonymitätsmenge schrumpft überhaupt nicht, weil diese IP bereits Ihr Browsing erledigt hat.
Beim ersten Nachschlagen eines Namens minimal langsamer, bei jeder Wiederholung merklich schneller, und unter dem Strich etwa ausgeglichen. Ein Resolver, der kalt startet, muss die Delegationskette durchlaufen — Root, TLD, autoritativ —, also drei oder vier Round Trips statt des einen Round Trips zu einem öffentlichen Resolver, der die Antwort bereits aus der Abfrage von jemand anderem im Cache hatte. Sobald Ihr Cache warm ist, was in einem Haushalt etwa einen Tag dauert, werden die gängigen Namen aus dem RAM in deutlich unter einer Millisekunde bedient, und Sie liegen vorn. Schalten Sie prefetch ein, damit populäre Einträge aufgefrischt werden, bevor sie ablaufen, dann verschwindet der Kaltstart-Fall größtenteils. Der einzige Ort, an dem Sie tatsächlich Leistung verlieren können, ist die CDN-Geolokalisierung: Große öffentliche Resolver geben eine gekürzte Version Ihres Netzwerkstandorts an den autoritativen Server weiter (EDNS Client Subnet), damit das CDN einen nahegelegenen Edge-Server wählen kann. Unbound sendet das absichtlich nicht. Sitzt Ihr Resolver in derselben Region wie Sie, ändert das nichts Messbares. Steht der Resolver in Reykjavík und Sie sitzen in Singapur, liefern manche CDNs Ihnen einen europäischen Edge-Server, und das werden Sie spüren.
Nur für verschlüsselten Transport. Reines DNS über einen WireGuard-Tunnel braucht keine Domain, kein Zertifikat und überhaupt keine öffentliche Angriffsfläche — der Resolver lauscht auf einer privaten Adresse wie 10.8.0.1 und antwortet nur Peers im Tunnel. Diese Konfiguration ist zugleich die einfachste und die privateste in diesem Leitfaden. Eine Domain brauchen Sie in dem Moment, in dem Sie DNS-over-TLS oder DNS-over-HTTPS wollen, denn beide werden durch ein Zertifikat authentifiziert, und ein Zertifikat wird für einen Namen ausgestellt. Das ist die Konfiguration der Wahl, wenn Geräte nicht immer im VPN sein können — ein Arbeitslaptop, ein Telefon in einem Netzwerk, das UDP blockiert, ein Familienmitglied, das keinen Tunnel pflegen wird. Falls Sie eine registrieren, tun Sie das dort, wo nicht dieselbe Identität verlangt wird, auf die Sie anderswo geachtet haben, und lassen Sie die WHOIS-Privatsphäre aktiviert.
Sie lösen unterschiedliche Probleme, und die Paarung ist nicht redundant. Unbound ist der Resolver: Er durchläuft das DNS vom Root aus, validiert DNSSEC-Signaturen und cacht die Ergebnisse. AdGuard Home ist überhaupt kein Resolver — es ist ein vorgeschaltetes Filter-Frontend mit Weboberfläche und verschlüsselten Listenern, das alles, was es nicht blockiert, an einen Upstream weiterleitet. Betreiben Sie AdGuard Home allein, ist sein Upstream ein öffentlicher Resolver, und Ihr gesamter Abfragestrom landet wieder im Protokoll von jemand anderem. Betreiben Sie Unbound allein, erhalten Sie einen wirklich privaten Resolver ohne Blocklisten, ohne geräteweise Regeln und ohne Oberfläche. Verkettet — AdGuard auf 53, Unbound auf 127.0.0.1:5335 als einzigem Upstream — erhalten Sie Filterung und verschlüsselten Transport vor einem Resolver, der vom Root aus antwortet. Wenn Sie die kleinstmögliche Angriffsfläche wollen und Werbeblocker egal sind, ist Unbound allein eine vollkommen respektable Antwort, und es ist die Hälfte des Stacks, die den Datenschutz tatsächlich liefert.
Ein offener Resolver ist ein rekursiver Resolver, der Abfragen von jeder beliebigen Quelladresse im Internet beantwortet. Das ist gravierend, weil DNS über UDP läuft, UDP-Quelladressen sich trivial fälschen lassen und eine kleine Abfrage eine große Antwort erzeugen kann. Ein Angreifer schickt Ihrem Server eine 60-Byte-Abfrage mit der gefälschten Adresse eines Opfers als Absender; Ihr Server schickt dem Opfer brav eine um ein Vielfaches größere Antwort. Multiplizieren Sie das mit Tausenden offener Resolver, und es wird ein Reflection-and-Amplification-DDoS, und Ihr Server ist eine der Waffen. In der Praxis läuft die Abfolge schnell und vorhersehbar ab: internetweite Scanner finden einen neu geöffneten Port 53 innerhalb von Stunden, der Traffic beginnt, die Missbrauchsbeschwerden treffen ein, und der Provider legt die IP per Null-Routing lahm, um sein Netzwerk zu schützen. Das ist keine Hypothese und keine Seltenheit — es ist die mit Abstand häufigste Art, wie ein erster DNS-Server schlecht endet. Die Lösung kostet eine Firewall-Regel und eine Zeile Konfiguration: standardmäßig ablehnen, nur den eigenen Tunnel erlauben.
Es verbirgt die Abfrage, nicht den Besuch. DNS-over-TLS und DNS-over-HTTPS bedeuten, dass Ihr ISP nicht mehr eine Klartextfrage sieht, die example.com lautet. Was er weiterhin sieht, ist die Verbindung, die Sie eine Millisekunde später aufbauen: die Ziel-IP-Adresse und — sofern nicht beide Seiten Encrypted Client Hello unterstützen — den Servernamen im TLS-Handshake, im Klartext. Bei einer Seite mit eigener IP identifiziert die Adresse allein sie bereits; bei einer Seite hinter einem großen CDN ist die Adresse geteilt, und die SNI verrät es. Verschlüsseltes DNS erhöht also die Kosten passiver Protokollierung und entfernt die einfachste, billigste Überwachungsfläche, die es gibt, macht Ihr Browsing aber nicht unsichtbar. Wenn das Bedrohungsmodell Ihr ISP oder ein feindliches Netzwerk ist, das alles sieht, ist der Tunnel das richtige Werkzeug dafür — verschlüsseltes DNS schließt das Leck, das ein VPN allein noch haben kann, wenn das Betriebssystem außerhalb des Tunnels weiter den ISP-Resolver benutzt.
Viel kleiner, als man erwartet. DNS-Antworten sind einige hundert Byte groß, und die Arbeit pro Abfrage ist ein Hash-Lookup, sodass der Resolver für einen Haushalt oder ein kleines Team fast die ganze Zeit im Leerlauf ist. Ein Sentinel — 2 vCPU, 4 GB, $3.90 im Monat — bedient Dutzende Geräte, ohne dass die Load Average die Null verlässt, und der Großteil dieser 4 GB steht für Cache zur Verfügung, der einzigen Ressource, die die Erfahrung tatsächlich verbessert. Geben Sie Unbound ein paar Hundert Megabyte Message- und RRset-Cache, und Ihre Trefferquote liegt im Bereich von achtzig bis neunzig Prozent. Der Grund, größer zu dimensionieren, ist nie DNS: Es ist, dass dieselbe Maschine auch Ihren WireGuard-Tunnel terminiert, oder ein Vaultwarden betreibt, oder ein Backup-Repository vorhält. Bandbreite ist kein Thema — ein stark genutzter Haushalts-Resolver bewegt einige hundert Megabyte im Monat.
Jedes Gerät, das ihn nutzt, hört auf, Namen aufzulösen, was die Nutzer als „das Internet ist ausgefallen" beschreiben werden. Das sind die eigentlichen Betriebskosten von selbstgehostetem DNS, und das verdient eine Entscheidung statt einer Überraschung. Drei Absicherungen, in steigender Aufwandsreihenfolge. Konfigurieren Sie einen sekundären Resolver auf Ihren Clients — einen öffentlichen wie Quad9 oder dns0.eu — und akzeptieren Sie, dass diese Abfragen während eines Ausfalls Ihre Kontrolle verlassen; das sollten die meisten so machen. Oder betreiben Sie eine zweite Instanz auf einem zweiten VPS in einer anderen Bastion und tragen Sie beide ein, was alles im eigenen Haus hält, zum Preis einer zweiten Maschine für $3.90. Oder lassen Sie im Tunnel auf jedem Client einen winzigen lokalen Cache laufen, sodass ein kurzer Ausfall unsichtbar bleibt. Wofür auch immer Sie sich entscheiden: Setzen Sie Restart=on-failure auf die Unit, aktivieren Sie sie beim Boot, und testen Sie den Neustart einmal absichtlich — ein Resolver, der nicht von selbst zurückkommt, wird sich dafür immer den schlechtesten Moment aussuchen.
Ja, gelegentlich, und wie Sie damit umgehen, macht den Unterschied zwischen einem Setup, das hält, und einem, das nach zwei Wochen wieder herausgerissen wird. Blocklisten werden von Menschen gepflegt, die Ermessensentscheidungen treffen, und hin und wieder erwischt eine Entscheidung etwas, das Sie brauchen: den Betrugserkennungs-Endpunkt einer Bank, ein Sendungsverfolgungs-Widget, einen Login-Ablauf, der über eine Analytics-Domain umleitet. Der Ausfall ist verwirrend, weil er nicht wie DNS aussieht — die Seite lädt nur halb, oder ein Button tut nichts. Drei Gewohnheiten beheben das. Beginnen Sie mit einer konservativen Liste statt sechs aggressiven. Führen Sie eine Positivliste und ergänzen Sie sie ohne schlechtes Gewissen. Und lassen Sie das Abfrageprotokoll lange genug an, um die Frage „was hat dieses Gerät gerade angefragt, und was haben wir abgelehnt?" zu beantworten — genau in diesem Moment entdecken Sie, dass ein filternder Resolver selbst ein Gerät ist, das alles protokolliert, und dass seine Aufbewahrungseinstellung eine Datenschutzentscheidung ist, die Sie für jeden im Netzwerk treffen.
Ja, und das ist einer der besten Gründe, ihn zu bauen — eine einzige Maschine für $3.90 kann das DNS für einen ganzen Haushalt oder eine Handvoll Freunde aufräumen. Zwei Regeln machen es sicher. Erstens: Teilen Sie ihn über den Tunnel oder über einen authentifizierten, verschlüsselten Endpunkt, niemals indem Sie Port 53 der Welt öffnen; mit DNS-over-HTTPS können Sie jeder Person einen eigenen Pfad geben, sodass der Zugriff einzeln widerrufen werden kann, und AdGuard Home kann dann pro Client unterschiedlich filtern. Zweitens: Machen Sie sich klar, was Sie sich damit aufladen: Sie halten jetzt das Abfrageprotokoll von jedem, der ihn nutzt. Setzen Sie die Aufbewahrung auf null oder auf einen Tag, sagen Sie den Nutzern, wie die Einstellung lautet, und denken Sie daran: Wenn es je Ihre eigene Privatsphäre ist, die Sie schützen, ist ein von fünf Personen genutzter Resolver auch ein Resolver, bei dem sich jede einzelne Abfrage schwerer einer von ihnen zuordnen lässt.
Überhaupt nicht — ein privater, zugriffskontrollierter Resolver ist eine normale Arbeitslast, und die Acceptable-Use-Policy hat dazu nichts zu sagen. Was die Richtlinie interessiert, und was jedes seriöse Netzwerk interessiert, ist ein offener Resolver, der als Verstärkungsreflektor gegen Dritte missbraucht wird, weil der Angriffsverkehr unser Netzwerk verlässt und bei jemand anderem landet. Befolgen Sie Schritt 02, und das passiert nie: standardmäßig ablehnen, den Tunnel erlauben, den Rest per Rate-Limiting drosseln. Wenn Sie absichtlich einen öffentlichen Resolver als Dienst für andere betreiben wollen, ist das ein Gespräch, das sich lohnt, im Voraus zu führen statt nach der ersten Missbrauchsmeldung — die technischen Anforderungen (Response-Rate-Limiting, kein ANY, Monitoring) sind gut verstanden, und ein Resolver, der versehentlich offen läuft, ist das Problem, nicht einer, der absichtlich offen läuft.
Sentinel — 2 vCPU und 4 GB für $3.90 im Monat, in Helsinki, Stockholm, Oslo oder Reykjavík. Genug für den Resolver, den WireGuard-Tunnel, hinter dem er leben sollte, und was auch immer Sie sonst nicht mehr mieten wollen. Keine E-Mail bei der Anmeldung, kein Ausweisdokument, und kein Protokoll auf Produktebene von irgendetwas, das Sie nachschlagen.
Zuletzt überprüft · 2026-10-12 · Quellen · Unbound- und AdGuard-Home-Dokumentation, RFC 9156 (QNAME-Minimierung), RFC 7858 (DNS-over-TLS), RFC 8484 (DNS-over-HTTPS), systemd-resolved(8) · Rhythmus · jährlich
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Your own WireGuard tunnel — server config, peer keys, kill-switch.
A v3 .onion address that survives reboots and IP changes.
Ihr eigener Tailscale-Kontrollserver — ACLs, MagicDNS, Exit-Node, eigenes DERP.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Privates Hosting, im Norden gebaut.