DNS-Änderungen durch KI-Coding-Agenten: Prüfungen sicherer machen

DNS-Änderungen durch KI-Coding-Agenten brauchen eine strengere Form als gewöhnliche Änderungen an der Infrastruktur. Ein Agent sollte niemals einfach «DNS aktualisieren» als eine einzige Genehmigung vorlegen. Er sollte das Erstellen, Bearbeiten oder Löschen als getrennte Aktionen darstellen, jeweils mit anderen Belegen, anderen Fragen für den Prüfer und einer eigenen Behandlung von Fehlern.

Diese Trennung klingt so lange bürokratisch, bis ein Agent einen Mail-Eintrag ersetzt, neben inkompatiblen Daten einen CNAME hinzufügt oder während einer Migration den letzten Adresseintrag löscht. DNS lässt kleine Textänderungen harmlos aussehen. Ihre Auswirkungen reichen über Resolver, Clients, delegierte Zonen, Zertifikatsprüfungen, den E-Mail-Versand und die Diensterkennung hinweg. Ein Prüfer muss das genaue Verb sehen, bevor er die Reichweite eines Fehlers beurteilen kann.

DNS-Eintragsverben bergen unterschiedliche Risiken

Beim Erstellen eines DNS-Eintrags kommt eine neue Aussage zur Zone hinzu. Der Prüfer muss fragen, wem der Name gehört, ob das Ziel stimmt, ob die neuen Daten mit vorhandenen Daten kollidieren und ob jemand den Eintrag für eine Domain-Validierung oder zum Abfangen von Datenverkehr missbrauchen könnte.

Beim Bearbeiten eines Eintrags wird eine bestehende Aussage geändert. Diese Aktion braucht den alten und den neuen Wert nebeneinander. Eine Änderung von einer Adresse zu einer anderen kann den Anwendungsdatenverkehr umleiten. Eine Änderung an einem TXT-Eintrag kann die Absenderauthentifizierung, eine Besitzprüfung oder eine Konfiguration beeinflussen, die ein externer Dienst nutzt. Der alte Zustand hilft dem Prüfer, einen beabsichtigten Austausch von einer Aktion des Agenten mit veralteten Informationen zu unterscheiden.

Beim Löschen eines Eintrags wird behauptet, dass sein Fehlen jetzt korrekt ist. Die möglichen Folgen sind am weitesten gefächert, weil ein sicherer Ausgang oft von etwas außerhalb des DNS abhängt. Vielleicht braucht der neue Endpunkt Zeit, um Datenverkehr zu empfangen. Vielleicht nutzt ein anderes Team noch einen TXT-Eintrag zur Verifizierung. Vielleicht gehört der Eintrag zu einer Failover-Konfiguration, die der Agent aus einem Repository nicht ableiten kann.

Wer diese Vorgänge als einen allgemeinen Schreibvorgang behandelt, macht Prüfer blind für den Unterschied. Ein Prüfer sieht auf jeder Karte dasselbe, klickt sich durch und bemerkt zu spät, dass eine Karte ein vollständiges RRset entfernt hat. Die Kontrolle muss den gefährlichen Unterschied unübersehbar machen.

Auch die DNS-Terminologie verlangt Sorgfalt. Ein DNS-Owner-Name kann ein RRset enthalten, also eine Gruppe von Einträgen mit demselben Namen und Typ. Viele Provider-APIs stellen ein einzelnes «record»-Objekt bereit, aber ihr Update-Verhalten kann das vollständige RRset ersetzen. Wenn ein Agent einen von zwei A-Werten entfernen will und der Provider die Gruppe ersetzt, kann er versehentlich beide entfernen. Prüfe das tatsächliche Objektmodell des Providers, bevor du festlegst, was eine Aktion bedeutet.

Jede Anfrage muss ein eindeutiges, unumkehrbares Verb nennen

Eine DNS-Aktion sollte genau ein Verb enthalten: create, edit oder delete. Akzeptiere an der Genehmigungsgrenze keine vage Methode namens apply, sync oder upsert. Diese Namen sind für Programmierer praktisch und für Betreiber teuer.

