Das Kernproblem, das Split-DNS löst
Ohne Split-DNS lösen interne Clients öffentliche Domainnamen über die öffentliche IP auf — und der Traffic verlässt das lokale Netz, geht durchs Internet zum Router zurück, nur um wieder im eigenen Netz zu landen (Hairpin-NAT). Das ist nicht nur langsamer, sondern bei manchen Router/Firewall-Kombinationen schlicht kaputt (Hairpin-NAT wird nicht von jeder Hardware unterstützt).
Ohne Split-DNS:
mail.firma.de -> öffentliche IP -> Router -> zurück ins eigene Netz (Hairpin)
Mit Split-DNS:
mail.firma.de -> intern aufgelöst -> direkte Verbindung, kein Umweg übers Internet
BIND9 Split-DNS mit Views
apt install -y bind9 bind9utils
cat > /etc/bind/named.conf.local << 'EOF'
acl intern {
192.168.0.0/16;
10.0.0.0/8;
localhost;
};
view "intern" {
match-clients { intern; };
recursion yes;
zone "firma.de" {
type master;
file "/etc/bind/zones/firma.de.intern";
};
};
view "extern" {
match-clients { any; };
recursion no;
zone "firma.de" {
type master;
file "/etc/bind/zones/firma.de.extern";
};
};
EOF
Die Reihenfolge der Views ist wichtig: BIND prüft von oben nach unten und nimmt die erste passende View. intern muss vor extern stehen, sonst greift match-clients { any; } immer zuerst und die interne View wird nie erreicht.
Interne Zone
cat > /etc/bind/zones/firma.de.intern << 'EOF'
$TTL 3600
@ IN SOA ns1.firma.de. admin.firma.de. (
2026070201 ; Serial (Format: JJJJMMTTnn)
3600 ; Refresh
900 ; Retry
1209600 ; Expire
86400 ) ; Negative TTL
@ IN NS ns1.firma.de.
ns1 IN A 192.168.10.10
@ IN A 192.168.20.10
www IN A 192.168.20.10
mail IN A 192.168.20.50
gitlab IN A 192.168.20.60
nas IN A 192.168.1.100
EOF
Die Serial-Nummer nach dem JJJJMMTTnn-Schema (Jahr-Monat-Tag-laufende Nummer) ist Konvention, keine Pflicht — wichtig ist nur, dass sie bei jeder Änderung strikt steigt, sonst übernehmen Secondary-Server die Änderung nicht.
Externe Zone
cat > /etc/bind/zones/firma.de.extern << 'EOF'
$TTL 3600
@ IN SOA ns1.firma.de. admin.firma.de. (
2026070201
3600
900
1209600
86400 )
@ IN NS ns1.firma.de.
ns1 IN A 203.0.113.1
@ IN A 203.0.113.10
www IN A 203.0.113.10
mail IN A 203.0.113.20
IN MX 10 mail.firma.de.
; Interne Dienste bewusst NICHT hier eintragen:
; gitlab, nas, etc. bleiben nach außen unsichtbar
EOF
named-checkconf
named-checkzone firma.de /etc/bind/zones/firma.de.intern
systemctl restart bind9
Das ist der eigentliche Sicherheitsgewinn von Split-DNS, nicht nur Performance: Interne Hostnamen wie gitlab oder nas tauchen in der externen Zone gar nicht erst auf — wer von außen DNS-Anfragen stellt, erfährt nichts über die interne Infrastruktur.
Einfachere Alternative: Pi-hole als lokaler Resolver
Für kleinere Umgebungen ohne dedizierten DNS-Admin ist BIND9 mit Views oft überdimensioniert. Pi-hole (oder AdGuard Home) als lokaler DNS-Server mit manuell gepflegten lokalen Einträgen erreicht dasselbe Ergebnis mit deutlich weniger Konfigurationsaufwand:
Pi-hole Admin -> Local DNS -> DNS Records
mail.firma.de -> 192.168.20.50
gitlab.firma.de -> 192.168.20.60
nas.firma.de -> 192.168.1.100
Upstream-DNS für alle anderen (externen) Domains:
Pi-hole -> Settings -> DNS -> Cloudflare/Quad9
Der Unterschied zu echtem Split-DNS: Pi-hole beantwortet nur die manuell hinterlegten Namen anders, alle anderen Anfragen gehen unverändert an den Upstream-Resolver. Für die allermeisten KMU-Szenarien (eine Handvoll interner Dienste) reicht das völlig aus.
FAQ
Warum nicht einfach /etc/hosts auf jedem Gerät pflegen?
Skaliert nicht — bei 50 Geräten sind das 50 Dateien, die bei jeder Änderung einzeln aktualisiert werden müssten. Kein zentraler Punkt, keine Automatisierung, hohe Fehleranfälligkeit.
Brauche ich zwingend zwei separate DNS-Server?
Nein — sowohl BIND9-Views als auch Pi-hole laufen als ein einziger Server-Prozess, der je nach anfragendem Client unterschiedlich antwortet.
Fazit
Split-DNS ist für jedes Unternehmen mit internen Diensten sinnvoll: schnellere interne Verbindungen ohne Hairpin-Umweg, und interne Hostnamen bleiben nach außen unsichtbar. Für kleinere Setups reicht Pi-hole, für komplexere Anforderungen mit mehreren Zonen und Secondary-Servern ist BIND9 der robustere Unterbau.
Ich richte DNS-Infrastruktur inklusive Split-DNS für Unternehmen in Heidelberg, Mannheim, Ludwigshafen und dem Rhein-Neckar-Kreis ein. Projekt anfragen.