BIND9: DNS-Anfragen mittels RPZ manipulieren!

Im Homelab möchte man Server häufig unter der eigenen Domain erreichen, ohne dafür eine zusätzliche Subdomain anzulegen oder überhaupt öffentlich verfügbare DNS-Einträge zu erstellen. Mit Response Policy Zones (RPZ) bietet BIND9 dafür eine praktische Lösung. Man kann damit aber noch deutlich mehr anstellen.

RPZ kannst du man nämlich als DNS-Firewall einsetzen, um beispielsweise Anfragen an bekannte Schadsoftware- oder Phishing-Domains zu blockieren. In diesem Artikel zeige ich dir allerdings, wie du RPZ mit BIND9 für eigene DNS-Overrides nutzt. So kannst du interne Hostnamen nutzen, ohne die öffentliche DNS-Zone bei deinem DNS-Anbieter anfassen zu müssen.

Systemkonfiguration & Rahmenbedinungen:

Response Policy einrichten:

Öffne auf deinem DNS-Server die Konfigurationsdatei /etc/named.conf.

Ergänze innerhalb des vorhandenen options-Blocks folgende Konfiguration:

response-policy {
    zone "customrecords";
};

RPZ-Zone anlegen:

Ergänze außerhalb des options-Blocks die Definition für die Policy-Zone:

zone "customrecords" {
    type master;
    file "/etc/named/zones/customrecords.zone";
    allow-query { localhost; };
    allow-transfer { none; };
};

Die Zone customrecords ist dabei keine echte Domain, die deine Clients auflösen sollen. Sie dient ausschließlich als Regelwerk für die Response Policy.

Lege anschließend die Zonendatei an:

mkdir -p /etc/named/zones
touch /etc/named/zones/customrecords.zone

Interne DNS-Einträge definieren:

In der Datei /etc/named/zones/customrecords.zone hinterlegst du die DNS-Namen, die intern überschrieben werden sollen.

Für unser Beispiel sieht die Zonendatei folgendermaßen aus:

$TTL 300

@ IN SOA localhost. root.localhost. (
    2026101201 ; Serial
    60         ; Refresh
    60         ; Retry
    60         ; Expire
    300        ; Negative Cache TTL
)

    IN NS localhost.

; Interne Hostnamen
docker-local.fabianscloud.de A 192.168.178.100

Möchtest du weitere interne Server ergänzen, kannst du einfach zusätzliche Einträge hinzufügen:

ceph-01.fabianscloud.de A 192.168.178.241
ceph-02.fabianscloud.de A 192.168.178.242
ceph-03.fabianscloud.de A 192.168.178.243

websrv-01.homelabtopia.com A 1.2.3.4
webserver.fabian-wuest.de A 1.2.4.5

Konfig prüfen & BIND9 neu laden:

Bevor du den DNS-Server neu startest, solltest du die Konfiguration überprüfen.

Zuerst kontrollierst du die Hauptkonfiguration:

named-checkconf

Danach prüfst du die RPZ-Zone:

named-checkzone customrecords /etc/named/zones/customrecords.zone

Wenn beide Prüfungen erfolgreich sind, kannst du die Konfiguration neu laden:

rndc reconfig

Alternativ kannst du den Dienst neu starten:

systemctl restart named

Prüfe anschließend den Status:

systemctl status named

Falls Probleme auftreten, helfen dir die Logs weiter:

journalctl -u named -f

DNS-Auflösung testen:

Jetzt kannst du mit dig überprüfen, ob die Hostnamen deiner internen Server korrekt aufgelöst werden. Alternativ kannst du unter Linux auch host verwenden, das auf vielen Distributionen bereits vorinstalliert ist. Unter Windows steht dir mit nslookup ebenfalls ein bekanntes Bordmittel zur Verfügung.

Interne Hostnamen prüfen:

dig @<DNS-IP> docker-local.fabianscloud.de

Die Antwort sollte die interne IP-Adresse enthalten:

docker-local.fabianscloud.de. 300 IN A 192.168.178.100

Andere DNS-Einträge abfragen:

Teste anschließend einen DNS-Namen, für den du keinen Override definiert hast:

dig @<DNS-IP> blog.fabianscloud.de

Alle anderen DNS-Anfragen laufen wie gewohnt über die öffentliche DNS-Infrastruktur. Voraussetzung ist natürlich, dass du die rekursive Namensauflösung auf deinem BIND9 entsprechend eingerichtet hast. So kannst du deine internen Dienste via Hostname erreichbar machen, ohne die reguläre Auflösung anderer Einträge deiner Domain zu beeinflussen.

Mein Fazit:

Mit Response Policy Zones (RPZ) kannst du DNS-Anfragen auf deinem BIND9-Server schnell und unkompliziert anpassen. Gerade im Homelab ist das praktisch, wenn du bereits eine eigene Domain nutzt und interne DNS-Einträge zentral verwalten möchtest.

So sparst du dir eine zusätzliche Subdomain wie internal.fabianscloud.de und musst die Einträge auch nicht in der Zonendatei deines autoritativen DNS-Servers pflegen. Ein weiterer Vorteil: Die internen Einträge bleiben auf deinem BIND9-Server und sind damit nicht öffentlich einsehbar. Allerdings ist BIND9 dafür nicht zwingend notwendig.

DNS-Dienste wie Unbound oder Pi-hole bieten ähnliche Möglichkeiten und lassen sich teilweise bequem über eine grafische Oberfläche konfigurieren. Wenn du BIND9 ohnehin in deinem Homelab betreibst, sind RPZ eine praktische Ergänzung. Für eine reine DNS-Lösung mit möglichst wenig Konfigurationsaufwand gibt es aber durchaus einfachere Alternativen.