Zusammenfassung

  • Eine RPZ enthält transportierbare Auslöser und vorgeschlagene Aktionen. AXFR, IXFR und TSIG können Herkunft und Version belegen, nicht aber sachliche Richtigkeit oder die Berechtigung für jede Clientgruppe.
  • Der abonnierende Resolver bestimmt Reihenfolge, Überschreibungen, PASSTHRU, DNSSEC, TTL, Cache und Startverhalten. Deshalb verantwortet sein Betreiber die umgeschriebene Antwort.

Besonders deutlich wird diese Verantwortung beim Neustart. Drei externe Richtlinienzonen sind konfiguriert, aber nur zwei laden. Soll der Resolver mit dem Teilbestand antworten, bis die dritte verfügbar ist? Soll er für alle Anfragen SERVFAIL liefern? Soll er einen gespeicherten alten Stand verwenden? Keine Signatur des Feeds beantwortet diese Fragen.

Die heutige BIND-9-Dokumentation beschreibt Response Policy Zones als offenes, herstellerneutrales Format für DNS-Firewallregeln. Auslöser und Aktionen stehen in einer DNS-Zone, die mit bekannten Transfermechanismen verteilt wird. Unbound und PowerDNS Recursor setzen dieses Modell mit eigenen Betriebsentscheidungen um.

Der formale Status ist enger. draft-vixie-dnsop-dns-rpz-00 ist ein abgelaufener individueller Internet-Draft, kein RFC und kein vom IETF gebilligter Standard. Die Datatracker-Historie vermerkt seit Juli 2020 den Zustand dormant. Das Dokument erklärt das gemeinsame Format, besitzt aber keine erfundene Normautorität.

Seine Trennung von Produzent und Abonnent bleibt aufschlussreich. Der Transfer veröffentlicht Richtliniendaten. Erst die Resolverkonfiguration des Abonnenten hebt sie in dessen lokale Steuerungsebene. TSIG kann den Transferpartner und die Unversehrtheit des Transports absichern. Es prüft weder einen Fehlalarm noch die Angemessenheit der vorgesehenen Wirkung.

Fünf Auslöser erfassen verschiedene Dinge: Client-IP, QNAME, eine Adresse in der ursprünglichen Antwort, den Namen eines autoritativen Servers und dessen Adresse. Sie wirken in unterschiedlichen Auflösungsphasen. NSDNAME und NSIP können zahlreiche fremde Domains treffen, wenn sie dieselbe DNS-Infrastruktur verwenden. BIND warnt vor dieser weitreichenden Wirkung.

Auch sechs Aktionen dürfen nicht als ein „Block“ behandelt werden. NXDOMAIN behauptet Nichtexistenz. NODATA lässt den Namen bestehen, entfernt aber den angefragten Typ. DROP schweigt. TCP-only erzwingt einen neuen Versuch über TCP. Local Data erzeugt eine eigene Antwort. PASSTHRU schützt eine Ausnahme. Jede Variante erzeugt andere Fehlerbilder und Cachefolgen.

Die BIND-Konfigurationsreferenz legt zuerst die Reihenfolge der Zonen zugrunde. Innerhalb einer Zone folgen Auslöserrang und Spezifität. Unbound prüft ebenfalls in Konfigurationsreihenfolge; PASSTHRU zählt als Treffer und stoppt spätere Zonen. Daher empfiehlt BIND eine interne RPZ vor externen Feeds, damit lokale Partnerausnahmen zuerst entscheiden.

Der Betreiber kann zudem die Aktion einer ganzen Zone überschreiben: BIND bietet unter anderem NXDOMAIN, NODATA, DROP, TCP-only, PASSTHRU und lokales CNAME. Unbound kann externe Auslöser behalten und alle Treffer an ein eigenes Ziel lenken. PowerDNS kennt Custom, Drop, NXDOMAIN, NODATA, Truncate und NoAction. Der Feed liefert damit nicht zwangsläufig die Aktion, die ein Client erlebt.

