Eigener DNS-Resolver: Filter, Protokolle, Kontrolle

Ein eigener DNS-Resolver bringt drei Dinge: Filterung nach eigenen Regeln, Protokolle darüber, welches Gerät wohin funkt, und Unabhängigkeit vom Auflöser des Anbieters. Er bringt auch ein Risiko, er ist ein Einzelpunkt, und wenn er steht, steht gefühlt das Internet.

Welches Programm#

	Unbound	AdGuard Home	Pi-hole
Rolle	vollwertiger Auflöser	Filter + Auflöser	Filter, meist mit Weiterleitung
Oberfläche	keine	ja, ausführlich	ja
Filterlisten	von Hand	eingebaut, viele	eingebaut, viele
Verschlüsselter Ausgang	DoT eingebaut	DoT/DoH/DoQ	über Zusatzprogramm
Statistik pro Gerät	nein	ja	ja

Für die meisten: AdGuard Home, Filter, Statistik und verschlüsselte Weiterleitung in einem. Wer keine Filterung will, sondern Unabhängigkeit: Unbound, der die Wurzelserver selbst befragt.

AdGuard Home im Container#

services:
  adguard:
    image: adguard/adguardhome:latest
    restart: unless-stopped
    ports:
      - "53:53/udp"
      - "53:53/tcp"
      - "127.0.0.1:3000:3000"     # Oberfläche nur lokal, Proxy davor
    volumes:
      - agh-conf:/opt/adguardhome/conf
      - agh-work:/opt/adguardhome/work
volumes: { agh-conf: , agh-work: }

Port 53 ist auf vielen Systemen schon belegt

Ubuntu und viele Container-Hosts betreiben systemd-resolved, das selbst auf 53 lauscht. Der Container startet dann mit „address already in use“, oder schlimmer: er startet, und Anfragen landen weiter beim alten Dienst.

ss -ulnp | grep :53
# systemd-resolved den Port abnehmen, aber als Stub-Auflöser behalten:
mkdir -p /etc/systemd/resolved.conf.d
printf "[Resolve]\nDNSStubListener=no\n" > /etc/systemd/resolved.conf.d/kein-stub.conf
systemctl restart systemd-resolved

Ausgang verschlüsseln#

Ohne weitere Einstellung fragt der Resolver im Klartext weiter, der Anbieter sieht dann jede Anfrage, und der Gewinn ist gering. In AdGuard Home werden die Weiterleitungsziele deshalb als DoT/DoH eingetragen:

tls://dns.example-anbieter.de
https://dns.example-anbieter.de/dns-query

Wer stattdessen selbst auflöst (Unbound), fragt die Wurzelserver direkt. Dann sieht kein Anbieter das gesammelte Bild, dafür sehen die einzelnen autoritativen Server die Anfragen, die sie ohnehin beantworten.

# Unbound, Minimalkonfiguration mit eigener Auflösung
apt install unbound
cat > /etc/unbound/unbound.conf.d/eigen.conf <<'CFG'
server:
  interface: 0.0.0.0
  access-control: 10.9.0.0/24 allow
  access-control: 192.168.178.0/24 allow
  hide-identity: yes
  hide-version: yes
  prefetch: yes
  cache-min-ttl: 60
CFG
systemctl restart unbound
dig @127.0.0.1 example.com +short

Der Fehler, der wehtut#

Ein Resolver ist ein Einzelpunkt

Wird im Router genau ein DNS-Server eingetragen und der fällt aus, geht im ganzen Netz nichts mehr und für die Bewohner sieht das aus wie „das Internet ist kaputt“. Ein zweiter Eintrag hilft nur bedingt: Viele Geräte fragen beide parallel und nehmen die erste Antwort, dann filtert der zweite eben nicht. Die ehrliche Wahl: zweiter eigener Resolver (Container auf einer anderen Maschine), oder bewusst ein öffentlicher als Fallback, im Wissen, dass die Filterung dann teilweise umgangen wird.

Praktisch bewährt: Der Resolver läuft nicht auf derselben Maschine, die man regelmäßig neu startet. Ein LXC-Container auf dem Hypervisor ist ein guter Ort (LXC oder VM), er startet in Sekunden und hängt nicht an Updates einer großen VM.

Ausrollen im Netz#

Nicht an jedem Gerät einzeln, sondern per DHCP:

# In der FritzBox: Heimnetz → Netzwerk → Netzwerkeinstellungen →
# IPv4-Konfiguration → „Lokaler DNS-Server"

Wichtig ist die IPv6-Seite: Geräte bekommen ihre DNS-Adresse oft zusätzlich per Router-Advertisement, und wenn dort noch der Anbieter steht, fragen sie an deinem Resolver vorbei. Was der Router von sich aus mitbringt und wo er aufhört, steht in FRITZ!OS 8.50 und dein Server.

# Gegenprobe von einem Gerät im Netz:
nslookup example.com
dig +short CHAOS TXT version.bind @<resolver-ip>   # antwortet dein Dienst?

Filtern, ohne sich das Netz zu zerlegen#

Mit wenigen Listen anfangen. Eine aggressive Sammlung blockiert Bezahlvorgänge, Sendungsverfolgung und Anmeldedienste und der Fehler ist nicht als DNS-Problem erkennbar.
Ausnahmen pflegen, statt Listen abzuschalten.
Protokolle sind personenbezogen. Wer im Haushalt sieht, welches Gerät wohin funkt? Aufbewahrungsdauer bewusst kurz halten.
Nicht als Sicherheitsmaßnahme verkaufen. DNS-Filter halten Werbung und bekannte Ziele auf, keinen gezielten Angriff.

Häufige Fragen#

Macht ein eigener Resolver das Internet schneller?#

Spürbar nur beim wiederholten Zugriff, weil der Zwischenspeicher lokal ist. Der erste Aufruf einer neuen Domain kann sogar langsamer sein, wenn selbst aufgelöst wird.

Kann ich ihn auf demselben VPS wie die Website betreiben?#

Technisch ja. Öffne Port 53 aber nicht ins Internet, ein offener Resolver wird binnen Stunden für Verstärkungsangriffe missbraucht. Zugriff nur aus dem eigenen Netz oder über den WireGuard-Tunnel.

Was ist mit DNS über HTTPS im Browser?#

Browser bringen eigene DoH-Einstellungen mit und fragen dann an deinem Resolver vorbei. Wer das nicht will, muss es in den Browsern abschalten, oder akzeptieren, dass die Filterung dort nicht greift.

Brauche ich DNSSEC?#

Unbound prüft es standardmäßig, und das ist gut. Bei Problemen mit einzelnen Domains ist es der erste Verdächtige, dig +cd (ohne Prüfung) zeigt, ob es daran liegt.

Wie viel Speicher braucht das?#

Wenig. Ein kleiner Container mit ein paar hundert Megabyte reicht; der Zwischenspeicher wächst mit der Zahl der Anfragen, nicht mit der Zahl der Geräte.

Kurz gesagt#

AdGuard Home für Filter und Statistik, Unbound für eigene Auflösung ohne Filter.
Port 53 ist oft von systemd-resolved belegt, erst nachsehen.
Ausgang verschlüsseln, sonst sieht der Anbieter weiterhin alles.
Zweiter Resolver oder bewusster Fallback, sonst ist ein Ausfall ein Netzausfall.
Port 53 nie offen ins Internet.