{% extends "baseTemplate/index.html" %} {% load static %} {% block title %}DNS Clustering{% endblock %} {% block content %}
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.
Probing peers… each zone is queried directly, so this can take a moment.
Create a zone, or add ALSO-NOTIFY metadata / apex NS records pointing at your other nameservers, and their serials will be compared here.
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.
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.
| Master IP | Nameserver | Account | Actions |
|---|---|---|---|
| none |
Loading supermasters…
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.
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.
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.