Die Anfrage muss außerdem angeben, ob sie sich auf ein einzelnes Provider-Objekt oder auf ein vollständiges RRset bezieht. Wenn die API ein einzelnes Mitglied nicht sicher bearbeiten kann, sollte die Aktion festhalten, dass sie das gesamte RRset ersetzt, und jeden beibehaltenen Wert auflisten. Schweigen an dieser Stelle verwandelt eine scheinbar kleine Adressänderung in einen Ausfall.

Verwende eine Anfrageform, die die Absicht bewahrt und dem Ausführer genug Zustand gibt, um Abweichungen zurückzuweisen:

{
  "action": "edit",
  "zone": "example.net",
  "owner": "api.example.net.",
  "type": "A",
  "expected_rrset": {
    "ttl": 300,
    "values": ["198.51.100.24"]
  },
  "proposed_rrset": {
    "ttl": 300,
    "values": ["198.51.100.81"]
  },
  "reason": "Move the API endpoint after the service owner confirmed health checks",
  "verification": [
    "authoritative lookup returns 198.51.100.81",
    "HTTPS health check succeeds at the new endpoint"
  ]
}

Bei einer Erstellungsaktion sollte expected_rrset angeben, dass das RRset nicht vorhanden ist, oder einen zulässigen bestehenden Zustand nennen, wenn das Modell des Providers dies verlangt. Bei einer Löschung sollte proposed_rrset ausdrücklich als nicht vorhanden angegeben werden. Kodiere das Fehlen nicht als leere Zeichenkette und lasse das Feld nicht weg. Eindeutige Nutzdaten erzeugen eindeutige Logs.

Der Ausführer sollte den aktuellen Zustand der Zone unmittelbar vor dem Schreibvorgang lesen. Er sollte diese Beobachtung mit expected_rrset vergleichen und bei jeder Abweichung abbrechen. Das ist ein Compare-and-Swap-Prinzip, auch wenn der DNS-Provider keinen entsprechenden Endpunkt anbietet.

RFC 2136, «Dynamic Updates in the Domain Name System», formuliert diese Idee direkt im Protokoll. Der Abschnitt zu den Voraussetzungen erlaubt einem Client anzugeben, welche RRsets vor der Annahme eines Updates vorhanden sein müssen oder nicht vorhanden sein dürfen. Die meisten gehosteten DNS-APIs stellen keine RFC-2136-Nachrichten auf Leitungsebene bereit, aber die praktische Lehre bleibt richtig: Ein Schreibvorgang auf Grundlage einer ungeprüften früheren Abfrage ist unsicher.

Ein Agent darf eine Abfrage wiederholen. Einen fehlgeschlagenen Schreibvorgang darf er nicht wiederholen, indem er den erwarteten Zustand auf das setzt, was er gerade sieht. Eine Abweichung bedeutet, dass ein anderer Akteur DNS geändert hat, der Plan des Agenten veraltet ist oder der Provider Daten anders normalisiert hat als erwartet. Dieser Zustand muss an einen menschlichen Prüfer eskaliert werden.

Beim Erstellen zählen Zuständigkeit und Konfliktbelege

Ein neuer Eintrag braucht vor der Genehmigung einen Beleg dafür, dass der Name zum vorgesehenen Dienst gehört. Ein Repository-Pfad, ein Ticketverweis oder eine natürlich formulierte Anfrage kann auf Zuständigkeit hindeuten, beweist aber nicht, dass ein neuer öffentlicher Name frei verwendet werden darf.

Der Agent sollte den exakten Owner-Namen über alle Eintragstypen hinweg prüfen, bevor er eine Erstellung vorschlägt. Das ist bei CNAME-Einträgen besonders wichtig. RFC 1034 besagt, dass an einem Knoten neben einem vorhandenen CNAME-RR keine anderen Daten vorhanden sein sollen. Ein Planer, der nur nach einem vorhandenen CNAME sucht, kann einen CNAME an einem Namen vorschlagen, der bereits Adress-, Mail- oder TXT-Daten enthält. Der Provider kann den Schreibvorgang ablehnen oder, schlimmer noch, Daten nach einer providerspezifischen Regel ersetzen.

Bei der Prüfung einer Erstellung sollten vier Dinge in klarer Sprache erscheinen:

• Der vollständig qualifizierte Owner-Name, die Zone, der Eintragstyp, der Wert und die TTL.
• Die aktuellen Einträge unter demselben Owner-Namen, einschließlich der Typen, die der Agent nicht ändern wird.
• Wer den Namen angefordert hat und welcher Dienst ihn nutzen wird.
• Die für den Eintragstyp passende Zielprüfung.

