VorticPanel

Administration

DNS with PowerDNS

Customers can host their domains’ records on your nameservers (DNS in their sidebar), and the panel keeps reverse DNS for the addresses it hands out. Zones are always kept in the panel. To serve them, connect PowerDNS Authoritative.

1. Switch on PowerDNS’s API

In pdns.conf:

api=yes
api-key=the-api-key-from-pdns.conf
webserver=yes
webserver-address=127.0.0.1
webserver-port=8081
default-soa-edit-api=DEFAULT

2. Connect it in the panel

Network → Reverse DNS → PowerDNS (top right): enter the API address (e.g. http://10.0.0.5:8081, reachable from the controller; http://127.0.0.1:8081 on the controller itself is fine, but not the panel’s own port, 8080, nor a link-local address such as 169.254.169.254), the server ID (usually localhost) and the API key, and the 2 to 4 nameservers zones are made with, such as ns1.example.com and ns2.example.com. Test connection tries it without saving; Connect PowerDNS saves it once it answers. The key is kept encrypted with the controller’s other secrets and never shown again. Disconnect PowerDNS stops the panel updating it; what PowerDNS has stays there.

The same nameservers are the ones customers point their domains at (Settings → DNS hosting). To switch DNS hosting off for customers, use Settings → Customer features.

It can also be set in /etc/panel/controller.env instead, which wins over the panel’s setting (the page then shows it read-only):

PANEL_PDNS_URL=http://127.0.0.1:8081
PANEL_PDNS_KEY=the-api-key-from-pdns.conf
# PANEL_PDNS_SERVER=localhost

3. Create the reverse zones

Network → Reverse DNS → Reverse zones lists every reverse zone PowerDNS has, plus the ones your IP pools need: one per /24 for IPv4 (one per /16 for very large pools) and one per /48 or other prefix for IPv6. Pools smaller than a /24 get none, since their zone belongs to whoever holds the /24. For each zone it shows:

  • In PowerDNS: whether it exists, and how many PTRs it holds. Create zone makes it with your nameservers; Delete removes it and every record in it (type its name to confirm).
  • Points at: who the internet asks for it, from a lookup every 10 minutes. Your nameservers means it works. Not delegated yet or someone else’s means the owner of the range above (your provider, or your RIR for your own allocation) has to point it at your nameservers.

Add a zone by hand takes any in-addr.arpa or ip6.arpa name, including a classless one your provider delegated (e.g. 16/29.20.56.31.in-addr.arpa).

How the panel uses PowerDNS

  • Zones: each changed zone is pushed on the next tick, sending only the records that differ. The panel sets the apex NS records and leaves the SOA to PowerDNS (soa_edit_api). If PowerDNS is down, the zone page says so and the push is retried with back-off.
  • Reverse DNS: once a reverse zone exists (step 3), the panel keeps the PTRs for the addresses in its IP pools (see below), and leaves gateways and reserved addresses without a PTR set here, and the rest of each zone, alone. The Reverse DNS page warns about addresses no reverse zone covers.
  • Delegation: checked with ordinary DNS lookups from the controller, so it needs to reach a resolver. A new zone is checked straight away, then every 5 minutes for its first day and hourly after that. Live zones are checked every 6 hours, so a domain that moves away is noticed and its owner told. A zone is live when every nameserver the domain has is one of yours.
  • Proof of ownership: a new zone isn’t pushed to PowerDNS, so nothing is served for it, until the customer shows the domain is theirs with a TXT record at _panel-verify.<domain> holding the value the zone page gives them. It’s looked up with the delegation checks, or straight away with Check now. Without this, anyone could add a domain that still points at your nameservers after its owner left, and answer for it. Zones added before this existed count as verified.

Without PowerDNS, zones are kept in the panel only.

Reverse DNS for ranges

Reverse DNS in the admin menu lists your IP pools on the left, each with how many of its addresses have a PTR, and whether PTRs are reaching PowerDNS at the top. For an IPv4 pool:

  • Default PTR (under the pool’s name): a pattern every assigned or free address gets until it has a PTR of its own, such as {dashed}.static.example.net (203.0.113.42 becomes 203-0-113-42.static.example.net). Variables: {a} {b} {c} {d} for each part of the address and {dashed} for all of it. Gateways and reserved addresses don’t get it. A bar shows how many addresses have their own PTR, the default, or none.
  • The address list: each address, what it’s used by, and its PTR (marked default when it comes from the pattern). Search, filter, and edit or remove any one with the pencil and the ×, the gateway included.
  • Several at once: tick addresses, then Set PTR or Remove PTR; or Set a range for every address from one to another. Both take a hostname or a pattern, preview it, and with {hostname} point each server’s addresses at its hostname. Addresses that already have a PTR keep it unless you tick Replace PTRs already set, which includes customers’ own.

A PTR set on an address that isn’t on a server applies while it isn’t; once a server gets the address, its own PTR or the default takes over. IPv6 pools hand out whole /64s, so their PTRs are set per address on each server’s Network tab. Staff need Manage IP pools to change reverse DNS here.

What customers get

  • Adding a domain can point @ and www at one of their servers straight away.
  • The zone editor checks A, AAAA, CNAME, MX, TXT, SRV, CAA and NS records as they type, and suggests their servers’ addresses for A and AAAA records.
  • Zones import from, and export to, BIND zone files.
  • Reverse DNS is checked against forward DNS, with a one-click fix when the A record is missing.
  • Until the domain is verified, the zone shows Waiting for verification with the TXT record to add where the domain’s DNS is hosted now, usually at the registrar. They can remove the record once it’s verified.
  • Until the domain points at your nameservers, the zone shows Waiting for nameservers and what to set at the registrar.
  • A customer whose domain already points at your nameservers has nowhere else to add the TXT record. Sign in as the customer (a support session), open the zone and choose Confirm for the customer once you’re satisfied it’s theirs; it needs “Manage accounts” and is in the audit log.
  • Only a verified domain is held. Until one account verifies it, several accounts can add the same domain (or a name above or below it); the first to verify it keeps it, and the others’ zones are removed with a notification saying why. A zone that isn’t verified within 3 days is removed the same way.
  • A verified domain that’s deleted stays with the account that had it for 7 days: nobody else can add it, or a name above or below it, in that time. The same account can add it back without verifying again. A deleted unverified zone isn’t held, since nothing of it was served.

Resellers

Resellers can show their own nameserver names (white label) from their overview page. Those names have to resolve to your nameservers through glue records at the reseller’s registrar.

The domain those names are in (northwind.host for ns1.northwind.host) is kept from other accounts only once the reseller has it as a verified zone here, so naming a nameserver in someone else’s domain doesn’t keep that domain from its owner. A suspended reseller can’t change its nameservers or branding until it’s resumed.

Every word has to appear. ↑ ↓ to move, Enter to open.