Dieses Rezept eignet sich für produktive Änderungen, bei denen du eine bestehende RRID kennst und jede Änderung kontrolliert durchführen willst. 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 du den alten Zustand für den Rollback speichern kannst

Schritt 1: Ausgangszustand lesen

Vor jeder Änderung liest du den bestehenden Record aus und speicherst 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, spielst du 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 liest du den Record erneut. So erkennst du sofort, ob der Zielwert wirklich geschrieben wurde und ob du mit der erwarteten RRID gearbeitet hast.

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

Prüfe 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, spielst du 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 du keine RRID gespeichert hast und genau ein Record über name und type identifizierbar ist, kannst du 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

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

Ergebnis

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