Manage an authorised PowerDNS reverse-DNS zone in Blesta

Skip to main content
Print

Manage an authorised PowerDNS reverse-DNS zone in Blesta

Use PTR records only where the reverse-DNS range has been delegated to nameservers you manage. Adding a PTR-shaped record to an ordinary forward domain does not change the reverse DNS controlled by an address provider.

Confirm reverse authority

Ask the address provider or DNS administrator which reverse zone has been delegated and what names belong inside it. Confirm whether IPv4 or IPv6 reverse naming applies and whether any classless delegation arrangement changes the required record layout.

If the address provider retains reverse-DNS control, use its supported PTR process. PD PowerDNS cannot acquire authority for an arbitrary address simply by creating a reverse-looking zone.

Add the intended PTR

  1. Open the intended authoritative reverse zone in PowerDNS → Zones.
  2. Review existing PTR values for the address.
  3. Choose Add record → PTR, or edit the exact existing record.
  4. Enter the required reverse name, canonical hostname and TTL.
  5. Save and compare the resulting record with the delegated-zone plan.

Use the hostname supplied for this address. Check its forward A or AAAA records separately where the consuming service expects forward and reverse names to agree.

Check the actual delegated answer

Verify the reverse lookup through the authoritative delegation, then account for caches. A record visible in the module is not proof that public reverse queries reach that zone.

If the answer is still supplied by the address provider, return to the delegation question. Preserve the affected address reference and redacted result for the responsible administrator rather than changing unrelated forward records or recreating a working DNS zone.

Check disabled native record members before editing

PowerDNS can retain disabled members in a native record set. The module displays enabled members of recognised types and rebuilds an affected set from enabled members when writing it. Disabled members in that same set can therefore be removed by a module change. If your deployment uses disabled records, have your PowerDNS administrator preserve and review the native set through your authorised server process before editing it here. Module snapshots and BIND exports omit disabled members, so they do not preserve that native state.

See the PD PowerDNS Blesta guide for related tasks, or explore PD PowerDNS.

Table of Contents

Get your website online with PD Hosting

UK hosting, domains and support from a real team. From a first site to a full server.

Terms and Conditions  ·  Privacy Policy

PD Hosting is the trading name of Projektif Digital Ltd, registered in England and Wales, company number 12482555.

PD Hosting
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.