Troubleshooting and Operations
Troubleshooting and Operations uses a layer-by-layer method to find the first point where observed DNS behavior differs from intended SDM state.
Where to find it: Documentation > DNS Manager > Troubleshooting and Operations.
Available to: All operators for their scope; root is needed for node, cluster, service, and retention controls.
What this page does
DNS incidents often cross several systems: panel state, authoritative data, provider synchronization, delegation, caching, DNSSEC, and client resolver behavior. This page keeps those layers separate so one symptom does not trigger five speculative changes.
Before you start
Record the exact domain, record type, expected answer, observed answer, resolver/server queried, timestamp, and last approved change. Preserve error responses and request ids.
Diagnostic order
- Identity and scope: can the user/API identity authenticate, and does it own the zone?
- SDM zone: does DNS Zones show the correct owner, provider, and recent state?
- Authoritative data: does Zone Editor contain the exact RRset and does zone_check pass?
- DNSSEC: do signing, DNSKEY, parent DS, and validating resolution agree?
- Provider: do desired/active state, sync result, Cloudflare zone id, and delegation agree?
- Cluster: do active nodes report healthy membership and synchronized data?
- Public delegation/cache: are registrar NS and cached TTLs consistent with the change?
- Evidence: correlate Audit with Logs and Monitor at the same time.
Common symptoms
| Symptom | First checks |
|---|---|
| Public API returns 404 | Use https://panel.example.com:882 and a documented /api/... route; direct service paths are not public. |
| 401 or 403 | Check API name/key, linked panel account active state, API IP rules, permission, root reservation, and ownership. |
| SDM shows record but public DNS does not | Query authoritative nameservers, then check registrar delegation, provider state, TTL, and DNSSEC. |
| Cloudflare live controls disabled | Read assigned versus detected nameservers and fix delegation mismatch. |
| DNSSEC validation fails | Compare current DNSKEY/DS with the parent; do not disable signing while a parent DS remains. |
| Missing old logs/audit | Compare query dates with effective retention and prior prune/rotation. |
How to use it
- Reproduce with a read-only query.
- Walk the diagnostic order and stop at the first mismatch.
- Use the owning page to make the smallest correction.
- Verify the corrected layer and every downstream consumer.
- Record the cause, change, and proof in the incident or support case.
Result and next check
The incident has one evidence-backed failure layer and a bounded correction. If no layer is proven, continue collecting evidence; “DNS is weird” is an observation, not yet a root cause.
Theme color