DNS-Record sicher ändern mit Prüfung und Rollback

Dieses Rezept eignet sich für produktive Änderungen, bei denen Sie eine bestehende RRID kennen und jede Änderung kontrolliert durchführen wollen. Der Ablauf besteht aus Snapshot, Änderung, Verifikation und Rollback-Option.

Voraussetzungen

ein API-Key mit Zugriff auf DNS-Endpunkte
die rrid des zu ändernden Records
ein klar definiertes Ziel für die Änderung, zum Beispiel neue Ziel-IP oder neues CNAME-Ziel
ein Ort, an dem Sie den alten Zustand für den Rollback speichern können

Schritt 1: Ausgangszustand lesen

Vor jeder Änderung lesen Sie den bestehenden Record aus und speichern dessen Inhalt. Dieser Snapshot ist die Grundlage für die spätere Prüfung und einen möglichen Rückweg.

curl --request GET \
  --url 'https://api.regfish.com/dns/rr/4711' \
  --header 'x-api-key: YOUR_API_KEY'

Ein typischer Snapshot sieht so aus:

{
  "success": true,
  "response": {
    "id": 4711,
    "type": "A",
    "name": "api.example.com.",
    "data": "203.0.113.10"
  }
}

Schritt 2: Geplante Änderung anwenden

Sobald der Ausgangszustand gesichert ist, spielen Sie die gewünschte Änderung per RRID ein. Dieser Weg ist präziser als die automatische Erkennung über name und type.

curl --request PATCH \
  --url 'https://api.regfish.com/dns/rr/4711' \
  --header 'content-type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  --data '
{
  "type": "A",
  "name": "api",
  "data": "203.0.113.20",
  "ttl": 300,
  "annotation": "change-ticket-2026-03-17"
}
'

Schritt 3: Ergebnis direkt verifizieren

Nach dem Update lesen Sie den Record erneut. So erkennen Sie sofort, ob der Zielwert wirklich geschrieben wurde und ob Sie mit der erwarteten RRID gearbeitet haben.

curl --request GET \
  --url 'https://api.regfish.com/dns/rr/4711' \
  --header 'x-api-key: YOUR_API_KEY'

Prüfen Sie dabei insbesondere:

ob id unverändert geblieben ist
ob data dem Zielwert entspricht
ob ttl und optionale Annotationen korrekt gesetzt wurden

Schritt 4: Bei Bedarf Rollback ausführen

Wenn der neue Wert nicht passt oder sich ein Folgeproblem zeigt, spielen Sie den vorherigen Zustand mit denselben Feldern zurück.

curl --request PATCH \
  --url 'https://api.regfish.com/dns/rr/4711' \
  --header 'content-type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  --data '
{
  "type": "A",
  "name": "api",
  "data": "203.0.113.10",
  "ttl": 300,
  "annotation": "rollback-change-ticket-2026-03-17"
}
'

Alternative: Änderung über den Auto-Endpunkt

Wenn Sie keine RRID gespeichert haben und genau ein Record über name und type identifizierbar ist, können Sie auch den Auto-Endpunkt verwenden. Für produktive Änderungen mit mehreren ähnlichen Records ist der RRID-Weg aber robuster.

curl --request PATCH \
  --url 'https://api.regfish.com/dns/rr' \
  --header 'content-type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  --data '
{
  "type": "A",
  "name": "api.example.com.",
  "data": "203.0.113.20"
}
'

Praxishinweise für produktive Abläufe

sichern Sie vor jeder Änderung den kompletten Altzustand inklusive type, name, ttl und data
verwenden Sie RRIDs für produktive Änderungen, sobald es mehrere ähnliche Records geben kann
ergänzen Sie Annotationen mit Ticket-, Job- oder Deploy-Referenzen
verifizieren Sie Änderungen unmittelbar nach dem Schreiben und nicht erst verzögert
halten Sie den Rollback-Payload bereits vor dem eigentlichen Update bereit

Ergebnis

Mit diesem Ablauf behandeln Sie DNS-Änderungen wie eine kontrollierte Betriebsänderung statt wie einen einzelnen Schreibzugriff. Das senkt das Risiko und macht Rollbacks im Fehlerfall sofort möglich.