DNS-Anbieter

Cloudflare, Hetzner, IONOS, netcup, INWX, OVHcloud, Route 53, deSEC und autoDNS verbinden: welche Zugangsdaten nötig sind und welche Rechte sie brauchen.

Auf dieser Seite

DNS-Anbieter verbinden

Unter Einstellungen → Integrationen (Owner und Admins) wählst du den Anbieter, gibst die Zugangsdaten ein und speicherst. DomainWarn prüft dabei nicht nur, ob die Zugangsdaten gelten, sondern ob sie schreiben dürfen: je nach Anbieter über die Berechtigungen des Tokens oder über einen kurzlebigen Probe-Record _domainwarn-verify-…, der sofort wieder gelöscht wird; bei netcup nur die Anmeldung, weil die Zugangsdaten ohnehin für das ganze Konto gelten. Zugangsdaten werden verschlüsselt gespeichert und nie wieder angezeigt; Anlegen, Prüfen und Löschen stehen im Audit-Log.

Neun Anbieter sind angebunden. Bei allen gilt: Zonen-Import und Records per Klick; DomainWarn schreibt nur, wenn alle Nameserver der Domain zum Zeitpunkt des Klicks auf den Anbieter zeigen. Vorschläge für fehlende Records (DMARC, SPF, TLS-RPT, CAA) werden nur angelegt, nie über bestehende Records geschrieben. Bei den gehosteten Funktionen (MTA-STS, BIMI, security.txt, siehe unten) aktualisiert DomainWarn zusätzlich die Records, die es selbst eingerichtet hat, und räumt doppelte eigene auf; fremde ersetzt oder löscht es nur nach ausdrücklicher Bestätigung, und die Vorschau zeigt vorher genau, was gelöscht würde.

  • Cloudflare: API-Token mit Zone:DNS:Edit und Zone:Zone:Read, am besten aus der Vorlage „DNS bearbeiten“ und auf die Zonen der Kunden begrenzt. Optional für die gehostete security.txt „Konto → Workers Scripts → Edit“ und „Zone → Workers Routes → Edit“ (ein Worker liefert die Datei direkt unter der Domain aus), als Rückfall „Zone → Single Redirect → Edit“ (Weiterleitung). Das Token lässt sich in Cloudflare jederzeit widerrufen.
  • Hetzner DNS: API-Token eines Projekts in der Hetzner Console mit „Lesen & Schreiben“; ein Nur-Lesen-Token wird abgelehnt. Hetzner-Tokens lassen sich nicht auf DNS beschränken, das Token darf alles im Projekt: deshalb ein eigenes Projekt nur für DNS-Zonen anlegen. Zonen der alten DNS Console müssen in die Hetzner Console übernommen sein.
  • IONOS: API-Schlüssel aus dem Developer Portal, bestehend aus öffentlichem Präfix und Geheimnis (nur einmal sichtbar). Der Schlüssel gilt für alle Zonen des Kontos und lässt sich weder auf Zonen noch auf DNS einschränken; DomainWarn belegt das Schreibrecht mit einem Probe-Record.
  • netcup: Kundennummer, Legacy-API-Key und Legacy-API-Passwort aus dem CCP unter Stammdaten → API (nicht das Login-Passwort). Es gibt keine Berechtigung je Zone. Eine Zonenliste liefert netcup nur Domain-Resellern; andere Konten importieren per Liste oder Zonendatei. Gilt für das klassische DNS, nicht für CloudDNS.
  • INWX: Benutzername und Passwort eines Unterkontos mit der Rolle „DNS-Verwaltung“ und ohne Zwei-Faktor-Authentifizierung, weil die API ohne TAN nicht anmelden kann. Das Unterkonto lässt sich im Kundencenter jederzeit sperren.
  • OVHcloud: Region des Kontos (Europa, Kanada oder USA – Nameserver auf .ovh.us gehören zu OVHcloud US) und die drei Schlüssel von der createToken-Seite der Region: Application Key, Application Secret und Consumer Key. Als Rechte genügen GET /domain/zone sowie GET, POST, PUT und DELETE auf /domain/zone/*; Domains, Server und Rechnungen bleiben außen vor. OVHcloud aktiviert Änderungen erst mit einer Aktualisierung der Zone, die DomainWarn nach jedem Anlegen, Ändern oder Löschen selbst auslöst. Records, die im Kundencenter als SPF, DKIM oder DMARC angelegt sind, zählen als TXT-Records.
  • Amazon Route 53: Access Key ID und Secret Access Key eines IAM-Benutzers ohne Konsolenzugang mit einer Inline-Richtlinie, die nur route53:ListHostedZones, route53:ListHostedZonesByName, route53:ListResourceRecordSets und route53:ChangeResourceRecordSets erlaubt, nach Möglichkeit auf einzelne Hosted Zones begrenzt. Temporäre Schlüssel mit Sitzungstoken werden nicht unterstützt.
  • deSEC: ein Token aus desec.io/tokens. Ohne Richtlinie darf es alle Domains des Kontos ändern; deshalb eine Standard-Richtlinie ohne Schreibrecht anlegen und je Domain, die DomainWarn verwalten soll, eine Richtlinie mit Schreibrecht. Die Domain muss die Nameserver ns1.desec.io und ns2.desec.org nutzen. Weitere Werte unter demselben Namen bleiben stehen, DomainWarn ergänzt das RRset; neue RRsets bekommen mindestens die Mindest-TTL der Domain (meist 3600 Sekunden). Bei Ratenlimits wartet DomainWarn kurz und meldet längere Sperren, statt es endlos zu versuchen.
  • autoDNS (InterNetX): Benutzer und Passwort eines eigenen autoDNS-Benutzers, der nur Zonen anzeigen und bearbeiten darf (Aufträge Zone Info und Zone Update), dazu der Kontext: 4 für das Live-System, bei PersonalAutoDNS die eigene Nummer; leer gilt 4. Zwei-Faktor-Authentifizierung muss für diesen Benutzer aus sein. Ein Schalter verbindet mit dem Demo-System von InterNetX (nur für Demo-Konten). Nameserver *.ns14.net und *.domain-robot.org.

Siehe auch: Übersicht der Integrationen

Zonen-Backup

Liegt die Zone einer Domain laut Nameservern vollständig bei einem verbundenen Anbieter, liest DomainWarn sie jede Nacht über dessen API – alle Records mit TTL, auch die, die von außen niemand sieht: interne Namen, Service-Records, Verifizierungen. Ein neuer Stand entsteht nur, wenn sich etwas geändert hat; sonst bestätigt DomainWarn den letzten. Aufbewahrt wird so lange wie der Verlauf im Tarif, mindestens die letzten zehn Stände je Domain. Alle sechs Anbieter liefern die Zone als Ganzes; netcup kennt keine TTL je Record, bei Route 53 fehlen Alias-Einträge.

Du findest das Backup im Reiter DNS der Domain unter „Zonen-Backup“: links der gewählte Stand mit den Änderungen zum vorigen (grün hinzugefügt, rot entfernt, gelb geändert) und allen Records, rechts die Stände und „Jetzt sichern“. Jeder Stand lässt sich als BIND-Zonendatei oder JSON herunterladen, etwa für einen Anbieterwechsel oder als Ablage beim Kunden.

  • Wiederherstellen: ausgewählte Records, „Rückgängig“ an einer einzelnen Änderung (stellt den vorigen Stand dieses Namens und Typs her) oder „Ganze Zone auf diesen Stand“ (alle Unterschiede in einem Lauf, höchstens 200 Änderungen). DomainWarn legt fehlende Werte an, löscht überzählige und ändert abweichende – erst nach Bestätigung, mit frisch geprüften Nameservern, und mit Eintrag im Audit-Log und in der Zeitleiste. Records, die bei Cloudflare hinter dem Proxy standen, stellst du von Hand wieder her, weil DomainWarn Records immer ohne Proxy anlegt.
  • Meldungen: Änderungen stehen in der Zeitleiste der Domain. Eine Benachrichtigung schickt das Backup nur für Records, die die Überwachung von außen nicht sieht – MX, SPF, DMARC und die übrigen überwachten Records meldet schon die Änderungserkennung, das Backup doppelt das nicht. Betrifft eine Änderung MX, Nameserver, SPF oder DMARC und hat die Änderungserkennung dazu noch nichts gemeldet, ist der Eintrag eine Warnung.
  • Rechte: Stände ansehen und exportieren dürfen alle mit Zugriff auf die Domain, auch Kundenzugänge; „Jetzt sichern“ und Wiederherstellen Owner, Admins und Mitglieder. Ohne verbundene Integration oder bei einem anderen Anbieter sagt die Seite, was fehlt.

Siehe auch: Domain- und DNS-Checks

Zonendatei

Der Import aus einer BIND-Zonendatei braucht keine Integration: Zonendatei aus Plesk, Cloudflare, IONOS oder Hetzner exportieren, einfügen, Hostnamen auswählen. Wie DomainWarn die Datei liest und welche Namen es weglässt, steht bei den ersten Schritten.

Siehe auch: Import aus einer Zonendatei