Chapter 11. Notes on upgrading

Table of Contents

1. From PowerDNS Authoritative Server 2.9.x to 3.0
1.1. Frequently Asked Questions about 3.0
2. From PowerDNS Authoritative Server 3.0 to 3.1
3. From PowerDNS Authoritative Server 3.1 to 3.2
4. From PowerDNS Authoritative Server 3.2 to 3.3
5. From PowerDNS Authoritative Server 3.3 to 3.3.1
6. From PowerDNS Authoritative Server 3.3.1 to 3.4.0
6.1. Database schema
6.2. Configuration option changes

1. From PowerDNS Authoritative Server 2.9.x to 3.0

The 3.0 release of the PowerDNS Authoritative Server is significantly different from previous 2.9.x versions. This section lists important things to be aware of.


Version 3.0 of the PowerDNS Authoritative Server is the biggest change in PowerDNS history. In some senses, this means that it behaves somewhat like a '1.0' version. We advise operators to carefully perform the upgrade process from 2.9.x, and if possible test on a copy of the database beforehand.

In addition, it may also be useful to have a support agreement in place during such upgrades. For first class and rapid support, please contact, or see Alternatively, the PowerDNS Community can be very helpful too.

With similar settings, version 3.0 will most likely use a lot more memory than 2.9. This is due to the new DNSSEC key & signature caches, but also because the database query cache will now store multiple row answers, which it did not do previously. Memory use can be brought down again by tuning the cache-ttl settings.

Performance may be up, or it may be down. We appreciate that this is spotty guidance, but depending on your setup, lookups may be a lot faster or a lot slower. The improved database cache may prove to be a big benefit, and improve performance dramatically. This could be offset by a near duplication of database queries needed because of more strict interpretation of DNS standards.

PowerDNS Authoritative Server 3.0 contains a completely renewed implementation of the core DNS 'Algorithm', loosely specified in RFC 1034. As stated above, our new implementation is a lot closer to the original standard. This may mean that version 3.0 may interpret the contents of your database differently from how 2.9.x interpreted them. For fully standards confirming zones, there should not be a problem, but if zones were misconfigured (no SOA record, for example), things will be different.

When compiling version 3.0, there are now more dependencies than there used to be. Whereas previously, only Boost header files were needed, PowerDNS now needs a number of Boost libraries to be installed (like boost-program-options, boost-serialization). In addition, for now Lua 5.1 is a dependency.

PowerDNS Authoritative Server 3.0 comes with DNSSEC support, but this has required big changes to database schemas. Each backend lists the changes required. To facilitate a smooth upgrade, the old, non-DNSSEC schema is used by default. Features like per-domain metadata, TSIG and DNSSEC itself however need the new schema. Consult your backend documentation for the correct 'alter table' statements. Afterwards, set the relevant '-dnssec' setting for your backend (for example: gmysql-dnssec).

In version 3.0, "Fancy Records", like URL, CURL and MBOXFW are no longer supported. Support may come back in later versions. In addition, the LDAP Backend has moved to 'unmaintained' status.

1.1. Frequently Asked Questions about 3.0

Q: Can 2.9.x versions read the 3.0 DNSSEC database schema?

A: Yes, every database can be altered to the new schema without impact on 2.9. The new fields and tables are ignored.

Q: Can 3.x versions read the 2.9 pre-DNSSEC database schema?

A: Yes, as long as the relevant '-dnssec' setting is not enabled. These settings are typically called 'gmysql-dnssec', 'gpgsql-dnssec', 'gsqlite3-dnssec'. If this setting IS enabled, 3.x expects the new schema to be in place.

Q: If I run 3.0 with the new schema, and I have set '-dnssec', do I need to rectify my zones?

A: Yes. If the '-dnssec' setting is enabled, PowerDNS expects the 'auth' field to be filled out correctly. When slaving zones this happens automatically. For other zones, run 'pdnssec rectify-zone zonename'. Even if a zone is not DNSSEC secured, as long as the new schema is in place, the zone must be rectified (or at least have the 'auth' field set correctly).

Q: I want to fill out the 'auth' and 'ordername' fields directly, how do I do this?

A: The 'auth' field should be '1' or 'true' for all records that are within your zone. For a zone without delegations, this means 'auth' should always be set. If you have delegations, both the NS records for that delegation and possible glue records for it should not have 'auth' set.

For more details on 'auth' and 'ordername', please see Section 8.5, “Rules for filling out fields in database backends”.

Q: If I don't update to the new DNSSEC schema, will 3.0 give identical answers as 2.9.x?

A: Not always. The core DNS logic of 3.0 was changed, so even if no changes are made to the database, you may get different answers. This might happen for zones without SOA records for example, which used to (more or less) work. An upgrade from 2.9.x to 3.0 should always be monitored carefully.