Zusammenfassung

  • ISC stellte auf APNIC 62 Zonenlisten und die Erkennung abweichender Seriennummern als heutige DNS-Funktionen von Stork vor. Die Quellen belegen weder einen produktiven Einsatz bei APNIC noch einen realen Vorfall mit einer veralteten Zone.
  • Eine Abweichung ist Evidenz für die Server-, View- und Zonenkonfigurationszeilen, die Stork entdecken und abrufen konnte. Eine leere Abweichungsliste gilt nicht für den gesamten Bestand, solange Fehler, nicht unterstützte Views, Ausschlüsse und Cachealter fehlen.
  • Zum Ergebnis gehört ein Vergleichsbeleg: Versionen, Soll- und Ist-Umfang, Abrufstatus, rohe SOA-Seriennummern, Beobachtungszeit, Frist für Aktualität und die Behandlung jeder nicht verfügbaren Zeile.

Eine Abweichung trägt zwei Zahlen — eine Null braucht einen Nenner

Wenn dieselbe Zone auf zwei Servern verschiedene SOA-Seriennummern zeigt, ist der Befund eng, aber klar. Zwei beobachtete Werte stimmen nicht überein. Zeigt ein Dashboard keine Abweichung, ist die Lage anspruchsvoller. Es kann bedeuten, dass alle erwarteten Instanzen übereinstimmen. Es kann ebenso bedeuten, dass eine Instanz nie Teil des Vergleichs war.

In den Stork-Folien von APNIC 62 ordnete Marcin Siodelski Zonenliste und -filter, Zone Viewer sowie „Serial Mismatch Detection“ den aktuellen DNS-Funktionen zu. Der Bericht von APNIC hob denselben Vergleich zwischen Servern hervor. Für große Umgebungen ist das ein echter Fortschritt: Die Differenz muss nicht mehr auf jedem System einzeln gesucht werden.

Stork beobachtet jedoch keinen abstrakten Gesamtbestand. Es sieht Daemons, die seine Agenten erkennen, Konfigurationen und Schnittstellen, die sie lesen können, und Zoneninformationen, deren Abruf der Stork-Server veranlasst hat. Was diese Kette nicht durchläuft, erscheint weder als Abweichung noch als Übereinstimmung.

Die DNS-Dokumentation von Stork 2.4.1 beschreibt das für BIND 9. Der Agent ermittelt aus dem laufenden named-Prozess die tatsächlich genutzte Konfiguration. Findet er sie nicht, erscheint der Daemon nicht in der Liste erkannter Dienste. Für den Zone Viewer ist außerdem der Statistics Channel nötig, über den konfigurierte Views und Zonen ermittelt werden. PowerDNS wird über seine Konfiguration und Web-API angebunden.

Unsichtbarkeit ist damit noch kein Fehler. Ein Server kann bewusst außerhalb des Monitorings liegen, eine Berechtigung kann absichtlich knapp sein, eine Schnittstelle kann aus Sicherheitsgründen deaktiviert sein. Die Folge betrifft die Aussage: Das Ergebnis beschreibt die erfolgreich beobachtete Menge, nicht automatisch jeden autoritativen Server der Organisation.

Hinzu kommt die Zeit. Die Zonenliste im Stork-Server ist anfangs leer. Nach Fetch Zones werden die von den Agenten gesammelten Daten in Storks Datenbank zwischengespeichert. Die Liste aktualisiert sich aus Leistungsgründen nicht automatisch; für einen neuen Stand ist ein weiterer Abruf nötig. Fehler sind unter Fetch Status sichtbar. Ohne Abrufzeitpunkt kann eine korrekte alte Liste wie ein aktuelles Bild gelesen werden.

Stork weist zwei unterschiedliche Größen aus. Zone Configs Count zählt Konfigurationen; derselbe Zonenname in mehreren Views wird mehrfach gezählt. Distinct Zones zählt den Namen nur einmal. Wer nur die zweite Zahl bewahrt, verliert die View-Ebene. Wer nur die erste Zahl bewahrt, kann nicht erkennen, ob neue Namen oder zusätzliche Views hinzugekommen sind. Beide Werte gehören zum Nenner.

