Per zone settings aka Domain Metadata
Each served zone can have "metadata". Such metadata determines how this zone behaves in certain circumstances.
Warning: Domain metadata is only available for DNSSEC capable backends! Make sure to enable the proper '-dnssec' setting to benefit, and to have performed the DNSSEC schema update.
For the BIND backend, this information is either stored in the
bind-dnssec-db or the hybrid database, depending on your
For the implementation in non-sql backends, please review your backend's documentation.
Starting with the PowerDNS Authoritative Server 3.1, per-zone AXFR ACLs can be stored in the domainmetadata table.
Each ACL row can list one subnet (v4 or v6), or the magical value 'AUTO-NS' that tries to allow all potential slaves in.
select id from domains where name='example.com'; 7 insert into domainmetadata (domain_id, kind, content) values (7,'ALLOW-AXFR-FROM','AUTO-NS'); insert into domainmetadata (domain_id, kind, content) values (7,'ALLOW-AXFR-FROM','2001:db8::/48');
To disallow all IP's, except those explicitly allowed by domainmetadata records, add
The IP address to use as a source address for sending AXFR and IXFR requests.
ALLOW-DNSUPDATE-FROM, TSIG-ALLOW-DNSUPDATE, FORWARD-DNSUPDATE, SOA-EDIT-DNSUPDATE
See the documentation on Dynamic DNS update
When notifying this domain, also notify this nameserver (can occur multiple times). The nameserver may have contain an optional port number. e.g.:
insert into domainmetadata (domain_id, kind, content) values (7,'ALSO-NOTIFY','192.0.2.1:5300'); insert into domainmetadata (domain_id, kind, content) values (7,'ALLOW-AXFR-FROM','2001:db8:53::1');
Use this named TSIG key to retrieve this zone from its master, see Provisioning signed notification and AXFR requests.
Allow this GSS principal to perform AXFR retrieval. Most commonly it is
Use this principal for accepting GSS context. (See GSS-TSIG support).
If set to 1, attempt IXFR when retrieving zone updates. Otherwise IXFR is not attempted.
Script to be used to edit incoming AXFRs, see Modifying a slave zone using a script.
Set to "1" to tell PowerDNS this zone operates in NSEC3 'narrow' mode. See
NSEC3 parameters of a DNSSEC zone. Will be used to synthesize the NSEC3PARAM
record. If present, NSEC3 is used, if not present, zones default to NSEC. See
pdnsutil. Example content: "1 0 1 ab".
This zone carries DNSSEC RRSIGs (signatures), and is presigned. PowerDNS sets
this flag automatically upon incoming zone transfers (AXFR) if it detects DNSSEC
records in the zone. However, if you import a presigned zone using
pdnsutil load-zone you must explicitly set the zone to be
PRESIGNED. Note that
PowerDNS will not be able to correctly serve the zone if the imported data is
bogus or incomplete. Also see
If a zone is presigned, the content of the metadata must be "1" (without the quotes). Any other value will not signal presignedness.
Whether to publish CDNSKEY and/or CDS recording defined in RFC 7344.
To publish CDNSKEY records of the KSKs for the zone, set
To publish CDS records for the KSKs in the zone, set
PUBLISH-CDS to a comma-
separated list of signature algorithm numbers.
When serving this zone, modify the SOA serial number in one of several ways. Mostly useful to get slaves to re-transfer a zone regularly to get fresh RRSIGs. See the DNSSEC documentation for more information.
Allow these named TSIG keys to AXFR this zone, see Provisioning outbound AXFR access.
Through the API and on the
pdnsutil set-meta commandline, metadata unused by PowerDNS can be added.
It is mandatory to prefix this extra metadata with "X-" and the name of the external application; the API will only allow this metadata if it starts with "X-".