DNS-Survey

Das Primary-Secondary-Überkreuz-Problem

Ein häufig zu beobachtendes Problem beim Betrieb von Nameservern ist das Weiterleben von resource records an der Zonengrenze zwischen delegierender und delegierter Zone. Es tritt i.d.R. dann auf, wenn die primary server für beide Zonen auf verschiedenen Rechnern angesiedelt und zusätzlich für die jeweils andere Zone als secondary server konfiguriert sind.

Beispiel:

Sei der Server ns.Her.DE primary für die Zone Her.DE und secondary für Vieh.Her.DE. Der Server rind.Vieh.Her.DE sei der primary server für die Zone Vieh.Her.DE und secondary für Her.DE. Es existieren also in der Zone Vieh.Her.DE u.a. die beiden NS-resource records 
	Vieh.Her.DE.	IN	NS	rind.Vieh.Her.DE.
	Vieh.Her.DE.	IN	NS	ns.Her.DE.
Es gebe jetzt außerdem einen dritten NS-RR, z.B. 
	Vieh.Her.DE.	IN	NS	wilde.Hor.DE.
(Dieser RR existiert bei korrekter Verwaltung sowohl in der Zonendatei für Her.DE als auch in der für Vieh.Her.DE.) Soll dieser RR jetzt entfernt werden (weil etwa die Delegation an den Server wilde.Hor.DE aufgehoben werden soll), so wird - wiederum korrekte Administration vorausgesetzt - der RR sowohl aus der delegierenden Zone Her.DE als auch aus der delegierten Zone Vieh.Her.DE gestrichen.
Nach einem reload der beiden Server wird der alte - aus den Originalen gelöschte - NS-RR dennoch auf beiden Servern weiterhin vorhanden sein, auch wenn beide Administratoren sich bis hierher korrekt verhalten.

Die häufig anzutreffenden, schlechte Praxis, dem Verwalter der übergeordneten Zone Änderungen nicht oder nur verspätet mitzuteilen und nicht mit ihm abzustimmen, sorgt für weitere Fehlerquellen.

Gegenmaßnahmen

Ein lokaler Neustart der beteiligten Nameserver führt nicht zum Ziel, da vom jeweils anderen Server umgehend die fehlerhaften Daten wieder übernommen werden.

Wichtig ist vielmehr ein koordiniertes Vorgehen, bei dem beide Nameserver zeitgleich von der Zonenkopie der Zone, für die sie als secondary konfiguriert sind, befreit werden. Der folgende Fahrplan hilft, der einst gerufenen Geister wieder ledig zu werden:

Schritt 1:
Zuerst müssen beide Zonen aktualisiert werden. Dazu editieren Sie die Original-Zonendateien auf dem jeweiligen primary. Vergessen Sie nicht, dabei jeweils die SOA-Seriennummer zu erhöhen. Die aus der delegierenden Zone und aus der delegierten Zone stammenden Sätze von NS-RRs müssen übereinstimmen.
Schritt 2:
Stoppen Sie die beiden beteiligten Nameserver-Prozesse
Schritt 3:
Um eine Reinfektion zu verhindern müssen Sie jetzt die Dateien löschen, die die Kopie der Zone halten, für die der jeweilige Server secondary ist.
Schritt 4:
Sie können jetzt beide Nameserver neu starten. Dabei werden dann die aktuellen, "sauberen" Zonen gelesen und per AXFR dem jeweils anderen zur Verfügung gestellt.

Man kann auch um das Anhalten des Server-Prozesses herumkommen, indem man z.B. kurzfristig auf den jeweils überkreuz liegenden secondary verzichtet.

Ursachen

Die Ursache des Problems liegt zum einen in einer nicht bis ins letzte Detail ausgeführten Spezifikation des DNS, zum anderen an einer unsauberen bzw. unvorsichtigen Implementierung des BIND. Der Nameserver dürfte, wenn er für die delegierte Zone autoritativ ist, nur die in der zugehörigen Zonendatei angegebenen NS-RRs abgeben, und zwar auch beim Zonentransfer der delegierenden Zone - unabhängig von den dort für die delegierte Zone angegebenen RRs.

Bei alten BIND-Versionen treten diese Zombie-RRs nicht nur in als NS-RRs, sondern auch als MX-RRs, A-RRs oder andere Typen von resource records auf, die an der Zonengrenze existieren können.

Peter Koch, 1994-10-07, 1994-10-24