Die Zielprüfung hängt von den Daten ab. Bei einem A- oder AAAA-Eintrag kann der Agent bestätigen, dass die Adresse zum erwarteten Deployment-Bestand gehört, sofern es einen solchen Bestand gibt. Bei einem CNAME sollte er das Ziel auflösen und sicherstellen, dass der Zielname vollständig ist. Bei einem MX-Eintrag sollte er den Mail-Hostnamen und die Priorität mit dem Mail-Verantwortlichen bestätigen. Bei einem TXT-Eintrag für einen externen Prüfer sollte er den exakt gelieferten Wert beibehalten, statt Leerzeichen oder Anführungszeichen nach Vermutungen zu «bereinigen».

Lass einen Agenten nicht annehmen, dass eine neu angeforderte Subdomain harmlos ist, weil sie unter einer bekannten Domain liegt. login, auth, mta, vpn und admin haben offensichtlich weitreichende Folgen, aber auch beliebige andere Namen können wichtig sein. Ein öffentlicher DNS-Name wird zu einer Schnittstelle, sobald sich jemand darauf verlässt.

Auch eine Erstellung unterscheidet sich von einem Release-Deployment, weil ein Rollback nicht unbedingt Löschen bedeutet. Wenn ein neuer Eintrag einen Verifizierungsablauf unterstützt, kann sein Löschen nach Abschluss des Ablaufs die Erneuerung oder eine spätere Validierung beschädigen. Der Vorschlag sollte sagen, ob der Eintrag vorübergehend ist, wer über sein Auslaufen entscheidet und ob der Antragsteller einer späteren Entfernung zustimmt. Wenn niemand diese Frage verantwortet, erfinde kein Ablaufdatum.

Eine Bearbeitung muss den zu ersetzenden Zustand nennen

Eine Bearbeitung ist nur sicher, wenn der Vorschlag den genauen Zustand nennt, den er ersetzt. «Die App auf den neuen Host zeigen lassen» beschreibt eine Absicht, aber keine ausführbare DNS-Aktion.

Verlange in jedem Bearbeitungsantrag das bisherige RRset, einschließlich der Werte, die der Agent beibehalten will. Betrachte ein A-RRset mit zwei Adressen:

Current:  app.example.net. 60 IN A 198.51.100.10
          app.example.net. 60 IN A 198.51.100.11
Proposed: app.example.net. 60 IN A 198.51.100.11
          app.example.net. 60 IN A 198.51.100.12

Das ist eine kontrollierte Rotation. Der Prüfer sieht, dass die Aktion eine aktive Adresse beibehält und die andere ersetzt. Wenn der Provider RRsets als Einheit ersetzt, wäre das Senden von nur 198.51.100.12 eine Löschung und eine Erstellung, die als Bearbeitung getarnt sind.

TTL-Änderungen gehören auf dieselbe Prüfkarte. Teams senken die TTL vor einer Migration oft ab und erhöhen sie danach wieder. Beide Änderungen haben Folgen. Eine niedrigere TTL erhöht die Häufigkeit von Resolver-Abfragen und kann Konfigurationsfehler schneller sichtbar machen. Eine höhere TTL kann den Datenverkehr nach einer fehlerhaften Bearbeitung länger am falschen Endpunkt halten. Keine der beiden Änderungen sollte in einem allgemeinen Eintragsupdate verschwinden.

Ein Agent sollte außerdem Datenänderungen von bloßen Formatierungsunterschieden trennen. Provider können Owner-Namen kanonisieren, einen abschließenden Punkt hinzufügen, TXT-Zeichenketten aufteilen oder Werte neu anordnen. Ein Planer, der rohe API-Texte vergleicht, erzeugt unnötige Genehmigungskarten oder falsche Konflikte. Normalisiere die Darstellung vor dem Vergleich, bewahre aber die semantischen Daten, die ein Prüfer lesen muss.

Genehmige eine Bearbeitung nicht einfach deshalb, weil ein Agent eine passende Zeichenkette in der Versionsverwaltung gefunden hat. Die Versionsverwaltung kann einen gewünschten Zustand enthalten, der nach einer dringenden DNS-Änderung nicht mehr relevant ist. Der aktuelle autoritative Zustand bleibt die Voraussetzung für den Schreibvorgang. Repositories erklären die Absicht, DNS zeigt, was Clients empfangen können.

