Chapter 15. Per zone settings aka Domain Metadata

Starting with the PowerDNS Authoritative Server 3.0, each served zone can have "metadata". Such metadata determines how this zone behaves in certain circumstances.

[Warning]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.

Most of these metadata items are described elsewhere in the documentation. The following settings are available:

ALLOW-AXFR-FROM

Per-zone AXFR ACLs (see Chapter 14, AXFR ACLs).

ALLOW-2136-FROM

See Section 2, “Per zone settings”

TSIG-ALLOW-2136

See Section 2, “Per zone settings”

FORWARD-2136

See Section 2, “Per zone settings”

SOA-EDIT-2136

See Section 2, “Per zone settings”

ALSO-NOTIFY

When notifying this domain, also notify this nameserver (can occur multiple times).

AXFR-MASTER-TSIG

Use this named TSIG key to retrieve this zone from its master (see Section 2, “Provisioning signed notification and AXFR requests”).

LUA-AXFR-SCRIPT

Script to be used to edit incoming AXFRs (see Section 2.2, “Modifying a slave zone using a script”).

NSEC3NARROW

Set to "1" to tell PowerDNS this zone operates in NSEC3 'narrow' mode (see 'set-nsec3' in Section 5, “'pdnssec' for PowerDNSSEC command & control”).

NSEC3PARAM

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 'set-nsec3' in Section 5, “'pdnssec' for PowerDNSSEC command & control”). Example content: "1 0 1 ab".

PRESIGNED

This zone carries DNSSEC RRSIGs (signatures), and is presigned (see 'set-presigned' in Section 5, “'pdnssec' for PowerDNSSEC command & control”).

SOA-EDIT

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.

Inception refers to the time the RRSIGs got updated in live mode. This happens every week (see Section 4.2, “Signatures”). The inception time does not depend on local timezone, but some modes below will use localtime for representation.

Available modes are:

INCREMENT-WEEKS

Increments the serial with the number of weeks since the epoch.

This should work in every setup; but the result won't look like YYYYMMDDSS anymore.

INCEPTION-EPOCH (available since 3.1)

Sets the new SOA serial number to the maximum of the old SOA serial number, and age in seconds of the last inception.

This requires your backend zone to use age in seconds as SOA serial. The result is still the age in seconds of the last change.

INCEPTION-INCREMENT (available since 3.3)

Uses YYYYMMDDSS format for SOA serial numbers. If the SOA serial from the backend is within two days after inception, it gets incremented by two (the backend should keep SS below 98). Otherwise it uses the maximum of the backend SOA serial number and inception time in YYYYMMDD01 format.

This requires your backend zone to use YYYYMMDDSS as SOA serial format. Uses localtime to find the day for inception time.

INCEPTION (not recommended)

Sets the SOA serial to the last inception time in YYYYMMDD01 format. Uses localtime to find the day for inception time.

[Warning]Warning

The SOA serial will only change on inception day, so changes to the zone will get visible on slaves only on the following inception day.

INCEPTION-WEEK (not recommended)

Sets the SOA serial to the number of weeks since the epoch, which is the last inception time in weeks.

[Warning]Warning

Same problem as INCEPTION

EPOCH

Sets the SOA serial to the number of seconds since the epoch.

[Warning]Warning

Don't combine this with AXFR - the slaves would keep refreshing all the time. If you need fast updates, sync the backend databases directly with incremental updates (or use the same database server on the slaves)

TSIG-ALLOW-AXFR

Allow these named TSIG keys to AXFR this zone (see Section 1, “Provisioning outbound AXFR access”).