RPZ vs. Blacklist

1. Ausgangslage

Viele Teams sagen im Alltag "wir brauchen eine DNS Blacklist", meinen aber in Wirklichkeit zwei sehr unterschiedliche Dinge: entweder eine einfache Liste bekannter Domains oder eine kontrollierte Policy direkt im Resolver.

Genau hier trennt sich ein kleiner, pragmatischer Ansatz von einem belastbaren Betriebsmodell. Solange nur wenige Domains blockiert werden sollen, reicht eine klassische Sperrliste oft aus. Sobald aber mehrere Resolver, Ausnahmen, Redirects, unterschiedliche Kundengruppen oder strukturierte Feeds ins Spiel kommen, wird das Modell schnell zu grob.

2. Was mit Blacklist meist gemeint ist

Im einfachsten Fall ist eine Blacklist eine Sammlung bekannter Domains oder Feeds, die auf irgendeine Art gesperrt oder umgeleitet werden. Das ist schnell erklärt, leicht zu pflegen und für kleine Setups oft ausreichend.

3. Was RPZ technisch zusätzlich kann

RPZ steht für Response Policy Zone. Die Policy wird dabei als DNS Zone modelliert. Das ist der entscheidende Unterschied: Policy ist nicht einfach nur eine lose Textliste, sondern ein strukturiertes DNS Objekt, das sich mit typischen DNS Mechanismen pflegen und verteilen lässt.

• Policy direkt im rekursiven Resolver
• konsistente Verteilung über mehrere Resolver möglich
• nicht nur QNAME, sondern auch Client IP, Antwort IP, NSDNAME und NSIP als Trigger
• mehrere klar unterscheidbare Actions statt nur einfachem Blocken
• Ausnahmen, Redirects und kontrollierte Umschreibungen möglich

Gerade in grösseren oder sicherheitsrelevanten Umgebungen ist das oft der Punkt, an dem eine Blacklist Denke nicht mehr reicht. Dann geht es nicht mehr nur um "Name X blockieren", sondern um reproduzierbare Policy im Betrieb.

3.1 Betriebsmodell: RPZ versus klassische Blacklist Integration

Ein wesentlicher Unterschied zwischen RPZ und klassischen Blacklist Ansätzen liegt im Betriebsmodell. Viele klassische Blacklist Integrationen sind vendorabhängig und werden als Dateien, externe Feeds oder proprietäre Parser in den jeweiligen DNS Service eingebunden. Wie diese Daten verarbeitet werden, hängt deshalb stark vom verwendeten Produkt ab.

RPZ basiert dagegen auf dem DNS Modell selbst. Die Policy wird als Zone abgebildet und kann über normale DNS Mechanismen gepflegt und verteilt werden. In BIND lassen sich RPZ Zonen per Dynamic Update ändern, und Änderungen können per IXFR effizient an weitere Resolver übertragen werden. Das macht RPZ in BIND deutlich dynamischer und operativ sauberer als klassische dateibasierte Integrationen.

Genau das zeigt sich bei Infoblox in der Praxis. RPZ wird dort als verwaltetes Objektmodell geführt und ist Teil der Plattform, nicht nur ein loses Dateiimport Format. Gleichzeitig ist das Verhalten stärker produktgesteuert als bei einem klassischen BIND Setup. Je nach Änderung kann in NIOS ein Restart erforderlich sein, auch wenn RPZ grundsätzlich als natives Feature integriert ist.

Für rekursive Resolver ist das relevant, weil ein Restart immer ein operativer Eingriff ist. In Umgebungen, in denen ein Resolver bei Policy Änderungen neu initialisiert werden muss, ist das betrieblich unattraktiver als ein zonenbasierter Update Weg. Genau hier liegt die Stärke von RPZ besonders in BIND: Änderungen können als DNS Daten gepflegt und verteilt werden, ohne dass der Resolver jedes Mal über einen Neustart neu aufgebaut werden muss. Damit entfallen auch die Verzögerungen und der operative Nachteil, der durch Restarts und den anschliessenden Neuaufbau des Cache entsteht.