Eine Löschung braucht einen Grund für das Fehlen

Eine Löschung sollte erklären, warum der Eintrag jetzt verschwinden darf, und nicht nur, warum der Agent ihn für überflüssig hält. Alte Einträge wirken oft redundant, bis jemand feststellt, dass sie einen alten Callback, ein E-Mail-System, einen Zertifikatsprüfer oder einen delegierten Dienst unterstützen.

Das sichere Vorgehen trennt die Umleitung des Datenverkehrs von der Bereinigung. Erstelle oder bearbeite zunächst die Ersatzdaten. Überprüfe anschließend die gewünschte autoritative Antwort und den abhängigen Dienst. Erst wenn der Verantwortliche das neue Verhalten akzeptiert hat, sollte der Agent die Löschung der alten Daten beantragen. Halte den Löschantrag getrennt, selbst wenn der Provider beides zusammenfassen könnte.

Ein Löschantrag sollte folgende Angaben enthalten:

• Das genaue RRset oder Provider-Objekt, das entfernt werden soll.
• Den Dienst oder das Team, das bestätigt hat, dass es die Daten nicht mehr benötigt.
• Die Ersatzaktion, falls es eine gibt, und ihr Prüfergebnis.
• Die geplante Prüfung nach der Entfernung.
• Eine Aussage darüber, ob die Entfernung ein vollständiges RRset verändert.

Für Apex-Einträge ist besondere Vorsicht nötig. Das Verhalten am Zonen-Apex unterscheidet sich je nach Provider, insbesondere wenn Provider Aliase oder synthetische Einträge anbieten, die sich wie CNAMEs verhalten. Ein Agent sollte einen gewünschten CNAME niemals ohne einen Prüfer, der die Semantik des Providers versteht, in eine providerspezifische Apex-Funktion übersetzen. Ein vertrautes DNS-Wort garantiert kein vertrautes DNS-Verhalten.

Negatives Caching erschwert die Wiederherstellung nach einer Entfernung. RFC 2308 beschreibt, wie Resolver negative Antworten cachen können, darunter NXDOMAIN und Antworten ohne Daten. Wenn du einen Eintrag löschst und anschließend wiederherstellst, können einige Clients den früheren Zustand weiterhin als nicht vorhanden sehen, bis ihr negativer Cache abläuft. Das bedeutet nicht, dass Löschen verboten ist. Es bedeutet, dass der Rollback-Plan auch die Zeit berücksichtigen muss, in der das autoritative DNS bereits korrigiert ist, Nutzer aber noch einen gecachten Fehler erhalten.

Eine Löschaktion darf sich nicht stillschweigend ausweiten, wenn der Provider die Entfernung eines einzelnen Werts ablehnt. Der Ausführer sollte melden, dass der Provider den Austausch eines vollständigen RRsets verlangt, und eine neue, ausdrücklich formulierte Aktion anfordern. Diese zusätzliche Genehmigung ist günstiger, als erklären zu müssen, warum ein angeblich nicht mehr genutzter Adresseintrag verschwunden ist.

Prüfkarten brauchen mehr Kontext als einen Zonen-Diff

Ein roher Diff liefert Prüfern Daten, verbirgt aber oft die Konsequenz. Prüfkarten sollten mit einem kurzen Satz beginnen, der die Aktion und das erwartete Verhalten nennt: «Den veralteten TXT-Verifizierungseintrag für verify.example.net löschen; der Antragsteller hat bestätigt, dass die externe Verifizierung abgeschlossen ist.» Danach sollten die genauen Einträge folgen.

Auf der Karte sollten diese Felder sichtbar sein, ohne eine separate Ansicht zu öffnen: Aktionsverb, Zone, Owner-Name, Typ, alter Zustand, vorgeschlagener Zustand, TTL, Antragsteller, Identität des Agent-Prozesses, Grund und Prüfplan. Wenn der Schreibvorgang ein vollständiges RRset betreffen kann, muss das in der ersten Zeile stehen.

Verwende direkte Formulierungen. «Beide A-Werte ersetzen» ist besser als «Eintragssatz abgleichen». «Diesen MX-Eintrag entfernen» ist besser als «Gewünschte Konfiguration anwenden». Prüfer entscheiden schneller, wenn das System operative Verben statt abstrakter Begriffe verwendet.

