Eine Zone für alle Rückwärtseinträge — RFC 2317 ohne Unterzonen

Wer eine Mail verschickt, wird vom Empfänger rückwärts geprüft: Auf welchen Namen zeigt die Adresse, von der die Verbindung kommt, und zeigt dieser Name wieder zurück auf genau diese Adresse? Fehlt einer der beiden Wege, landet die Post im Spam oder wird gleich abgelehnt. Für die eigenen öffentlichen IPv4-Adressen pflege ich diese Rückwärtseinträge (PTR) deshalb selbst. Bis zum 15. Oktober 2026 lagen sie in einer Zone mit einem Namen, den man sich nicht merken kann.

Wie es vorher war

Die Adressen gehören dem Provider, mir gehört nur ein kleiner Block daraus, ein /28. Rückwärtszonen gibt es aber nur in Schritten von 256 Adressen. Für Blöcke darunter beschreibt RFC 2317 einen Ausweg: Der Provider legt in seiner Zone für jede Adresse einen CNAME an, der in eine eigene, an mich delegierte Unterzone zeigt.

; beim Provider, in 100.51.198.in-addr.arpa
176-191   NS     ns1.<hauptdomain>.
176-191   NS     ns2.<hauptdomain>.
185       CNAME  185.176-191.100.51.198.in-addr.arpa.

Das funktioniert, hat aber einen Haken: Jedes weitere Netz braucht eine weitere Zone, mit eigenem Namen nach demselben Muster. Dazu eine eigene Delegation beim Provider, einen eigenen Eintrag in der Zonenverteilung und eine eigene Prüfung in der Überwachung. Bei einem Netz ist das lästig, bei dreien wird es unübersichtlich.

Der Umbau

Wohin die CNAMEs zeigen, schreibt RFC 2317 nicht vor. Das Ziel muss weder unter in-addr.arpa liegen, noch muss es eine eigene Zone sein. Also zeigen sie jetzt in eine Zone unter meiner eigenen Domain:

; beim Provider - keine NS mehr, nur noch eine Zeile
$GENERATE 176-191 $ CNAME $.100.51.198.ptr.<hauptdomain>.

; bei mir, in ptr.<hauptdomain>
$ORIGIN 100.51.198.ptr.<hauptdomain>.
185   PTR   mail.<hauptdomain>.

• Ein neues Netz bedeutet jetzt: CNAMEs beim Provider, ein neuer $ORIGIN-Block in derselben Datei. Es gibt keine neue Zone und keine neue Delegation, und an der Konfigurationsverwaltung ändert sich nichts.
• Die Namen enthalten die volle Adresse rückwärts. Zwei Netze, deren Adressen auf dieselbe Zahl enden, kommen sich so nicht ins Gehege.
• Die Zone ist nicht signiert. Die Kette vom Provider her ist es ohnehin nicht, eine Signatur am Ende hätte niemand prüfen können. Wie bei der Zone für die Zertifikatsnachweise: Die übergeordnete Zone beweist signiert, dass es keinen DS gibt, und das ist gültig.
• Die neue Zone verteilt sich wie alle anderen über die Catalog Zone an die beiden öffentlichen Nameserver.

Umgezogen wurde in drei Schritten: Erst stand die neue Zone parallel zur alten, mit denselben Einträgen. Dann hat der Provider die CNAMEs umgestellt. Erst als niemand mehr nach der alten Zone gefragt hat, habe ich sie abgebaut. Ein Prüfskript hat jede der 16 Adressen in beiden Zonen verglichen und für jeden Namen nachgesehen, ob er wieder auf seine Adresse zeigt.

Stolpersteine

Der interne Resolver wäre ins Leere gelaufen. Der Nameserver beantwortet intern auch Anfragen nach meiner eigenen Domain, und zwar aus einer eigenen, internen Fassung der Zone. Folgt er dem CNAME vom Provider nach ….ptr.<hauptdomain>, sucht er den Namen in dieser internen Fassung. Dort gab es ihn nicht, also lautete die Antwort NXDOMAIN, und jede interne Rückwärtsabfrage wäre gescheitert.

Abhilfe ist eine Delegation ptr NS … in beiden Fassungen der Zone. Dann erkennt der interne Resolver den Schnitt und reicht die Frage weiter. Ich habe das vorab mit zwei BIND-Instanzen im Labor nachgestellt: Mit dem Schnitt kam der PTR, ohne ihn NXDOMAIN. Von außen sieht man diesen Fehler nicht, nur von innen.

Die Elternzone beim Provider ist dynamisch. Dort trägt die Provisionierung Einträge per Update ein. rndc reload verweigert dann den Dienst, weil eine Änderung von Hand an der Datei die Updates überschreiben könnte. Der richtige Weg ist rndc freeze, ändern, rndc thaw, und vorher ein Vergleich, ob das Einfrieren die Datei verändert hat.

24 Stunden Cache. Der alte CNAME hatte eine TTL von einem Tag. Wie lange irgendwo draußen noch ein Resolver den alten Weg im Speicher hat, lässt sich nicht abfragen. Messen lässt es sich aber: Ein solcher Resolver muss für den PTR selbst stündlich bei meinen Nameservern nachfragen, und zwar unter dem alten Namen. Ich habe das Abfrageprotokoll mitlaufen lassen. Die einzigen Anfragen an die alte Zone kamen von meiner eigenen Überwachung. Damit ließ sich die alte Zone schon am Vormittag abbauen statt erst am Abend.

Die Uhren gingen verschieden. Bei dieser Auswertung fiel auf, dass die Nameserver außer Haus nach UTC protokollierten und alle anderen nach deutscher Zeit. Einträge von zwei Hosts ließen sich so nicht direkt nebeneinanderlegen. Seitdem gibt die Konfigurationsverwaltung allen Maschinen dieselbe Zeitzone vor.

Aufgeräumt, wenn man schon dabei ist

Beim Abbau der alten Zone lagen auf den öffentlichen Nameservern noch Dateien von einer Domain, die schon seit sechs Wochen nicht mehr existiert, dazu eine zweite Fassung der alten Rückwärtszone, deren Name sich nur in der Groß- und Kleinschreibung unterschied. Normalerweise löscht BIND die Datei einer Zone selbst, sobald sie aus der Catalog Zone fällt. Liegen bleibt sie, wenn das passiert, während BIND nicht läuft.

Dafür gibt es jetzt ein kleines Werkzeug im Nameserver-Modul. Es fragt BIND, welche Dateien es tatsächlich benutzt, und schiebt alles andere in eine Quarantäne. Gelöscht wird erst nach 90 Tagen. Ein Timer erledigt das jede Woche, aber nur für Dateien, die sich seit mindestens sieben Tagen nicht mehr geändert haben. Antwortet BIND nicht oder sähe plötzlich mehr als die Hälfte der Dateien verwaist aus, bricht es ab und rührt nichts an.

Dass der Timer läuft, prüfte die Überwachung schon vorher. Neu ist eine Prüfung, ob er auch wirkt: Sie meldet sich, wenn eine verwaiste Datei länger liegt, als der Timer sie liegen lassen dürfte. Gleich beim ersten Lauf hat sie die sechs Wochen alten Reste gefunden. Das war der Beweis, dass die Prüfung etwas sieht, was vorher niemand gesehen hatte.

Was ich daraus mitnehme

Ein Name, den ich selbst festlege, wächst mit. Das nächste Netz kostet jetzt fünf Minuten in einer Datei, die ich ohnehin pflege. Vorher waren es eine neue Zone, eine neue Delegation und eine neue Prüfung.