4. Die sechs RPZ Policy Actions

bad-domain.example    CNAME   .

tracking.example      CNAME   *.

ok.bad-domain.example CNAME   rpz-passthru.

silent-block.example  CNAME   rpz-drop.

udp-sensitive.example CNAME   rpz-tcp-only.

phishing.example      CNAME   blockpage.alpin-networks.ch.
quarantine.example    A       10.10.10.50
infected-mail.example MX      10 quarantine-mail.alpin-networks.ch.

4.1 Warum das wichtig ist

Genau hier wird der Unterschied zur klassischen Blacklist sichtbar. Eine Blacklist denkt oft nur in "erlauben oder blockieren". RPZ denkt in klaren Resolver Actions mit Ausnahmen, Redirects und kontrollierten Betriebsreaktionen.

4.2 PASSTHRU ist keine magische Whitelist

PASSTHRU ist eine gezielte Ausnahme. Wenn mehrere Regeln potenziell greifen, muss die Ausnahme passend definiert sein, damit sie die allgemeinere Policy tatsächlich übersteuert.

5. Wann eine Blacklist reicht

• kleine Umgebung mit einfachem Resolver Setup
• nur wenige bekannte Domains sollen gesperrt werden
• keine Kundensegmentierung nötig
• kein Walled Garden oder gezielter Redirect erforderlich
• keine komplexen Ausnahmen oder Triggerarten notwendig

In so einem Fall ist die Blacklist oft die pragmatischere Lösung. Weniger bewegliche Teile, weniger Betriebsaufwand, weniger Risiko.

6. Wann RPZ die bessere Wahl ist

• mehrere Resolver oder mehrere Standorte
• einheitliche Resolver Policy im Betrieb erforderlich
• interne und externe Threat Feeds sollen kontrolliert verteilt werden
• bestimmte Kundengruppen oder Netze brauchen Ausnahmen
• Redirect auf Warnseite oder Walled Garden soll möglich sein
• nicht nur QNAME, sondern auch Client IP, Antwort IP oder NS Informationen sollen Teil der Policy sein

6.1 Schweiz: Provider Policies, Umgehung und lokale Durchsetzung

Die eigentliche Frage ist daher nicht nur: Wollen wir blockieren? Sondern: Wie viel Policy, Steuerung, Ausnahmefähigkeit und Betriebssicherheit brauchen wir wirklich? In der Schweiz kommt eine weitere Dimension hinzu: In einzelnen Bereichen existieren regulatorische oder behördlich koordinierte Sperrmechanismen, die technisch sauber umgesetzt werden müssen.

Klar belegbar ist dies insbesondere beim Geldspielgesetz. Die ESBK veröffentlicht Sperrlisten für nicht bewilligte Online Spielangebote, und die Internetanbieter in der Schweiz müssen diese Sperren technisch durchsetzen. Für Phishing und betrügerische Webseiten ist die Lage differenzierter: Dort stehen heute vor allem Massnahmen rund um .ch und .swiss Domains, Blockierung, Umleitung und die Koordination zwischen BACS, Polizei, SWITCH und BAKOM im Vordergrund.

Technisch entscheidend ist dabei, wo die Policy tatsächlich greift. DNS Sperren auf Provider Resolvern sind nicht perfekt und können umgangen werden. Genau dort entsteht in Unternehmensnetzen oft eine Lücke: Wenn Corporate DNS Resolver nicht die Provider Resolver als Upstream verwenden, sondern selbst rekursiv auflösen, greift eine rein providerseitige DNS Policy auf diesen Resolvern nicht automatisch.

Die saubere Lösung ist deshalb, die Policy direkt auf den eigenen rekursiven Resolvern durchzusetzen. Genau hier kann Alpin Networks ansetzen: Corporate Resolver rekursieren selbst über die DNS Hierarchie und nutzen lokal eingespielte RPZ Feeds. Damit bleibt die Schutzwirkung auch dann erhalten, wenn ein Unternehmen bewusst nicht über die Upstream Resolver des Access Providers auflöst.