Eine gute Karte gibt dem Prüfer außerdem einen konkreten Grund, die Aktion abzulehnen. Bei der Erstellung eines CNAMEs sollten kollidierende Daten unter diesem Owner-Namen angezeigt werden. Bei einer Bearbeitung sollte sichtbar sein, ob der aktuelle Zustand vom erwarteten Zustand abweicht. Bei einer Löschung sollte erkennbar sein, wenn die Bestätigung des Service-Eigentümers fehlt. Die Genehmigungsoberfläche sollte Unsicherheit offenlegen und nicht in einem Ausführungslog verstecken.

Mache Prüfer nicht zu einer manuellen Richtlinien-Engine, indem du ihnen ein großes Freitextfeld für Ausnahmen gibst. Wenn der Agent eine Aktion außerhalb der normalen Form anfordert, muss er eine neue Aktion mit den fehlenden Belegen vorbereiten. Ein Prüfer, der DNS-Semantik aus einem Chatverlauf rekonstruieren muss, wird irgendwann einen Fehler genehmigen.

Ein ausgearbeitetes Prüfbeispiel

Angenommen, ein Agent muss api.example.net auf eine Ersatzadresse umstellen. Eine schlechte Karte sagt: «DNS für die API aktualisieren.» Der Prüfer kann nicht erkennen, dass der Provider ein RRset mit zwei Mitgliedern ersetzen wird.

Eine prüfbare Bearbeitung lautet: «198.51.100.24 im A-RRset von api.example.net durch 198.51.100.81 ersetzen; 198.51.100.25 beibehalten; TTL 300 beibehalten.» Danach zeigt sie die vollständigen aktuellen und vorgeschlagenen RRsets, nennt den Service-Eigentümer und erklärt, dass der Agent nach dem Schreibvorgang den autoritativen Nameserver abfragt und die genehmigte Zustandsprüfung ausführt.

Wenn der Prüfer stattdessen eine Umschaltung ohne Überschneidung möchte, sollte er diese Karte ablehnen und die Absicht ausdrücklich anfordern. Der Agent darf nicht entscheiden, dass eine Überschneidung unnötig ist, nur weil seine Deployment-Dateien eine neue Adresse enthalten.

DNS-Caches machen den Zeitpunkt zu einem Teil der Genehmigung

Autoritatives DNS und rekursives DNS beantworten unterschiedliche operative Fragen. Der autoritative Server zeigt die aktuell veröffentlichten Zonendaten. Ein rekursiver Resolver kann eine frühere Antwort zurückgeben, bis die von ihm erhaltene TTL abläuft. Ein Browser, ein Betriebssystem, eine Laufzeitumgebung, ein Load Balancer oder ein interner Resolver kann einen weiteren Cache hinzufügen.

Die Genehmigung sollte deshalb den gewünschten Prüfpunkt nennen. «Die autoritativen Server liefern die neue Antwort» prüft den Schreibvorgang. «Ein öffentlicher Resolver liefert die neue Antwort» prüft einen Teil der Verbreitung. «Die Anwendung bedient Datenverkehr am neuen Ziel» prüft das von den Nutzern benötigte Ergebnis. Das sind getrennte Prüfungen.

Verwende Befehle, die die Quelle einer Antwort sichtbar machen. Ersetze Namen und Adresse durch den tatsächlichen autoritativen Server der Zone:

dig @ns1.example.net api.example.net A +noall +answer

; expected answer shape
api.example.net. 300 IN A 198.51.100.81

dig @1.1.1.1 api.example.net A +noall +answer

; resolver answer can retain an older value with a lower remaining TTL
api.example.net. 117 IN A 198.51.100.24

Die erste Abfrage prüft den veröffentlichten Zustand an einem autoritativen Server. Die zweite prüft, was ein rekursiver Resolver derzeit zurückgibt. Keine der beiden Abfragen beweist, dass jeder Client umgeschaltet hat. Speichere beide Ergebnisse im Aktionslog, damit ein Incident-Responder einen fehlgeschlagenen Provider-Schreibvorgang von erwartbarem Cache-Verhalten unterscheiden kann.

