-@ 86400 IN SOA pdns-public-ns1.powerdns.com. peter\.van\.dijk.powerdns.com. 2024121701 10800 3600 604800 10800
+@ 86400 IN SOA pdns-public-ns1.powerdns.com. peter\.van\.dijk.powerdns.com. 2025011400 10800 3600 604800 10800
@ 3600 IN NS pdns-public-ns1.powerdns.com.
@ 3600 IN NS pdns-public-ns2.powerdns.com.
recursor-5.2.0-alpha1.security-status 60 IN TXT "1 Unsupported pre-release"
recursor-5.2.0-beta1.security-status 60 IN TXT "1 Unsupported pre-release"
recursor-5.2.0-rc1.security-status 60 IN TXT "1 Unsupported pre-release"
+recursor-5.2.0.security-status 60 IN TXT "1 OK"
; Recursor Debian
recursor-3.6.2-2.debian.security-status 60 IN TXT "3 Upgrade now, see https://doc.powerdns.com/3/security/powerdns-advisory-2015-01/ and https://doc.powerdns.com/3/security/powerdns-advisory-2016-02/"
Older releases are marked end of life and receive no updates at all.
Pre-releases do not receive immediate security updates.
-The currently supported release train of the PowerDNS Recursor is 5.1.
+The currently supported release train of the PowerDNS Recursor is 5.2.
-PowerDNS Recursor 5.0 will only receive critical updates and will be End of Life one year after PowerDNS Recursor 5.1 was released.
+PowerDNS Recursor 5.1 will only receive critical updates and will be End of Life one year after PowerDNS Recursor 5.2 was released.
-PowerDNS Recursor 4.9 will only receive critical updates and will be End of Life one year after PowerDNS Recursor 5.0 was released.
+PowerDNS Recursor 5.0 will only receive critical updates and will be End of Life one year after PowerDNS Recursor 5.1 was released.
-PowerDNS Recursor 4.0 through 4.8, 3.x, and 2.x are End of Life.
+PowerDNS Recursor 4.0 through 4.9, 3.x, and 2.x are End of Life.
Note: Users with a commercial agreement with PowerDNS.COM BV or Open-Xchange
can receive extended support for releases which are End Of Life. If you are
- Release date
- Critical-Only updates
- End of Life
+ * - 5.2
+ - January 14 2025
+ - ~ July 2025
+ - ~ July 2026
* - 5.1
- July 10 2024
- - ~ February 2025
- - ~ February 2026
+ - January 14 2025
+ - January 14 2026
* - 5.0
- January 10 2024
- July 10 2024
* - 4.9
- June 30 2023
- January 10 2024
- - January 10 2025
+ - EOL January 10 2025
* - 4.8
- December 12 2022
- June 30 2023
Before upgrading, it is advised to read the :doc:`../upgrade`.
+.. changelog::
+ :version: 5.2.0
+ :released: 14th of January 2025
+
+ .. change::
+ :tags: Bug Fixes
+ :pullreq: 15015
+ :tickets: 15010
+
+ Fix protobufServer(.. {taggedOnly=true}) logic for cache-returned responses (g0tar).
+
+ .. change::
+ :tags: Improvements
+ :pullreq: 15020
+ :tickets: 15019
+
+ Explicitly log port of listening addresses.
+
.. changelog::
:version: 5.2.0-rc1
:released: 13th of December 2024
Before upgrading, it is advised to read the :doc:`changelog/index`.
When upgrading several versions, please read **all** notes applying to the upgrade.
-5.1.0 to master
-----------------
+5.1.0 to 5.2.0 and master
+-------------------------
Changed behaviour
^^^^^^^^^^^^^^^^^
-Parsing of old-style settings is no longer enabled by default.
-Convert your settings file to YAML (see :doc:`appendices/yamlconversion`) or pass ``--enable-old-settings`` on the command line.
+
+.. warning::
+
+ **Parsing of old-style settings is no longer enabled by default.**
+
+ This means that after upgrading an existing installation using old-style settings to 5.2.0 the updated install will fail to start.
+ Convert your settings file to YAML (see :doc:`appendices/yamlconversion`) or pass ``--enable-old-settings`` on the command line.
The way :ref:`setting-yaml-incoming.max_tcp_clients` is enforced has changed.
If there are too many incoming TCP connections, new connections will be accepted but then closed immediately.
These are the YAML settings that correspond to Lua configuration items, plus a few new settings that have no Lua equivalent.
The documentation has been updated to state more clearly which settings can be modified at runtime.
+The built-in trust anchors now include the DS record for the new Key Signing Key (KSK-2024) which will be used by the root zone starting October 11th 2026. See `IANA's information page <https://www.iana.org/dnssec/files>`__.
+
Changed settings
^^^^^^^^^^^^^^^^
Starting with version 5.1.0, the settings originally specified in a Lua config file can also be put in YAML form.
The conversion printed by ``rec_control show-yaml`` will print these settings if a Lua config file is specified in the config file being converted.
You have to choose however: either set Lua settings the old way in the Lua config file, or convert all to YAML.
- If you are using YAML settings of items originally specified in the Lua config file, do not set :ref:`setting-yaml-recursor.lua_config_file` anymore. The :program:`Recursor` will check that you do not mix both configuration methods.
+ If you are using YAML settings of items originally specified in the Lua config file do not set :ref:`setting-yaml-recursor.lua_config_file` anymore. The :program:`Recursor` will check that you do not mix both configuration methods.
- When using YAML style for settings originally found in the Lua config file, ``rec_control reload-lua-config`` will reload parts of the YAML settings. Refer to the specific setting to learn if it is subject to reloading. Starting with version 5.2.0, the command ``rec_control reload-yaml`` can be used, which is an alias for ``rec_control reload-lua-config``.
+ When using YAML style for settings originally found in the Lua config file ``rec_control reload-lua-config`` will reload parts of the YAML settings. Refer to the specific setting to learn if it is subject to reloading. Starting with version 5.2.0, the command ``rec_control reload-yaml`` can be used (which is an alias for ``rec_control reload-lua-config``).
YAML settings file
------------------
'default' : '7830',
'help' : 'Packetcache tag associated to responses sent with EDNS padding, to prevent sending these to clients for which padding is not enabled.',
'doc' : '''
-The packetcache tag to use for padded responses, to prevent a client not allowed by the :ref::`setting-edns-padding-from` list to be served a cached answer generated for an allowed one. This
+The packetcache tag to use for padded responses, to prevent a client not allowed by the :ref:`setting-edns-padding-from` list to be served a cached answer generated for an allowed one. This
effectively divides the packet cache in two when :ref:`setting-edns-padding-from` is used. Note that this will not override a tag set from one of the ``Lua`` hooks.
''',
'versionadded': '4.5.0'
projects / thirdparty / pdns.git / commitdiff
