Read-Only Provider API Credentials
ZoneWatcher only needs read access to your DNS records. Many providers support read-only API credentials, which we recommend using to follow the principle of least privilege.
Why Use Read-Only Credentials?
For monitoring-only use, ZoneWatcher reads your DNS records but never modifies them. By using read-only API credentials, you ensure that even if credentials were compromised, no changes could be made to your DNS configuration. We strongly recommend using the most restrictive credentials available for your provider.
When You Need a Write-Enabled Token
Read-only credentials are not sufficient if you plan to use ZoneWatcher's Change Management or rollback features. Both features write back to your provider on your behalf — submitting approved changesets, and reverting unauthorized changes — so the API token must have permission to create, update, and delete DNS records.
The table below shows the read-only mechanism each provider supports for monitoring, alongside the write-enabled equivalent you'll need if you turn on Change Management or rollback. If you only want change notifications, use the read-only column. If you want ZoneWatcher to apply or revert changes for you, use the write-enabled column.
OAuth providers (DigitalOcean, DNSimple, Linode): ZoneWatcher's OAuth integrations currently request read-only scopes only, so Change Management and rollback are not available for those providers today. Reach out to support if you need this.
Provider Support
The table below shows which DNS providers support read-only API credentials and how to configure them.
| Provider | Read-Only Support | Read-Only Mechanism (monitoring) | Write-Enabled (Change Management & rollback) |
|---|---|---|---|
| AWS Route 53 | Yes | IAM policy: AmazonRoute53ReadOnlyAccess |
IAM policy: AmazonRoute53FullAccess (or a custom policy granting route53:ChangeResourceRecordSets + route53:GetChange) |
| Alibaba Cloud | Yes | RAM policy: AliyunDNSReadOnlyAccess |
RAM policy: AliyunDNSFullAccess |
| Ascio | No | Single username/password, no permission scoping | — |
| Atom | No | No documented permission scoping | — |
| Azure | Yes | RBAC Reader role |
RBAC DNS Zone Contributor role |
| Azure Private DNS | Yes | RBAC Reader role |
RBAC Private DNS Zone Contributor role |
| Bunny DNS | No | API keys have selectable permissions but DNS read-only scope is not documented | — |
| CSC Global | Yes | Service accounts with READ permission level (managed by CSC) | Service account with UPDATE permission (must be requested from CSC) |
| Civo | No | Team roles exist but API key scoping for DNS is unclear | — |
| ClouDNS | Yes | API sub-users with "Read only" access level | API sub-users with "Modify only" or "Full access" level |
| CloudFlare | Yes | Scoped API token with Zone:DNS:Read permission |
Scoped API token with Zone:DNS:Edit + Zone:Zone:Read |
| Contabo | Yes | RBAC roles restricting to GET methods per endpoint | Role allowing POST/PUT/DELETE on the DNS endpoints |
| DNS Made Easy | No | RBAC roles exist but API key scoping to read-only is unclear | — |
| Digicert UltraDNS | No | — | |
| Digital Ocean | Yes | OAuth scope: read (currently the only scope ZoneWatcher requests) |
Not supported via OAuth today — ZoneWatcher only requests read scope |
| Dnsimple | Yes | OAuth scope: read-only (currently the only scope ZoneWatcher requests) | Not supported via OAuth today — ZoneWatcher only requests read-only scope |
| Dreamhost | Yes | Per-command API key permissions (allow only dns-list_records) |
Allow dns-add_record and dns-remove_record in addition to dns-list_records |
| Dynadot | No | Single API key, IP allowlist only | — |
| EasyDNS | No | Single token and key pair, no permission scoping | — |
| Gandi | No | PAT scoping exists but DNS permission does not split read/write | — |
| Gcore | Yes | Role-based API tokens with Viewer role |
Role-based API tokens with Administrators (or a custom DNS Manager) role |
| Go Daddy | No | No documented read-only API key scoping | — |
| Google Cloud | Yes | IAM roles/dns.reader role |
IAM roles/dns.admin role |
| Hetzner | Yes | API tokens with Read permission level |
API tokens with Read & Write permission level |
| Hostinger | No | Token permissions exist but scopes are not documented | — |
| Huawei Cloud | Yes | IAM policy: DNS ReadOnlyAccess |
IAM policy: DNS FullAccess |
| IBM Cloud | Yes | IAM Reader / Viewer roles |
IAM Manager role on the DNS Services instance |
| IONOS | Yes | IAM roles with read-only as default | Role with the dns-change privilege (Contract Owner / DNS Admin) |
| Interserver | No | cPanel API tokens, no permission scoping | — |
| Katapult | Yes | Scoped API token permissions | Scoped API token with DNS zone write permissions |
| LeaseWeb | Yes | API keys restricted to GET method only | API keys allowing POST, PUT, and DELETE on DNS endpoints |
| Linode | Yes | OAuth scope: domains:read_only (currently the only scope ZoneWatcher requests) |
Not supported via OAuth today — ZoneWatcher only requests domains:read_only |
| Markmonitor | No | Granular permissions mentioned but not publicly documented | — |
| NS1 | Yes | API key with view_zones permission |
API key with manage_zones permission |
| Name.com | No | Single token, no scopes | — |
| NameSilo | Yes | Read-only checkbox on API key generation | Generate the API key with the read-only checkbox unchecked |
| Namecheap | No | Single API key, IP allowlist only | — |
| Netlify | No | No scope support for access tokens | — |
| No-IP | No | — | |
| OVH | Yes | Consumer Key access rules restricted to GET methods | Consumer Key access rules adding POST / PUT / DELETE on /domain/zone/* |
| Oracle Cloud | Yes | IAM policy with read verb |
IAM policy with the manage verb on dns |
| Porkbun | No | Single API key pair, no scoping | — |
| PowerDNS | Yes | Server-wide api-readonly configuration flag |
Set api-readonly=no on the authoritative server |
| Rackspace | Yes | RBAC Observer role |
RBAC DNS Admin role |
| Scaleway | Yes | IAM policies with ReadOnly permission sets | IAM policy with the DomainsDNSFullAccess permission set |
| Spaceship | Yes | API key scope: dnsrecords:read |
API key scope: dnsrecords:write (combined with dnsrecords:read) |
| Vercel | No | Tokens are team-scoped only, no granular permissions | — |
| Vultr | No | DNS ACL is all-or-nothing (read and write) | — |
| Wix | No | Scoped permissions exist but DNS read-only scope is not confirmed | — |
| deSEC | Yes | Token policies; all tokens can read, write permissions are configurable | Token policy with perm_write enabled |
| eNom | No | Multiple tokens but no permission scoping | — |
Providers Without Read-Only Support
For providers that do not support read-only credentials, we recommend using a dedicated API key that is only used by ZoneWatcher. Some providers offer IP allowlisting as an alternative security measure, which you can configure to only allow requests from ZoneWatcher's IP addresses.
Alternative: Public DNS and AXFR Monitoring
If your provider does not support read-only API credentials and you are not comfortable granting full API access, ZoneWatcher offers two alternative monitoring methods that require no provider API credentials at all:
- Public DNS — monitors your domains by querying public DNS resolvers directly. No API credentials needed. This method can detect changes to any publicly visible DNS records, though it is limited to records that are discoverable through public queries.
- Zone Transfer Protocol (AXFR) — fetches a complete copy of your DNS zone directly from your authoritative nameserver using the AXFR protocol. This requires your nameserver to be configured to allow zone transfers from ZoneWatcher's IP addresses, but does not require any provider API credentials.