Troubleshooting

Provider credentials rejected

Symptoms: Provider status shows "Error" with a message about invalid credentials or access denied.

Solutions:

• Verify the credentials haven't expired or been rotated
• Check that the IAM user/service account has the required permissions (see Provider Setup Guides)
• For AWS Route 53, ensure the access key is active in the IAM console
• For Cloudflare, verify the API token hasn't been revoked
• For Azure DNS, check the service principal's client secret hasn't expired
• For Google Cloud DNS, ensure the service account key is still valid

To update credentials, go to Settings → Providers, select the provider, and enter new credentials.

Zones not appearing after provider connection

Symptoms: Provider shows "Active" status but no zones are listed.

Solutions:

• Wait 1–2 minutes — zone discovery runs asynchronously after the provider is connected
• Check the provider's zone count on the Providers page
• Verify the credentials have permission to list zones (not just read records)
• For Route 53, ensure the IAM policy includes route53:ListHostedZones
• For Cloudflare, ensure the token has Zone:Read permission for the correct zones
• Try triggering a manual resync from the Providers page

Scan stuck or not completing

Symptoms: Records show "pending" scan status for an extended period.

Solutions:

• Daily scans process records in batches — large inventories may take several hours to complete
• Check the Scan History page for any failed scans
• Individual record rescans can be triggered manually from the Records page
• If scans consistently fail for specific records, the target host may be blocking connections

"Why is this issue showing as critical?"

Issue severity is fixed per issue type and reflects how directly the finding can be exploited:

• Critical — confirmed and attacker-actionable right now (a CNAME takeover vulnerability with a matching service fingerprint, an unauthenticated Docker API). A single open Critical issue caps your DNS Health grade at D.
• High — serious exposure or a failed security control (dangling subdomains, expired certificates, exposed databases, broken delegations)
• Medium — a real weakness with indirect risk (weak TLS versions, SPF/DKIM/DMARC errors, self-signed certificates)
• Low — hygiene and availability findings (HTTP errors, certificates expiring soon)
• Informational — expected or contextual observations (delegated subdomains, authentication required)

Dangling subdomains and CNAME takeover vulnerabilities are graded differently on purpose. A Dangling Subdomain is a CNAME whose target no longer resolves — a takeover precondition that has not been confirmed claimable, so it is High. A CNAME Takeover Vulnerability is a CNAME whose target DNS Watchdog has fingerprinted as an unclaimed resource on a known service, so it is Critical.

See the individual issue pages for detailed explanations of why each issue type is flagged at its severity level.

How to rotate provider credentials

1. Generate new credentials at your DNS provider (see Provider Setup Guides for the required permissions)
2. Go to Settings → Providers in DNS Watchdog
3. Select the provider and update the credentials
4. DNS Watchdog validates the new credentials immediately
5. Revoke the old credentials at your DNS provider

Notifications not being delivered

Solutions:

• Check the channel status on Settings → Notifications — channels in "Error" state have failed 3+ consecutive deliveries
• For Slack, verify the webhook URL hasn't been revoked in your Slack workspace settings
• For Teams, check the incoming webhook connector is still active
• For custom webhooks, ensure your endpoint returns a 2xx status code
• Send a Test notification to verify the channel is working
• Check that the scan actually detected changes — notifications are only sent when changes are found

Getting help

If you're experiencing an issue not covered here, contact support at support@dnswatchdog.io.