### `virtual bool replaceRRSet(uint32_t domain_id, const string& qname, const QType& qt, const vector<DNSResourceRecord>& rrset)`
This method should remove all the records with `qname` of type `qt`. `qt` might also be ANY, which means all the records with that `qname` need to be removed. After removal, the records in `rrset` must be added to the zone. `rrset` can be empty in which case the method is used to remove a RRset.
+
+# DNS update support
+To make your backend DNS update compatible, it needs to implement a number of new functions and functions already used for slave-operation. The new functions are not DNS update specific and might be used for other update/remove functionality at a later stage.
+
+``` {.programlisting}
+class DNSBackend {
+public:
+ /* ... */
+ virtual bool startTransaction(const string &qname, int id);
+ virtual bool commitTransaction();
+ virtual bool abortTransaction();
+ virtual bool feedRecord(const DNSResourceRecord &rr, string *ordername);
+ virtual bool replaceRRSet(uint32_t domain_id, const string& qname, const QType& qt, const vector<DNSResourceRecord>& rrset)
+ virtual bool listSubZone(const string &zone, int domain_id);
+ /* ... */
+}
+```
+
+## `virtual bool startTransaction(const string &qname, int id);`
+See [Read/write slave-capable backends](#read-write-slave-capable-backends). Please note that this function now receives a negative number (-1), which indicates that the current zone data should NOT be deleted.
+
+## `virtual bool commitTransaction();`
+See [Read/write slave-capable backends](#read-write-slave-capable-backends).
+
+## `virtual bool abortTransaction();`
+See [Read/write slave-capable backends](#read-write-slave-capable-backends). Method is called when an exception is received.
+
+## `virtual bool feedRecord(const DNSResourceRecord &rr, string *ordername);`
+See [Read/write slave-capable backends](#read-write-slave-capable-backends). Please keep in mind that the zone is not empty because `startTransaction()` was called different.
+
+virtual bool listSubZone(const string &name, int domain\_id);
+This method is needed for rectification of a zone after NS-records have been added. For DNSSEC, we need to know which records are below the currently added record. `listSubZone()` is used like `list()` which means PowerDNS will call `get()` after this method. The default SQL query looks something like this:
+
+``` {.programlisting}
+// First %s is 'sub.zone.com', second %s is '*.sub.zone.com'
+select content,ttl,prio,type,domain_id,name from records where (name='%s' OR name like '%s') and domain_id=%d
+```
+
+The method is not only used when adding records, but also to correct ENT-records in powerdns. Make sure it returns every record in the tree below the given record.
+
+## virtual bool replaceRRSet(uint32\_t domain\_id, const string& qname, const QType& qt, const vector\<DNSResourceRecord\>& rrset);
+
+This method should remove all the records with `qname` of type `qt`. `qt` might also be ANY, which means all the records with that `qname` need to be removed. After removal, the records in `rrset` must be added to the zone. `rrset` can be empty in which case the method is used to remove a RRset.
--- /dev/null
+# Dynamic DNS Update (RFC2136)
+Starting with the PowerDNS Authoritative Server 3.4.0, DNS update support is available. There are a number of items NOT supported:
+
+* There is no support for GSS*TSIG and SIG (TSIG is supported);
+* WKS records are specifically mentioned in the RFC, we don't specifically care about WKS records;
+* Anything we forgot....
+
+The implementation requires the backend to support a number of new oparations. Currently, the following backends have been modified to support DNS update:
+
+* [gmysql](backend-generic-mypgsql.md)
+* [gpgsql](backend-generic-mypgsql.md)
+* [gsqlite3](backend-gsqlite.md)
+
+# Configuration options
+There are two configuration parameters that can be used within the powerdns configuration file.
+
+## `experimental-dnsupdate`
+A setting to enable/disable DNS update support completely. The default is no, which means that DNS updates are ignored by PowerDNS (no message is logged about this!). Change the setting to **experimental-dnsupdate=yes** to enable DNS update support. Default is **no**.
+
+## `allow-dnsupdate-from`
+A list of IP ranges that are allowed to perform updates on any domain. The default is 0.0.0.0/0, which means that all ranges are accepted. Multiple entries can be used on this line (**allow-dnsupdate-from=10.0.0.0/8 192.168.1.2/32**). The option can be left empty to disallow everything, this then should be used in combination with the **allow-dnsupdate-from** domainmetadata setting per zone.
+
+## `forward-dnsupdate`
+Tell PowerDNS to forward to the master server if the zone is configured as slave. Masters are determined by the masters field in the domains table. The default behaviour is enabled (yes), which means that it will try to forward. In the processing of the update packet, the **allow-dnsupdate-from** and **TSIG-2136-ALLOW** are processed first, so those permissions apply before the **forward-dnsupdate** is used. It will try all masters that you have configured until one is successful.
+
+# Per zone settings
+For permissions, a number of per zone settings are available via the domain metadata (See [Chapter 15, *Per zone settings aka Domain Metadata*](domainmetadata.html "Chapter 15. Per zone settings aka Domain Metadata")).
+
+## ALLOW-DNSUPDATE-FROM
+This setting has the same function as described in the configuration options (See [above](#configuration-options)). Only one item is allowed per row, but multiple rows can be added. An example:
+
+``` {.programlisting}
+sql> select id from domains where name='powerdnssec.org';
+5
+sql> insert into domainmetadata(domain_id, kind, content) values(5, ‘ALLOW-DNSUPDATE-FROM’,’10.0.0.0/8’);
+sql> insert into domainmetadata(domain_id, kind, content) values(5, ‘ALLOW-DNSUPDATE-FROM’,’192.168.1.2/32’);
+```
+
+This will allow 10.0.0.0/8 and 192.168.1.2/32 to send DNS update messages for the powerdnssec.org domain.
+
+## TSIG-ALLOW-DNSUPDATE
+This setting allows you to set the TSIG key required to do an DNS update. An example:
+
+``` {.programlisting}
+sql> insert into tsigkeys (name, algorithm, secret) values ('test', 'hmac-md5', 'kp4/24gyYsEzbuTVJRUMoqGFmN3LYgVDzJ/3oRSP7ys=');
+sql> select id from domains where name='powerdnssec.org';
+5
+sql> insert into domainmetadata (domain_id, kind, content) values (5, 'TSIG-ALLOW-DNSUPDATE', 'test');
+```
+
+An example of how to use a TSIG key with the **nsupdate** command:
+
+``` {.programlisting}
+nsupdate <<!
+server <ip> <port>
+zone powerdnssec.org
+update add test1.powerdnssec.org 3600 A 192.168.1.1
+key test kp4/24gyYsEzbuTVJRUMoqGFmN3LYgVDzJ/3oRSP7ys=
+send
+!
+```
+
+If a TSIG key is set for the domain, it is required to be used for the update. The TSIG is extra security on top of the **ALLOW-DNSUPDATE-FROM** setting. If a TSIG key is set, the IP(-range) still needs to be allowed via **ALLOW-DNSUPDATE-FROM**.
+
+## FORWARD-DNSUPDATE
+See [Section 1, “Configuration options”](dnsupdate.html#dnsupdate-configuration "1. Configuration options") for what it does, but per domain.
+
+``` {.programlisting}
+sql> select id from domains where name='powerdnssec.org';
+5
+sql> insert into domainmetadata(domain_id, kind, content) values(5, ‘FORWARD-DNSUPDATE’,’’);
+```
+
+There is no content, the existence of the entry enables the forwarding. This domain-specific setting is only useful when the configuration option **forward-dnsupdate** is set to 'no', as that will disable it globally. Using the domainmetadata setting than allows you to enable it per domain.
+
+## SOA-EDIT-DNSUPDATE
+This configures how the soa serial should be updated. See [below](#soa-serial-updates).
+
+# SOA Serial Updates
+After every update, the soa serial is updated as this is required by section 3.7 of RFC2136. The behaviour is configurable via domainmetadata with the SOA-EDIT-DNSUPDATE option. It has a number of options listed below. If no behaviour is specified, DEFAULT is used.
+
+RFC2136 (Section 3.6) defines some specific behaviour for updates of SOA records. Whenever the SOA record is updated via the update message, the logic to change the SOA is not executed.
+
+**Note**: Powerdns will always use **SOA-EDIT** when serving SOA records, thus a query for the SOA record of the recently update domain, might have an unexpected result due to a SOA-EDIT setting.
+
+An example:
+
+``` {.programlisting}
+sql> select id from domains where name='powerdnssec.org';
+5
+sql> insert into domainmetadata(domain_id, kind, content) values(5, ‘SOA-EDIT-DNSUPDATE’,’INCREASE’);
+```
+
+This will make the SOA Serial increase by one, for every successful update.
+
+## SOA-EDIT-DNSUPDATE settings
+These are the settings available for **SOA-EDIT-DNSUPDATE**.
+
+* DEFAULT: Generate a soa serial of YYYYMMDD01. If the current serial is lower than the generated serial, use the generated serial. If the current serial is higher or equal to the generated serial, increase the current serial by 1.
+* INCREASE: Increase the current serial by 1.
+* EPOCH: Change the serial to the number of seconds since the EPOCH, aka unixtime.
+* SOA-EDIT: Change the serial to whatever SOA-EDIT would provide. See [Domain metadata](domainmetadata.md)
+* SOA-EDIT-INCREASE: Change the serial to whatever SOA-EDIT would provide. If what SOA-EDIT provides is lower than the current serial, increase the current serial by 1.
+
+# DNS update How-to: Setup dyndns/rfc2136 with dhcpd
+DNS update is often used with DHCP to automatically provide a hostname whenever a new IP-address is assigned by the DHCP server. This section describes how you can setup PowerDNS to receive DNS updates from ISC's dhcpd (version 4.1.1-P1).
+
+## Setting up dhcpd
+We're going to use a TSIG key for security. We're going to generate a key using the following command:
+
+``` {.programlisting}
+dnssec-keygen -a hmac-md5 -b 128 -n USER dhcpdupdate
+```
+
+This generates two files (Kdhcpdupdate.\*.key and Kdhcpdupdate.\*.private). You're interested in the .key file:
+
+``` {.programlisting}
+# ls -l Kdhcp*
+-rw------- 1 root root 53 Aug 26 19:29 Kdhcpdupdate.+157+20493.key
+-rw------- 1 root root 165 Aug 26 19:29 Kdhcpdupdate.+157+20493.private
+
+# cat Kdhcpdupdate.+157+20493.key
+dhcpdupdate. IN KEY 0 3 157 FYhvwsW1ZtFZqWzsMpqhbg==
+```
+
+The important bits are the name of the key (**dhcpdupdate**) and the hash of the key (**FYhvwsW1ZtFZqWzsMpqhbg==**
+
+Using the details from the key you've just generated. Add the following to your dhcpd.conf:
+
+``` {.programlisting}
+key "dhcpdupdate" {
+ algorithm hmac-md5;
+ secret "FYhvwsW1ZtFZqWzsMpqhbg==";
+};
+```
+
+You must also tell dhcpd that you want dynamic dns to work, add the following section:
+
+``` {.programlisting}
+ddns-updates on;
+ddns-update-style interim;
+update-static-leases on;
+```
+
+This tells dhcpd to:
+
+1. Enable Dynamic DNS
+2. Which style it must use (interim)
+3. Update static leases as well
+
+For more information on this, consult the dhcpd.conf manual.
+
+Per subnet, you also have to tell **dhcpd** which (reverse-)domain it should update and on which master domain server it is running.
+
+``` {.programlisting}
+ddns-domainname "powerdnssec.org";
+ddns-rev-domainname "in-addr.arpa.";
+
+zone powerdnssec.org {
+ primary 127.0.0.1;
+ key dhcpdupdate;
+}
+
+zone 1.168.192.in-addr.arpa. {
+ primary 127.0.0.1;
+ key dhcpdupdate;
+}
+```
+
+This tells **dhcpd** a number of things:
+
+1. Which domain to use (**ddns-domainname "powerdnssec.org";**)
+2. Which reverse-domain to use (**dnssec-rev-domainname "in-addr.arpa.";**)
+3. For the zones, where the primary master is located (**primary 127.0.0.1;**)
+4. Which TSIG key to use (**key dhcpdupdate;**). We defined the key earlier.
+
+This concludes the changes that are needed to the **dhcpd** configuration file.
+
+## Setting up PowerDNS
+A number of small changes are needed to powerdns to make it accept dynamic updates from **dhcpd**.
+
+Enabled DNS update (RFC2136) support functionality in PowerDNS by adding the following to the PowerDNS configuration file (pdns.conf).
+
+``` {.programlisting}
+experimental-dnsupdate=yes
+allow-dnsupdate-from=
+```
+
+This tells PowerDNS to:
+
+1. Enable DNS update support(**experimental-dnsupdate**)
+2. Allow updates from NO ip-address (**allow-dnsupdate-from=**)
+
+We just told powerdns (via the configuration file) that we accept updates from nobody via the **allow-dnsupdate-from** parameter. That's not very useful, so we're going to give permissions per zone, via the domainmetadata table.
+
+``` {.programlisting}
+sql> select id from domains where name='powerdnssec.org';
+5
+sql> insert into domainmetadata(domain_id, kind, content) values(5, ‘ALLOW-DNSUPDATE-FROM’,’127.0.0.1’);
+```
+
+This gives the ip '127.0.0.1' access to send update messages. Make sure you use the ip address of the machine that runs **dhcpd**.
+
+Another thing we want to do, is add TSIG security. This can only be done via the domainmetadata table:
+
+``` {.programlisting}
+sql> insert into tsigkeys (name, algorithm, secret) values ('dhcpdupdate', 'hmac-md5', 'FYhvwsW1ZtFZqWzsMpqhbg==');
+sql> select id from domains where name='powerdnssec.org';
+5
+sql> insert into domainmetadata (domain_id, kind, content) values (5, 'TSIG-ALLOW-DNSUPDATE', 'dhcpdupdate');
+sql> select id from domains where name='1.168.192.in-addr.arpa';
+6
+sql> insert into domainmetadata (domain_id, kind, content) values (6, 'TSIG-ALLOW-DNSUPDATE', 'dhcpdupdate');
+```
+
+This will:
+
+1. Add the 'dhcpdupdate' key to our PowerDNSinstallation
+2. Associate the domains with the given TSIG key
+
+Restart PowerDNS and you should be ready to go!
+
+# How it works
+This is a short description of how DNS update messages are processed by PowerDNS.
+
+1. The DNS update message is received. If it is TSIG signed, the TSIG is validated against the tsigkeys table. If it is not valid, Refused is returned to the requestor.
+2. A check is performed on the zone to see if it is a valid zone. ServFail is returned when not valid.
+3. The **experimental-dnsupdate** setting is checked. Refused is returned when the setting is 'no'.
+4. If the **ALLOW-DNSUPDATE-FROM** has a value (from both domainmetadata and the configuration file), a check on the value is performed. If the requestor (sender of the update message) does not match the values in **ALLOW-DNSUPDATE-FROM**, Refused is returned.
+5. If the message is TSIG signed, the TSIG keyname is compared with the TSIG keyname in domainmetadata. If they do not match, a Refused is send. The TSIG-ALLOW-DNSUPDATE domainmetadata setting is used to find which key belongs to the domain.
+6. The backends are queried to find the backend for the given domain.
+7. If the domain is a slave domain, the **forward-dnsupdate** option and domainmetadata settings are checked. If forwarding to a master is enabled, the message is forward to the master. If that fails, the next master is tried until all masters are tried. If all masters fail, ServFail is returned. If a master succeeds, the result from that master is returned.
+8. A check is performed to make sure all updates/prerequisites are for the given zone. NotZone is returned if this is not the case.
+9. The transaction with the backend is started.
+10. The prerequisite checks are performed (section 3.2 of RFC2136). If a check fails, the corresponding RCode is returned. No further processing will happen.
+11. Per record in the update message, a the prescan checks are performed. If the prescan fails, the corresponding RCode is returned. If the prescan for the record is correct, the actual update/delete/modify of the record is performed. If the update fails (for whatever reason), ServFail is returned. After changes to the records have been applied, the ordername and auth flag are set to make sure DNSSEC remains working. The cache for that record is purged.
+12. If there are records updated and the SOA record was not modified, the SOA serial is updated. See [SOA Serial Updates](#soa-serial-updates). The cache for this record is purged.
+13. The transaction with the backend is committed. If this fails, ServFail is returned.
+14. NoError is returned.
--- /dev/null
+# 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**: 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.
+
+## ALLOW-AXFR-FROM
+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.
+
+Example:
+
+``` {.programlisting}
+sql> select id from domains where name='example.com';
+7
+sql> insert into domainmetadata (domain_id, kind, content) values (7,'ALLOW-AXFR-FROM','AUTO-NS');
+sql> insert into domainmetadata (domain_id, kind, content) values (7,'ALLOW-AXFR-FROM','2001:db8::/48');
+```
+
+## ALLOW-DNSUPDATE-FROM, TSIG-ALLOW-DNSUPDATE, FORWARD-DNSUPDATE, SOA-EDIT-DNSUPDATE
+See the documentation on [Dynamic DNS update](dnsupdate.md)
+
+## 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 [Provisioning signed notification and AXFR requests](modes-of-operation.md#provisioning-signed-notification-and-axfr-requests)).
+
+## LUA-AXFR-SCRIPT
+Script to be used to edit incoming AXFRs, see [Modifying a slave zone using a script](modes-of-operation.md#modifying-a-slave-zone-using-a-script).
+
+## NSEC3NARROW
+Set to "1" to tell PowerDNS this zone operates in NSEC3 'narrow' mode. See `set-nsec3` for [`pdnssec`](dnssec.md#pdnssec).
+
+## 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 [`pdnssec`](dnssec.md#pdnssec). Example content: "1 0 1 ab".
+
+## PRESIGNED
+This zone carries DNSSEC RRSIGs (signatures), and is presigned. See `set-presigned` in [`pdnssec`](dnssec.md#pdnssec).
+
+## 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-signing mode](dnssec.md#records-keys-signatures-hashes-within-powerdnssec-in-online-signing-mode). This happens every week (see [Signatures](dnssec.md#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**: 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**: Same problem as INCEPTION
+* EPOCH: Sets the SOA serial to the number of seconds since the epoch. **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 [Provisioning outbound AXFR access](modes-of-operation.md#provisioning-outbound-axfr-access).
```
Upon an incoming AXFR, PowerDNS calls our `axfrfilter` function for each record. All HINFO records are replaced by a TXT record with a TTL of 99 seconds and the specified string. TXT Records with names starting with `_tstamp.` get their value (rdata) set to the current time stamp. All other records are unhandled.
+
+# TSIG: shared secret authorization and authentication
+**Note**: Available since PowerDNS Authoritative Server 3.0!
+
+TSIG, as defined in [RFC 2845](http://tools.ietf.org/html/rfc2845), is a method for signing DNS messages using shared secrets. Each TSIG shared secret has a name, and PowerDNS can be told to allow zone transfer of a domain if the request is signed with an authorized name.
+
+In PowerDNS, TSIG shared secrets are stored by the various backends. In case of the popular Generic backends, they can be found in the 'tsigkeys' table. The name can be chosen freely, but the algorithm name will typically be 'hmac-md5'. The content is a Base64-encoded secret.
+
+**Note**: Most backends require DNSSEC support enabled to support TSIG. For the Generic SQL Backend make sure to use the DNSSEC enabled schema and to turn on the relevant '-dnssec' flag (for example, gmysql-dnssec)!
+
+## Provisioning outbound AXFR access
+To actually provision a named secret permission to AXFR a zone, set a metadata item in the 'domainmetadata' table called 'TSIG-ALLOW-AXFR' with the key name in the content field.
+
+As an example:
+
+``` {.programlisting}
+sql> insert into tsigkeys (name, algorithm, secret) values ('test', 'hmac-md5', 'kp4/24gyYsEzbuTVJRUMoqGFmN3LYgVDzJ/3oRSP7ys=');
+sql> select id from domains where name='powerdnssec.org';
+5
+sql> insert into domainmetadata (domain_id, kind, content) values (5, 'TSIG-ALLOW-AXFR', 'test');
+
+$ dig -t axfr powerdnssec.org @127.0.0.1 -y 'test:kp4/24gyYsEzbuTVJRUMoqGFmN3LYgVDzJ/3oRSP7ys='
+```
+
+To ease interoperability, the equivalent configuration above in BIND would look like this:
+
+``` {.programlisting}
+key test. {
+ algorithm hmac-md5;
+ secret "kp4/24gyYsEzbuTVJRUMoqGFmN3LYgVDzJ/3oRSP7ys=";
+};
+
+zone "powerdnssec.org" {
+ type master;
+ file "powerdnssec.org";
+ allow-transfer { key test.; };
+};
+```
+
+A packet authorized and authenticated by a TSIG signature will gain access to a zone even if the remote IP address is not otherwise allowed to AXFR a zone.
+
+## Provisioning signed notification and AXFR requests
+To configure PowerDNS to send out TSIG signed AXFR requests for a zone to its master(s), set the AXFR-MASTER-TSIG metadata item for the relevant domain to the key that must be used.
+
+The actual TSIG key must also be provisioned, as outlined in the previous section.
+
+For the popular Generic SQL backends, configuring the use of TSIG for AXFR requests could be achieved as follows:
+
+``` {.programlisting}
+sql> insert into tsigkeys (name, algorithm, secret) values ('test', 'hmac-md5', 'kp4/24gyYsEzbuTVJRUMoqGFmN3LYgVDzJ/3oRSP7ys=');
+sql> select id from domains where name='powerdnssec.org';
+5
+sql> insert into domainmetadata (domain_id, kind, content) values (5, 'AXFR-MASTER-TSIG', 'test');
+```
+
+This setup corresponds to the TSIG-ALLOW-AXFR access rule defined in the previous section.
+
+In the interest of interoperability, the configuration above is (not quite) similar to the following BIND statements:
+
+``` {.programlisting}
+key test. {
+ algorithm hmac-md5;
+ secret "kp4/24gyYsEzbuTVJRUMoqGFmN3LYgVDzJ/3oRSP7ys=";
+};
+
+server 127.0.0.1 {
+ keys { test.; };
+};
+
+zone "powerdnssec.org" {
+ type slave;
+ masters { 127.0.0.1; };
+ file "powerdnssec.org";
+};
+```
+
+Except that in this case, TSIG will be used for all communications with the master, not just those about AXFR requests.
projects / pdns / commitdiff