Testbetrieb hat ebenfalls produktspezifische Semantik. Bei Unbound protokolliert disabled, gilt nicht als Treffer und lässt die nächste Zone zu. PASSTHRU gilt als Treffer und beendet die spätere Auswertung. BIND definiert DISABLED mit eigener Prioritätswirkung. Eine Option ist erst dann harmlos, wenn das beobachtete Verhalten es bestätigt.

PowerDNS dokumentiert, dass sich die Auswertungsreihenfolge zwischen Versionen geändert hat. Aus Leistungs- und Datenschutzgründen werden Client, QNAME, Nameserver und Antwortadressen zu unterschiedlichen Zeitpunkten geprüft. Gleiche Zonen können auf zwei Softwareständen verschiedene Gewinner produzieren. Zur Beweiskette gehört daher die laufende Version.

DNSSEC verhindert, dass eine lokale Synthese die Autorität der Ursprungszone übernimmt. Der RPZ-Entwurf bezeichnet modifizierte Resultate technisch als bewusst „unwahre“ Antworten des rekursiven Servers. BIND wendet RPZ standardmäßig nicht an, wenn DNSSEC-Metadaten angefordert werden und im Original vorhanden sind. break-dnssec yes erlaubt die Umschreibung, deren Ergebnis dann nicht validiert werden kann.

RFC 4035 nennt Daten Bogus, wenn eine erwartete Vertrauenskette nicht hergestellt werden kann; Ursache kann Angriff, Fehlkonfiguration oder Beschädigung sein. Der RFC betont auch die lokale Richtlinie rekursiver Server. DNSSEC authentisiert autoritative RRsets, nicht das lokale NXDOMAIN. TSIG authentisiert den RPZ-Transfer, nicht die Aussage an den Client.

Ein lokaler Fehler kann zeitlich fortleben. RFC 2308 regelt negatives Caching von NXDOMAIN und NODATA mit unterschiedlichen Schlüsseln und TTL. BIND begrenzt die Richtlinien-TTL lokal; PowerDNS steuert synthetische TTL und Cachebereinigung. Rücknahme beim Produzenten, IXFR, Paketcache und nachgelagerte negative Caches laufen nach eigenen Uhren.

Für die Herkunft der Entscheidung bietet RFC 8914 differenzierte EDE-Codes: 15 für interne Sicherheitsrichtlinie, 16 für externe Vorgabe, 17 für vom Client gewünschte Filterung und 18 für einen nicht berechtigten Client. BIND und PowerDNS können EDE bei RPZ-Treffern setzen. Das verhindert, dass eine externe Verpflichtung als interne Gefahreneinschätzung erscheint.

EDE bleibt Diagnose, keine Ermächtigung. Es verändert die RCODE-Verarbeitung nicht, kann unauthentisiert sein und Informationen über Listen verraten. Aussagekräftig wird es erst zusammen mit Feed-Serial, lokaler Richtlinie, Gewinnerregel, Aktion, Clientgruppe und TTL.

Beim Start offenbart sich schließlich Kontinuitätsmacht. BIND kann mit servfail-until-ready bis zur Bereitschaft warten; scheitert eine Zone, kann es dennoch nach geladenen Zonen antworten. PowerDNS kann einen letzten erfolgreichen Stand dumpen und als Seed laden, bevor IXFR folgt. Der Betreiber muss Höchstalter, Teilbetrieb, Rollback und Eskalation festlegen. Ein gültiger alter Feed ist nicht automatisch ein zulässiger aktueller Feed.

Heng Lus Texte über den Vorrang von laufendem Code, minimale Anfangsspezifikation und lokalisierte Zukunftsentscheidung sowie Realitätsschichten liefern dafür die passende Disziplin. Das gemeinsame Format transportiert Kandidaten. Lokale Konfiguration entscheidet. Beobachtete Antworten zeigen die Wirklichkeit.

Ein belastbarer Nachweis verbindet Produzent, Serial, Transferauthentisierung, lokale Zulassung, Reihenfolge, Überschreibung, Gewinner, Aktion, TTL und EDE mit Proben aus jeder relevanten Clientgruppe. Die Gültigkeit des Feeds steht am Anfang dieser Kette, nicht an ihrem Ende.