Managing PTR Records

Managing PTR Records #

PTR records can be managed in two places: the per-server Reverse DNS page (available to both admins and clients) and the global Network > rDNS PTRs list (admin only). Every change made in either place is logged and synced to the configured DNS provider automatically.

This page describes package version 3.1 and later, which moved rDNS management from an expanding box on the server page to a dedicated per-server page.

The Reverse DNS page #

Every server page — in both the admin and client portals — shows an rDNS Management panel with a Manage Reverse DNS button. It opens the server’s Reverse DNS page (/hardware/server/<id>/rdns), which lists the server’s IP space in two tabs:

IPv4 #

Every IPv4 address in the server’s IP entities is listed with a text box for its PTR hostname:

  • Type or change a hostname and click Save to apply your edits. Multiple rows can be edited before saving; Save applies them all.
  • Clear a hostname and click Save to delete that PTR record.
  • Long lists are paginated — 20 rows per page by default, with a selector for 50, 100, or 500.

IPv6 #

IPv6 ranges are far too large to list address-by-address, so the IPv6 tab works per record:

  • Existing IPv6 PTR records (and any single-address IPv6 entities) are listed just like IPv4 rows — edit the hostname and Save to change them.
  • To add a record, enter an IPv6 address and hostname in the bottom row and click +. The record is created immediately — no Save needed. The address must fall within an IPv6 range assigned to the server (e.g. inside the entity’s /64).
  • The trash button deletes a record immediately.
  • The IPv6 tab only appears when the server has IPv6 addresses assigned (or existing IPv6 PTR records).

Client rules #

Clients see the same page for their own servers, with these guardrails:

  • Clients can only manage PTRs for IP entities assigned to their servers.
  • Forward-DNS validation: a client-entered hostname must already have an A (IPv4) or AAAA (IPv6) record pointing at the IP before the PTR is accepted. This enforces forward-confirmed reverse DNS. Admins are not subject to this check.
  • IPv6 limit: clients can create at most a set number of IPv6 PTR records per IP entity (the IPv6 rDNS Limit setting, 20 by default). Creating more shows a validation error. Admins are not limited, so a client who legitimately needs more records can either have the global limit raised or have an admin create them.

The rDNS PTRs list (admin) #

Network > rDNS PTRs lists every PTR record in the system:

  • Search by full or partial IP address — either family, any notation (64.74.160, 2605:9f80, 2605:9f80::1) — or by hostname.
  • The Server column shows which server each IP belongs to (via its IP entity) and links to that server. Records for unassigned IPs show a blank cell. Requires package 3.1.6+.
  • Create records for any IP — including IPs outside any entity, which is useful for infrastructure addresses. Records created here for unassigned IPs are not visible to any client.
  • Select multiple records for bulk deletion, or open a record to edit or delete it.
  • The page also hosts the zone file import and a PTR activity log.

Logging and sync behavior #

Every PTR create, change, and delete is written to the SynergyCP logs with the IP and hostname, and queued for sync to the DNS provider. Sync jobs retry with backoff when the provider is unreachable and write an admin-visible log entry if retries run out — so if a record shows in SynergyCP but not in DNS, check the logs first. Some provider actions add useful details to the log entry, such as the nameservers Cloudflare assigns to a newly created zone.

When a server is wiped or an IP entity is deleted, all PTR records for that entity — IPv4 and IPv6 — are removed from SynergyCP and deleted from the DNS provider automatically.