Nimm nicht an, dass eine TTL ein Countdown bis zur globalen Konsistenz ist. Ein Resolver erhält eine TTL, wenn er eine Antwort cached, daher beginnen verschiedene Resolver zu unterschiedlichen Zeitpunkten zu zählen. Einige Clients können außerdem Verbindungen offen halten oder Anwendungskonfiguration unabhängig vom DNS cachen. Ein Migrationsplan braucht eine Prüfung auf Dienstebene und darf sich nicht darauf beschränken, dass eine bestimmte Zahl von Sekunden vergangen ist.

Änderungen an DNS-Delegationen verlangen zusätzliche Sorgfalt. Das Bearbeiten von NS-, Glue-, DS- oder anderen delegationsbezogenen Einträgen kann die Auflösung über die untergeordnete Zone hinaus beeinflussen. Ein Agent sollte diese als eigene Änderungsklasse einordnen und einen Prüfer verlangen, der die Beziehung zwischen übergeordneter und untergeordneter Zone verantwortet. Führe sie nicht in einem gewöhnlichen Workflow für Host-Einträge zusammen.

Weitreichende DNS-Anmeldedaten sind die falsche Abkürzung

Einem Agenten ein Provider-Zugangstoken zu geben, mit dem er jede Zone bearbeiten kann, wirkt effizient, weil er seine Aufgabe ohne eine Integrationsänderung abschließen kann. Es ist dennoch die falsche Grenze. Eine Prompt-Injection, eine falsche Anweisung im Repository oder ein fehlerhafter Plan erhält dadurch weit mehr Rechte, als für den zu ändernden Dienst nötig wären.

Begrenze jeden Ausführungspfad auf die Zonen und Operationen, die er benötigt. Trenne Lese- und Schreibzugriff, wenn der Provider das erlaubt. Halte eine Zuordnung zwischen Repository- oder Service-Identität und den Zonen, die sie anfordern darf. Weise eine Anfrage für eine Zone außerhalb dieser Zuordnung zurück, bevor sie Provider-Anmeldedaten erreicht.

Die Grenze muss Aktionen beschränken und darf nicht nur ein Token verbergen. Ein Agent, der einen Vermittler auffordern kann, beliebige Provider-API-Anfragen zu senden, hat weiterhin weitreichende Kontrolle, wenn dieser Vermittler beliebige Pfade, Methoden, Header und Anfragekörper akzeptiert. Die Aktionsschicht sollte die Form des Provider-Aufrufs für DNS selbst bestimmen und Felder außerhalb ihres Schemas zurückweisen.

Hier verursachen allgemeine «upsert»-Endpunkte Probleme. Sie erlauben einem Agenten, Erstellung, Bearbeitung und Löschung in einem Anfragekörper zusammenzufassen, häufig mit Provider-Standards, die ein Prüfer nicht sieht. Definiere getrennte Ausführermethoden und lasse jede Methode die erforderlichen Belege der Aktion prüfen. Eine Löschmethode sollte einen Payload mit einem Ersatzzustand ablehnen. Eine Bearbeitungsmethode sollte einen fehlenden erwarteten Zustand ablehnen.

Halte DNS-Anmeldedaten außerhalb des Agent-Prozesses. Für Teams, die Sallyport verwenden, kann die App den HTTP-Aufruf ausführen, während die Anmeldedaten in ihrem verschlüsselten Tresor bleiben. Der Agent erhält dann nur das Ergebnis und nicht die Anmeldedaten. Das verhindert die Offenlegung von Zugangsdaten, entscheidet aber nicht darüber, ob eine vorgeschlagene DNS-Aktion sinnvoll ist. Diese Aufgabe übernehmen weiterhin das Aktionsschema und die Genehmigungsbelege.

Ein veralteter Plan kann den falschen aktiven Eintrag löschen

Ein häufiger Fehler beginnt damit, dass ein Agent zu Beginn einer langen Coding-Aufgabe DNS liest. Er sieht cdn.example.net mit einem CNAME-Ziel und plant, es nach einem Deployment zu ersetzen. Während der Agent arbeitet, ändert ein Bereitschaftstechniker das Ziel, um den Datenverkehr während eines Vorfalls umzuleiten.