Views zeigen, warum Identität nicht allein im Zonennamen liegt. Möchte Stork den Inhalt einer BIND-9-Zone in einer nicht standardmäßigen View per AXFR abrufen, braucht es einen TSIG-Schlüssel, mit dem BIND die richtige View auswählt. match-clients und allow-transfer sind Teil dieser Zuordnung. Stork 2.4.1 unterstützt dagegen die in PowerDNS 5.0 eingeführten DNS-Views ausdrücklich noch nicht. Eine solche View ist nicht „gleich“ und nicht „abweichend“, sondern außerhalb der dokumentierten Sicht.

Zoneninventar und Zoneninhalt nehmen zudem verschiedene Wege. Liste und Seriennummern kommen über die Serverintegrationen und werden nach Fetch Zones gespeichert. Den vollständigen Inhalt fordert ein Nutzer über Show Zone an; dafür verwendet Stork AXFR und kann eine vorhandene Kopie anzeigen, bis Refresh from DNS einen neuen Abruf erzwingt. Ein fehlgeschlagener AXFR kann das Lesen der Records verhindern, obwohl eine Seriennummer in der Liste steht. Eine sichtbare Seriennummer beweist umgekehrt keine vollständige Übertragung.

XFR-Monitoring ist eine dritte Oberfläche. Die Folien markieren es als neu in der Entwicklungsversion 2.5.1. Laut Agent-Handbuch 2.5.1 ist die BIND-spezifische Logverfolgung standardmäßig deaktiviert, muss ausdrücklich eingeschaltet werden und kann Transfers nicht verfolgen, wenn sie nur im Syslog stehen. Die ISC-Produktseite führt 2.4.1 als stabile und 2.5.1 als Entwicklungsversion. Ein Beleg ohne Versionsnummer kann Fähigkeiten benachbarter Releases vermischen.

Auch SOA-Seriennummern folgen nicht der gewöhnlichen Ganzzahlordnung. RFC 1912 erläutert, wie ein Secondary anhand der Seriennummer des Primary entscheidet, ob neue Daten angefordert werden. RFC 1982 definiert einen zyklischen 32-Bit-Raum. Werte laufen über; bei genau einem halben Zahlenraum Abstand ist keine Reihenfolge definiert.

Die geprüften Stork-Quellen tragen die Aussage, dass ungleiche Werte hervorgehoben werden. Sie legen nicht offen, welche Altersbezeichnung das Produkt jedem möglichen Paar gibt. Deshalb sollte der Beleg beide Rohwerte und — falls eine Reihenfolge ausgewiesen wird — Regel und Ergebnis sichern. „Ungleich“ ist Beobachtung. „Dieser Secondary ist zurück“ braucht zusätzlich Rolle, Zeitpunkt und RFC-1982-Auswertung.

Gleiche Seriennummern beweisen weder identische Zonendaten noch gültiges DNSSEC oder die tatsächlich an Nutzer ausgelieferte Antwort. Für diese Fragen gibt es andere Prüfungen. Der besondere Gegenstand dieser Meldung liegt davor: Waren alle Zeilen vorhanden, deren Gleichheit später als Gesamtzustand ausgegeben wird?

Ein Abdeckungsbeleg kann knapp bleiben. Er nennt Versionen von Stork-Server, Agenten und DNS-Daemons; stabile Kennungen für Maschine, Daemon, Zone, Klasse und View; den erwarteten Bestand und dessen Verantwortlichen; Start, Ende und Status des Abrufs pro Daemon; beide Zonenzähler; Ausschlüsse und nicht unterstützte Views; rohe SOA-Werte; Beobachtungs- oder Cachezeit und zulässiges Alter; Ergebnis, Alarmentscheidung und Berichtigungen. Geheimnisse müssen darin nicht stehen.

Damit entstehen vier belastbare Zustände: vollständig für den erklärten Umfang, teilweise wegen fehlender Zeilen, veraltet wegen überschrittener Frist oder nicht vergleichbar wegen geänderter Mitgliedschaft. Eine Abweichung in einer Teilmenge bleibt ein echter Befund. Keine Abweichung in derselben Teilmenge wird dadurch nicht zum Befund über den Rest.

Diese Disziplin spricht nicht gegen Stork. Sie macht den zentralen Blick erst entscheidungsfähig. Die Software liefert die beobachtete Menge; die Organisation muss die erwartete Menge führen. Erst ihre Abstimmung verwandelt einen markierten Unterschied in einen reproduzierbaren Betriebsnachweis.

Quellen