DNS, E-Mail und Webhooks

Diese Integrationen liefern Änderungen und Ereignisse von Opfield an externe Systeme: DNS-Anbieter, Mailserver und Webhook-Empfänger. Geben Sie jedem Zugangsdaten mit minimalen Rechten und bestätigen Sie die Zustellung auf der Empfängerseite: Dass Opfield eine Änderung annimmt, beweist nicht, dass Resolver, Postfächer oder Webhook-Verbraucher sie erhalten haben.

Folgen Sie für die Einrichtung des DNS-Connectors der eigenen Cloudflare-Anleitung. E-Mail sowie Benachrichtigungs- und Deployment-Webhooks sind separate Integrationsoberflächen, keine Hosting-Konten.

Die E-Mail-Konfiguration unterstützt Authentifizierungsabläufe und, sofern aktiviert, die Zustellung von Benachrichtigungen. Testen Sie Absenderidentität, TLS, Zustellbarkeit und Ratenbegrenzungen, bevor Sie sich auf Einmalcodes per E-Mail verlassen.

Webhooks können unterstützte Deployment- oder Automatisierungsabläufe auslösen. Verwenden Sie generierte Secrets, prüfen Sie Signaturen, machen Sie Empfänger idempotent und unterscheiden Sie eine angenommene Operation von einem abgeschlossenen Deployment. Geben Sie in Webhook-Antworten keine internen Daemon-Fehler oder Zugangsdaten zurück.

DNS-Connectoren

Verwenden Sie ein eigenes Cloudflare-Token, das auf das vorgesehene Konto, die vorgesehenen Zonen und DNS-Berechtigungen beschränkt ist. Prüfen Sie die für dieses Token sichtbaren Zonen, bevor Sie verwaltete Einträge oder DNS-01-Challenges aktivieren. Opfield sollte nur für Einträge zuständig sein, die ausdrücklich an verwaltete Domains angehängt sind; unbeteiligte Einträge bleiben externer Zustand.

Halten Sie bei einer Migration die aktuellen Werte und die TTL fest, bestätigen Sie die Ziel-Ingress-Adresse, wenden Sie die Änderung an und prüfen Sie die Auflösung über unabhängige öffentliche Resolver. Löschen Sie den alten Endpunkt erst, wenn Kundenverkehr die neue Platzierung erreicht.

E-Mail

Konfigurieren Sie Absenderidentität, SMTP-Host, Port, TLS-Modus und Authentifizierung gemäß dem Anbieter unter Settings > Advanced > SMTP configuration. Senden Sie eine Testnachricht und prüfen Sie das tatsächliche Postfach, die Spam-Einstufung, die SPF/DKIM/DMARC-Ausrichtung und die Ratenbegrenzungen des Anbieters.

Sind Einmalcodes per E-Mail aktiviert, halten Sie einen weiteren Wiederherstellungsweg für Administratoren bereit. Eine erfolgreiche SMTP-Verbindung beweist nicht, dass Benutzer Authentifizierungsnachrichten empfangen können.

Benachrichtigungs-Webhooks

1. Erstellen Sie einen HTTPS-Empfänger mit begrenzter Anfragegröße und begrenztem Timeout.
2. Konfigurieren Sie Authentifizierung oder HMAC-Signierung.
3. Senden Sie ein Testereignis und prüfen Sie die Signatur gegen den rohen Anfrageinhalt.
4. Liefern Sie erst dann eine deterministische Erfolgsantwort, wenn der Empfänger das Ereignis dauerhaft angenommen hat.
5. Machen Sie Wiederholungen mit der Ereignis- oder Zustellkennung idempotent.
6. Überwachen Sie Zustellverlauf, Latenz, Wiederholungen und endgültige Fehlschläge.

Deployment-Webhooks

