Connecting DNS providers: Cloudflare, Hetzner, IONOS

Connecting DNS providers

Under Settings → Integrations (owners and admins) you choose the provider, enter the credentials and save. DomainWarn does not only check whether the credentials are valid but whether they may write: depending on the provider via the permissions of the token or via a short-lived probe record _domainwarn-verify-… that is deleted right away; at netcup only the login, because the credentials cover the whole account anyway. Credentials are stored encrypted and never shown again; creating, verifying and deleting are recorded in the audit log.

Nine providers are connected. For all of them: zone import and records in one click; DomainWarn only writes if all name servers of the domain point to the provider at the moment of the click. Suggestions for missing records (DMARC, SPF, TLS-RPT, CAA) are only created, never written over existing records. For hosted features (MTA-STS, BIMI, security.txt, see below) DomainWarn additionally updates the records it set up itself; foreign ones are only replaced after explicit confirmation, nothing is ever deleted.

Cloudflare: API token with Zone:DNS:Edit and Zone:Zone:Read, ideally from the "Edit zone DNS" template and limited to the client zones. Optionally for the hosted security.txt "Account → Workers Scripts → Edit" and "Zone → Workers Routes → Edit" (a Worker serves the file directly on the domain), as a fallback "Zone → Single Redirect → Edit" (redirect). The token can be revoked in Cloudflare at any time.
Hetzner DNS: API token of a project in the Hetzner Console with "Read & Write"; a read-only token is rejected. Hetzner tokens cannot be limited to DNS, the token may do anything in the project: therefore create a dedicated project for DNS zones only. Zones from the old DNS Console must have been migrated to the Hetzner Console.
IONOS: API key from the Developer Portal, consisting of public prefix and secret (visible only once). The key covers every zone of the account and cannot be limited to zones or to DNS; DomainWarn proves write access with a probe record.
netcup: customer number, Legacy API key and Legacy API password from the CCP under Master data → API (not the login password). There are no per-zone permissions. netcup provides a zone list to domain resellers only; other accounts import via list or zone file. Applies to classic DNS, not to CloudDNS.
INWX: username and password of a sub-account with the "DNS management" role and without two-factor authentication, because the API cannot log in without a TAN. The sub-account can be locked in the customer centre at any time.
OVHcloud: the region of the account (Europe, Canada or USA – name servers on .ovh.us belong to OVHcloud US) and the three keys from the createToken page of that region: application key, application secret and consumer key. The rights GET /domain/zone plus GET, POST, PUT and DELETE on /domain/zone/* are enough; domains, servers and invoices stay out of reach. OVHcloud only activates changes once the zone is refreshed, which DomainWarn triggers itself after every create, change or delete. Records entered as SPF, DKIM or DMARC in the control panel count as TXT records.
Amazon Route 53: access key ID and secret access key of an IAM user without console access with an inline policy that allows only route53:ListHostedZones, route53:ListHostedZonesByName, route53:ListResourceRecordSets and route53:ChangeResourceRecordSets, restricted to individual hosted zones where possible. Temporary keys with a session token are not supported.
deSEC: a token from desec.io/tokens. Without a policy it may change every domain of the account; therefore create a default policy without write access and, for each domain DomainWarn should manage, a policy with write access. The domain must use the name servers ns1.desec.io and ns2.desec.org. Other values under the same name stay, DomainWarn extends the RRset; new RRsets get at least the minimum TTL of the domain (usually 3600 seconds). On rate limits DomainWarn waits briefly and reports longer blocks instead of retrying endlessly.
autoDNS (InterNetX): user and password of a dedicated autoDNS user that may only view and edit zones (Zone Info and Zone Update tasks), plus the context: 4 for the live system, your own number for PersonalAutoDNS; empty means 4. Two-factor authentication must be off for this user. A switch connects to the InterNetX demo system (demo accounts only). Name servers *.ns14.net and *.domain-robot.org.

Zone backup

If the name servers of a domain point entirely to a connected provider, DomainWarn reads the zone through its API every night – all records with TTL, including the ones nobody sees from outside: internal names, service records, verifications. A new state is only stored when something changed; otherwise DomainWarn confirms the last one. States are kept as long as the history of your plan, at least the last ten per domain. All six providers return the zone as a whole; netcup has no TTL per record, and Route 53 alias entries are left out.

You find the backup in the DNS tab of the domain under “Zone backup”: on the left the selected state with the changes since the previous one (green added, red removed, yellow changed) and all records, on the right the states and “Back up now”. Every state can be downloaded as a BIND zone file or JSON, for example for a provider change or as a copy for the client.

Restoring: selected records, “Undo” on a single change (restores the previous state of that name and type) or “Whole zone to this state” (all differences in one run, at most 200 changes). DomainWarn creates missing values, deletes surplus ones and changes differing ones – only after confirmation, with freshly checked name servers, and with an entry in the audit log and the timeline. Records that were behind the Cloudflare proxy have to be restored by hand, because DomainWarn always creates records without the proxy.
Notifications: changes appear in the timeline of the domain. The backup only notifies for records the outside monitoring cannot see – MX, SPF, DMARC and the other monitored records are already reported by change detection, the backup does not duplicate that. If a change affects MX, name servers, SPF or DMARC and change detection has not reported it yet, the entry is a warning.
Permissions: everyone with access to the domain can view and export states, client accounts included; owners, admins and members can back up now and restore. Without a connected integration or with another provider, the page says what is missing.

Zone file

The import from a BIND zone file needs no integration: export the zone file from Plesk, Cloudflare, IONOS or Hetzner, paste it, select host names. How DomainWarn reads the file and which names it leaves out is described in Getting started.