{% extends "baseTemplate/index.html" %} {% load static %} {% block title %}DNS Clustering{% endblock %} {% block content %}

DNS Clustering

Replication between this server and your other nameservers: are the slaves actually carrying your current zones?

Everything on this page is server-wide. A supermaster can create zones here on its own, and allow-axfr-ips applies to every zone on the box — including every customer's. Nothing here is scoped to a single account.

{# --------------------------------------------------------------- tabs #}
{# ------------------------------------------------------- cluster status #}
In sync every peer holds our serial
Out of step serial drift on at least one peer
Unreachable no usable SOA answer
No peers nothing to compare against

Zone replication

Zone Role Our serial Peers Verdict Actions
none {$ stateLabel(zone.state) $}
Peer Address Learned from Their serial Drift State
{$ peer.address $}:{$ peer.port $} {$ peerStateLabel(peer) $}

PowerDNS last checked this zone at {$ zone.lastCheckText $}.

Probing peers… each zone is queried directly, so this can take a moment.

Nothing to compare yet

Create a zone, or add ALSO-NOTIFY metadata / apex NS records pointing at your other nameservers, and their serials will be compared here.

Showing {$ offset + 1 $}–{$ offset + clusterZones.length $} of {$ total $} zones.

Peers come from two places: ALSO-NOTIFY zone metadata, and any apex NS record that is not {{ ns1 }} or {{ ns2 }}. Each is asked for the zone's SOA with a direct, non-recursive query — a behind verdict on a zone you master means that slave has not transferred your latest change yet.

{# --------------------------------------------------------- supermasters #}

A supermaster may create zones on this server by itself. When the listed address sends a NOTIFY for a zone whose NS set contains the listed nameserver, PowerDNS provisions that zone as a slave without asking anyone. Only list hosts you operate.

Add a supermaster

The address this server will accept NOTIFY packets from.

Must appear in the NS set of every zone this master provisions, or PowerDNS refuses the zone.

A CloudPanel username, stamped on the zones this master creates. Zones created this way still get no panel ownership record, so only an administrator will see them until one is assigned.

Configured supermasters

Master IP Nameserver Account Actions
none

Loading supermasters…

No supermasters configured

That is the safe default: no remote host can provision zones here. Add one only if you run a hidden primary that should push zones to this server automatically.

{# ------------------------------------------------------------ axfr #}

allow-axfr-ips

Who may pull a full copy of a zone from this server.

Read from .

CloudPanel writes its value to {{ axfrPath }}, which PowerDNS reads through include-dir. The value in pdns.conf is left alone.

Comma or space separated IP addresses and CIDR ranges. Prefix an entry with ! to deny it. Leave the box empty to allow no transfers at all, which is the safe setting when you run no secondaries.

allow-axfr-ips is only read at startup, so saving restarts the {{ pdnsService }} service. Resolution stops for a second or two while it comes back.

Only a server administrator can change this value. You can see it, but not edit it.

A per-zone exception is cleaner than widening this list: set the ALLOW-AXFR-FROM metadata on the single zone that needs it instead of opening every zone on the server.

{% endblock %} {% block scripts %} {% endblock %}