Später beendet der Agent seine Arbeit und sendet den alten Änderungsantrag. Wenn sein Provider-Aufruf ein allgemeines Update oder eine unbedingte Sequenz aus Löschen und Erstellen verwendet, überschreibt er die Änderung des Bereitschaftstechnikers. Im Verhältnis zum Zustand, den der Agent Stunden zuvor beobachtet hat, kann die Anfrage korrekt aussehen. Im Verhältnis zur aktiven Zone ist sie falsch.

Frische Abfragen vor dem Schreibvorgang verhindern genau diesen Fehler. Der Ausführer liest das RRset, vergleicht es mit dem expected_rrset der Aktion und verweigert den Schreibvorgang, wenn das Ziel des Bereitschaftstechnikers abweicht. Die Ablehnung sollte beide Werte im Log behalten und dem Prüfer mitteilen, dass ein anderer Akteur den Eintrag geändert hat. Sie sollte keinen Zusammenführungsversuch unternehmen.

Das Zusammenführen von DNS-Daten verlangt Wissen über den Dienst. Zwei Adresswerte können eine beabsichtigte Kapazität, eine vorübergehende Überschneidung, eine geografische Aufteilung oder eine Notfallroute darstellen. Ein Agent kann daraus, dass er in einer Deployment-Datei nur eine Adresse erkennt, nicht sicher ableiten, welche Bedeutung die andere hat.

Dasselbe gilt nach einem Teilausfall. Wenn ein Provider eine Zeitüberschreitung meldet, muss der Ausführer vor einem erneuten Versuch den autoritativen Zustand beim Provider lesen. Der Schreibvorgang kann erfolgreich gewesen sein, obwohl der Client nie eine Antwort erhalten hat. Blinde Wiederholungen erzeugen bei manchen APIs doppelte Werte und führen bei anderen zu unerwünschten Ersetzungen.

Logs müssen das tatsächlich genehmigte beibehalten

Ein DNS-Audit-Eintrag braucht mehr als ein Provider-Ereignis, das lediglich meldet, dass sich ein Eintrag geändert hat. Speichere die vorgeschlagene Aktion, den vor der Ausführung beobachteten Zustand, die Genehmigungsentscheidung, den anfordernden Prozess, die Provider-Antwort und die Prüfergebnisse. Bewahre genug Daten auf, um zu rekonstruieren, ob der Ausführer der genehmigten Anfrage gefolgt ist.

Ein manipulationssicheres Log bietet einen zusätzlichen Nutzen: Wer einen Vorfall untersucht, kann prüfen, ob die Historie nachträglich verändert wurde. Das ist wichtig, wenn DNS-Antworten bereits aus Caches verschwunden sind und sich Menschen auf Erinnerungen oder Screenshots verlassen. Die Belege sollten auch ohne das ursprüngliche Agent-Gespräch verständlich bleiben.

Trenne den Laufdatensatz vom Aufrufdatensatz. Ein Laufdatensatz beantwortet die Frage, welcher Agent-Prozess wann Berechtigungen erhalten hat und wann diese endeten. Ein Aufrufdatensatz beantwortet, welche genaue DNS-Aktion er angefordert hat, ob jemand sie genehmigt hat und was passiert ist. Der sofortige Widerruf eines Laufs sollte spätere Aufrufe stoppen, kann aber einen bereits vom Provider angenommenen DNS-Schreibvorgang nicht rückgängig machen. Die Audit-Spur muss diese Grenze klar zeigen.

Verwende Aktions-IDs sowohl auf der Genehmigungskarte als auch im Ausführungsdatensatz. Wenn ein Betreiber ein fehlerhaftes Ergebnis sieht, sollte er die genaue genehmigte Löschung oder Bearbeitung finden können, ohne einen undifferenzierten Strom von Agent-Ausgaben durchsuchen zu müssen. Die ID sollte Anfrage, Zustandsvergleich, Provider-Antwort und Prüfungsbefehle miteinander verbinden.

Die erste praktische Änderung ist klein: Verbiete allgemeine DNS-Schreibvorgänge an der Genehmigungsgrenze. Zwinge jede Anfrage in die Form Erstellen, Bearbeiten oder Löschen, verlange bei Bearbeitungen und Löschungen das vollständige erwartete RRset und weise Abweichungen vor der Ausführung zurück. Diese eine Einschränkung macht die vorgeschlagene DNS-Arbeit eines Agenten lesbar genug, damit ein Mensch die wichtigen Fehler erkennt.