Behandeln Sie die Zustellung eines Webhooks als Anfrage, ein Quellereignis zu bewerten, nicht als Beweis für ein Deployment. Prüfen Sie die Signatur des Anbieters, die Repository-Allowlist, die Branch- oder Tag-Richtlinie, den aufgelösten Commit, die Build-Zulassung und den abschließenden Deployment-Task unabhängig voneinander.

Rotieren Sie Connector- und Webhook-Secrets, indem Sie den Ersatz installieren, ihn prüfen und dann den alten Wert widerrufen. Legen Sie nicht vertrauenswürdigen Aufrufern keine vollständigen Empfängerantworten, Anbieter-Zugangsdaten oder internen Daemon-Fehler offen.

Fehlerbilder und Wiederherstellung

DNS-Fehler entstehen häufig durch das falsche Konto oder die falsche Zone, unzureichende Token-Berechtigungen, veraltete Resolver-Caches, einen unerwarteten Proxy- oder CDN-Modus oder einen Challenge-Eintrag, der öffentlich nicht beobachtet werden kann. Vergleichen Sie den Eintrag in Opfield mit der Antwort des autoritativen Nameservers und mindestens eines unabhängigen Resolvers. Stellen Sie während einer Migration den festgehaltenen vorherigen Wert wieder her, wenn der neue Endpunkt nicht vor der vereinbarten Rollback-Frist geprüft werden kann.

Die E-Mail-Zustellung hat mehrere unabhängige Phasen: Opfield hat die Nachricht angenommen, der SMTP-Anbieter hat sie angenommen, das empfangende System hat sie angenommen, und der Benutzer kann sie finden. Prüfen Sie jede Phase, bevor Sie die Authentifizierungsrichtlinie ändern. Ist die Zustellung von Einmalcodes beeinträchtigt, halten Sie den getesteten alternativen Administratorzugang verfügbar und vermeiden Sie wiederholte Code-Anforderungen, die eine Drosselung beim Anbieter auslösen.

Webhook-Fehler erfordern den Zustelleintrag, die Anzahl der Versuche, die Antwortklasse und die Korrelations-ID auf der Empfängerseite. Eine 2xx-Antwort sollte bedeuten, dass der Empfänger das Ereignis dauerhaft angenommen hat; die Verarbeitung kann asynchron weiterlaufen. Lassen Sie den Empfänger bei wiederholbaren Fehlern anhand der Zustell- oder Ereignis-ID deduplizieren. Rotieren Sie bei endgültigen Authentifizierungsfehlern das gemeinsame Secret oder den Signaturschlüssel und prüfen Sie beide Seiten, bevor Sie begrenzt fehlgeschlagene Zustellungen erneut senden.

Sicherheitsgrenzen

Verwenden Sie HTTPS-Endpunkte ohne Zugangsdaten in der URL. Beschränken Sie ausgehende Ziele auf die erwarteten öffentlichen Hosts oder ausdrücklich freigegebene private CIDRs. Empfänger müssen Zeitstempel bzw. Wiederholungsfenster prüfen, wo die Integration es unterstützt, Signaturen in konstanter Zeit vergleichen, die Anfragegröße begrenzen und Anfrageinhalte nicht in Fehlerantworten zurückspiegeln.

Tokens von DNS- und E-Mail-Anbietern sind administrative Zugangsdaten, auch wenn Opfield sie verschlüsselt speichert. Lassen Sie das Audit beim Anbieter aktiviert, prüfen Sie ihren Geltungsbereich regelmäßig und widerrufen Sie das alte Token erst, nachdem der Ersatz eine echte Testoperation abgeschlossen hat.

Dokumentieren Sie für geschäftskritische Authentifizierung oder Benachrichtigung einen alternativen Kommunikations- und Wiederherstellungsweg für Administratoren. Erfolg und Latenz externer Anbieter liegen außerhalb der Verfügbarkeitsgrenze von Opfield; machen Sie daher keinen einzelnen ungetesteten Anbieter zum einzigen Weg, auf die Installation zuzugreifen oder sie zu betreiben.