7. BIND Beispiel mit RPZ

Das folgende Beispiel zeigt eine lokale RPZ Zone in BIND. In der Praxis würdest du diese Zone oft von einem Primary auf weitere Resolver übertragen.

7.1 named.conf Ausschnitt

options {
    directory "/var/named";
    recursion yes;
    allow-recursion { 10.0.0.0/8; 192.168.0.0/16; localhost; };

    response-policy {
        zone "rpz.local";
    };
};

zone "rpz.local" {
    type primary;
    file "/etc/named/zones/db.rpz.local";
    allow-query { localhost; };
};

7.2 Beispiel Zone Datei mit mehreren Actions

$TTL 300
@   IN SOA localhost. root.localhost. (
        2026040303 ; serial
        3600       ; refresh
        900        ; retry
        604800     ; expire
        300        ; minimum
)
    IN NS localhost.

; 1) NXDOMAIN
bad-domain.example              CNAME   .

; 2) NODATA
tracking.example                CNAME   *.

; 3) PASSTHRU
ok.bad-domain.example           CNAME   rpz-passthru.

; 4) DROP
silent-block.example            CNAME   rpz-drop.

; 5) TCP-Only
udp-sensitive.example           CNAME   rpz-tcp-only.

; 6) Local Data / Walled Garden
phishing.example                CNAME   blockpage.alpin-networks.ch.
quarantine-client.example       A       10.10.10.50
infected-mail.example           MX      10 quarantine-mail.alpin-networks.ch.

; Response-IP Trigger
24.113.0.203.32.rpz-ip          CNAME   .

; Client-IP Ausnahme
32.1.2.0.192.rpz-client-ip      CNAME   rpz-passthru.

7.3 Wie dieses Beispiel wirkt

• bad-domain.example liefert synthetisch NXDOMAIN
• tracking.example liefert NODATA
• ok.bad-domain.example ist trotz genereller Sperre explizit erlaubt
• silent-block.example erzeugt keine Antwort an den Client
• udp-sensitive.example zwingt den Client auf TCP
• phishing.example wird auf eine interne Blockseite umgeleitet

8. Betrieb, Logging und Stolpersteine

8.1 Trigger und Priorität

Nicht jede passende Regel gewinnt automatisch. Sobald mehrere Regeln greifen könnten, muss klar sein, welche Policy zuerst ausgewertet wird und wie spezifisch die Ausnahme oder Blockregel formuliert ist.

8.2 Logging

Für den Betrieb lohnt sich dediziertes Logging. Gerade PASSTHRU Ausnahmen sollten sichtbar sein, damit Ausnahmen im Betrieb nicht unsichtbar bleiben.

8.3 Was in der Praxis oft schiefgeht

• PASSTHRU Regeln sind zu unspezifisch und greifen nicht wie erwartet
• DROP wird eingesetzt, obwohl Support und Fehlersuche damit unnötig erschwert werden
• Local Data wird wie ein einfacher Redirect behandelt, obwohl auch andere RRsets möglich sind
• die Reihenfolge der RPZ Zonen wird unterschätzt

9. Fazit

Eine Blacklist ist gut für kleine, klare Anwendungsfälle. RPZ ist die richtige Wahl, wenn DNS Security und Resolver Policy als kontrollierbarer Betriebsbaustein gedacht sind.

Die eigentliche Frage ist daher nicht nur: Wollen wir blockieren? Sondern: Wie viel Policy, Steuerung, Ausnahmefähigkeit und Betriebssicherheit brauchen wir wirklich?

Gerade in der Schweiz zeigt sich, dass providerseitige DNS Sperren allein nicht jede Architektur sauber abdecken. Sobald Unternehmen eigene rekursive Resolver betreiben, muss die Policy dort lokal durchgesetzt werden, sonst entstehen technische Lücken trotz regulatorischer oder behördlich koordinierter Sperrmechanismen.

Der nachhaltige Ansatz ist deshalb nicht nur Blockierung, sondern kontrollierte Policy Durchsetzung auf den Resolvern, die tatsächlich von den Clients genutzt werden.