1. Warum DNS-Design mehr ist als "ein Server auf Port 53"
DNS ist in fast jeder Umgebung ein stiller Basisdienst. Fällt er aus oder antwortet inkonsistent, wirkt das
zuerst wie ein Problem von Webservern, LDAP, Mail oder Kubernetes. In Wahrheit hängen aber fast alle
Infrastrukturkomponenten an Namensauflösung, Caching und sauberer Zonenpflege.
Gutes DNS-Design bedeutet deshalb nicht nur "ein Resolver funktioniert", sondern:
klare Trennung der Rollen,
vorhersagbares Verhalten für interne und externe Namen,
sichere Defaults bei Ausfällen und Fehlkonfigurationen,
ein Betriebskonzept für Caches, Änderungen und Fehlersuche.
2. Rollen sauber trennen: rekursiv, autoritativ, lokal
Ein häufiger Fehler ist die Vermischung aller DNS-Funktionen auf einem einzelnen Dienst. Für kleine Umgebungen
mag das kurzfristig praktisch wirken, langfristig erschwert es aber Sicherheit und Fehlersuche.
Rekursiver Resolver: beantwortet Anfragen von Clients und beschafft externe Antworten selbst oder via Forwarding. Typische Werkzeuge: Unbound, BIND im Resolver-Modus, PowerDNS Recursor.
Autoritatives DNS: ist Quelle der Wahrheit für die eigene Zone. Typische Werkzeuge: BIND, Knot, NSD, PowerDNS Authoritative.
Lokale Komfortschicht: Pi-hole, AdGuard Home oder dnsmasq können Filterung, DHCP oder lokale Overrides liefern, sollten aber architektonisch klar verortet sein.
Faustregel: Ein öffentlich erreichbarer autoritativer Nameserver sollte nicht gleichzeitig als
offener Resolver für Clients dienen. Das reduziert Angriffsfläche, vereinfacht ACLs und verhindert viele
Missverständnisse rund um Split-Horizon-Setups.
3. Referenzarchitektur für Homelab und kleines Unternehmen
Für die meisten kleineren Umgebungen hat sich eine zweistufige Architektur bewährt:
Zwei rekursive Resolver im internen Netz, an die Clients per DHCP oder statischer Konfiguration zeigen.
Eine interne autoritative Zone für lokale Namen, zum Beispiel home.arpa oder eine Subdomain der eigenen öffentlichen Domain.
Beispiel:
dns01.internal.example und dns02.internal.example mit Unbound als Resolver,
ns01.internal.example als autoritativer Server für home.arpa,
optional Pi-hole vor Unbound, wenn Werbe- und Tracking-Filterung gewünscht ist.
Für interne Namensräume ist home.arpa technisch oft besser als .local, weil
.local im Umfeld von mDNS/Bonjour bereits besonders behandelt wird. Wer eine öffentliche Domain
besitzt, fährt häufig mit einer echten internen Subdomain wie int.example.com am saubersten.
4. Resolver mit Unbound aufbauen
Unbound ist für viele Self-Hosted-Umgebungen ein guter Standard: kleiner Footprint, DNSSEC-Validierung,
gutes Caching und übersichtliche Konfiguration. Minimal wichtig sind ACLs, Logging mit Augenmaß und ein klarer
Entscheid, ob der Resolver rekursiv bis zu den Root-Servern arbeitet oder an vertrauenswürdige Upstream-DNS
weiterleitet.
Ob Forwarding oder volle Rekursion besser ist, hängt vom Ziel ab:
Volle Rekursion: maximale Unabhängigkeit, aber etwas mehr Betriebsaufwand.
Forwarding mit DoT: einfacher, oft schneller eingerichtet, aber mit Abhängigkeit vom Upstream.
In Firmenumgebungen mit Active Directory kommt oft noch eine bedingte Weiterleitung hinzu, damit
AD-interne Zonen an die Domain Controller delegiert werden, während externe Namen weiter über Unbound laufen.
5. Split-DNS, interne Zonen und Namenskonventionen
Split-DNS bedeutet, dass derselbe Name je nach Herkunft der Anfrage unterschiedlich aufgelöst wird. Das ist
legitim, aber nur dann wartbar, wenn man es bewusst und sparsam einsetzt. Für viele Homelabs ist eine klare
Trennung in externe und interne Namen robuster als vollständiges Split-Horizon für die ganze Hauptdomain.
Gut wartbar:app.example.com extern, app.int.example.com intern.
Auch möglich: gleicher Name intern und extern, aber dann mit disziplinierter Zonenpflege.
Vermeiden: ungeplante Einzel-Overrides auf mehreren Servern gleichzeitig.
Eine kleine interne Zone mit BIND könnte so aussehen:
$TTL 300
@ IN SOA ns01.home.arpa. hostmaster.home.arpa. (
2026032101 ; serial
3600 ; refresh
900 ; retry
1209600 ; expire
300 ) ; minimum
IN NS ns01.home.arpa.
ns01 IN A 192.168.10.53
gw IN A 192.168.10.1
nas IN A 192.168.10.20
pve1 IN A 192.168.10.11
Entscheidend ist weniger das konkrete Produkt als die Prozessqualität: Zone serial sauber erhöhen, Änderungen
versionieren und TTLs bewusst wählen. Kurze TTLs sind praktisch bei Migrationen, langfristig aber kein Ersatz
für sauberes Change-Management.
6. Sicherheit, DNSSEC und Betriebsgrenzen
DNS wird oft als "nur Namensdienst" unterschätzt, ist aber ein attraktives Ziel für Missbrauch. Daher sollten
auch kleine Umgebungen einige klare Grenzen setzen:
Rekursive Resolver nur aus eigenen Netzen erreichbar machen.
Keine unnötigen Zonentransfers; AXFR nur explizit zwischen autoritativen Servern erlauben.
DNSSEC-Validierung auf Resolvern aktivieren, sofern der gewählte Dienst sie sauber unterstützt.
Logging so konfigurieren, dass Auffälligkeiten sichtbar bleiben, ohne die Platten mit Query-Logs zu fluten.
Für interne TLS-Zertifikate keine DNS-Namen verwenden, die nicht dauerhaft stabil gepflegt werden.
DNSSEC ist besonders hilfreich, wenn der Resolver externe Antworten validieren soll. Für interne Zonen ist
der Zusatznutzen kleiner, sofern die Zone nicht über unsichere Drittsysteme verteilt wird. In kleinen
Self-Hosted-Umgebungen lohnt sich oft mehr Energie in ACLs, Backups und Dokumentation als in maximaler
kryptografischer Komplexität.
7. Monitoring und Kapazitätsplanung
DNS fällt selten komplett aus. Häufiger werden Antworten langsam, Cache-Hit-Raten sinken, Forwarder sind nicht
erreichbar oder einzelne Zonen liefern inkonsistente Daten. Deshalb sollte Monitoring nicht nur "Port 53 offen"
prüfen.
Sinnvolle Signale sind:
Antwortzeit interner und externer Testabfragen,
Servfail-Rate und Timeout-Rate,
Cache-Hit- und Cache-Miss-Verhältnis,
Erreichbarkeit und Serial-Konsistenz autoritativer Zonen,
Ressourcenauslastung und Query-Volumen bei Resolvern.
Zwei Resolver sind im Alltag meist wichtiger als ein komplexes Anycast-Design. Erst wenn mehrere Standorte,
viele Clients oder höhere Verfügbarkeitsanforderungen dazukommen, lohnt sich zusätzlicher Aufwand.
8. Troubleshooting
Gute DNS-Fehlersuche trennt immer drei Ebenen: Client, Resolver und
autoritatives Ziel. Wer diese Ebenen vermischt, landet schnell bei reiner Raterei.
Resolver des Clients prüfen: zeigt das System wirklich auf den erwarteten DNS-Server?
Direkte Abfrage gegen den internen Resolver schicken.
Falls nötig, autoritative Nameserver direkt befragen.
Cache-Effekte und TTLs bewusst prüfen.
Letzte Änderungen an Zone, DHCP, Firewall oder Upstream nachvollziehen.
resolvectl status
dig @192.168.10.53 app.int.example.com
dig @ns01.int.example.com app.int.example.com
dig +trace example.org
tcpdump -ni any port 53
Typische Fehlerbilder:
Nur manche Clients haben das Problem: DHCP, lokaler Cache oder falscher Fallback-Resolver.
Interne Namen funktionieren, externe nicht: Upstream, Forwarding oder DNSSEC-Fehler.
Externe Namen funktionieren, interne nicht: Zone, Serial, ACL oder falsche View.
Nach Änderungen weiter alte Antworten: TTL und Client-Cache wurden nicht bedacht.
9. Zusammenfassung
Belastbares DNS entsteht durch klare Rollen, kleine saubere Zonen, restriktive Resolver und gutes Monitoring.
Die meisten Probleme lassen sich vermeiden, wenn rekursive und autoritative Aufgaben nicht unkontrolliert
vermischt werden und interne Namensräume bewusst geplant sind.
Für Homelab und kleine Firmen ist eine simple Architektur mit zwei Resolvern, einer internen autoritativen
Zone und sauber dokumentierten Overrides oft die beste Kombination aus Stabilität, Wartbarkeit und Sicherheit.