Troubleshooting

Troubleshooting rDNS #

A record saved in SynergyCP but does not resolve #

Work through the chain in order:

  1. Check the SynergyCP logs for the PTR entry. Every create/change/delete is logged; sync jobs retry with backoff and log an admin-visible failure entry when the DNS provider stays unreachable. A failure entry usually names the cause (connection refused, bad API key, provider error).

  2. Query the DNS server directly, bypassing delegation:

    dig +noall +answer -x <ip> @<your DNS server>
    • If this answers correctly, the record is fine and the problem is delegation: your IP range’s authoritative nameservers (set with your RIR or upstream) do not point at this DNS server. For Cloudflare, check the zone status in the dashboard — zones stay inactive until you delegate to the assigned nameservers, and Cloudflare only allows about 30 days for that.
    • If this returns nothing, the record never reached the provider — check the log entries from step 1 and the Settings > DNS values (host reachable? API key correct?).

  3. PowerDNS only: confirm the API is enabled in pdns.conf and the port matches what SynergyCP uses (v4: port 80 by default; v3: host:8081 syntax in API Host).

Saving a PTR does nothing at all — no log entry, no DNS change, no error #

If PTR saves report success but produce no log entries, no DNS sync, and no failed jobs, the SynergyCP background workers were likely started before the package was installed and are running with a stale event configuration. Restart the SynergyCP services on the panel server, then save the PTR again. If the behavior persists, contact support.

“Invalid PTR. Please ensure that X has an A or AAAA DNS record to Y” #

Clients (not admins) must pass forward-DNS validation: the hostname they enter must already resolve to the IP the PTR is for. Create the A (IPv4) or AAAA (IPv6) record in the domain’s forward DNS zone first, wait for it to propagate, then set the PTR.

“The DNS lookup for X failed. Please try again in a few minutes.” #

The forward-DNS check itself could not complete — usually a transient resolver problem or a lame delegation for the hostname’s domain. Verify the hostname resolves (dig A <hostname> / dig AAAA <hostname>) and try again.

“You do not have access to that IP” #

The client tried to set a PTR for an IP that is not inside any IP entity assigned to their servers. Check the server’s IP entities — for IPv6, the address must fall inside the entity’s IPv6 assignment (e.g. its /64).

“The IPv6 rDNS limit of N records for this IP range has been reached” #

The client hit the IPv6 rDNS Limit (per IP entity; default 20). Raise the limit in Settings > DNS, or have an admin create the extra records — admins are not limited.

PowerDNS: “must have at least 2 nameservers” #

PowerDNS zone creation requires at least two entries in the Name Servers setting. Enter a comma-separated list with the master first, e.g. ns1.example.com, ns2.example.com.

The panel UI looks wrong after upgrading the package #

If pages look broken or stale right after a package upgrade (e.g. missing buttons or labels showing as pkg.rdns... key paths), the browser is holding cached assets. Do a hard refresh (Ctrl+Shift+R / Cmd+Shift+R); if something still looks off, clear the browser cache for both the panel and API domains. Recent package versions carry cache-busting versions on their assets to prevent this.

Still stuck? #

Contact support with the affected IP, the log entries from the attempt, and the output of the dig query against your DNS server.