We are proud to announce the second beta release of PowerDNS Recursor 4.8.0.

Compared to the previous major (4.7) release of PowerDNS Recursor, this release contains the following major changes:

• Structured Logging has been implemented for almost all subsystems. This allows for improved (automated) analysis of logging information. We’ve posted a blog about this feature recently.
• Optional Serve Stale functionality has been implemented, providing resilience against connectivity problems towards authoritative servers.
• Optional Record Locking has been implemented, providing an extra layer of protection against spoofing attempts at the price of reduced cache efficiency.
• Internal tables used to track information about authoritative servers are now shared instead of per-thread, resulting in better performance and lower memory usage.
• EDNS padding of outgoing DoT queries has been implemented, providing better privacy protection.
• Metrics have been added about the protobuf and dnstap logging subsystems and the rcodes received from authoritative servers.

As always, there are also many smaller bug fixes and improvements, please refer to the changelog for additional details. When upgrading do not forget to check the upgrade guide.

We are also announcing the removal of XPF support. If you are using this feature, switch to the proxy protocol.

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.

The tarball (signature) is available from our download server and packages for several distributions are available from our repository.

With the final 4.8 release, the 4.5.x releases will be marked “End of Life” and the 4.6.x and 4.7.x releases will go into critical fixes only mode. Consult the EOL policy for more details.

We would also like to mention that with the 4.5 release we stopped supporting systems using 32-bit time. This includes many 32-bit Linux platforms.

We are grateful to the PowerDNS community for the reporting of bugs, issues, feature requests, and especially to the submitters of fixes and implementations of features.

This is the release of version 4.7.2 of the Authoritative Server.

Just one day after releasing version 4.7.1, we realised an important fix was missing from it. Specifically, AXFR clients (secondaries) can get very busy checking for updates on primaries, or could miss updates entirely. 4.7.2 fixes this.

A full list of changes can be found in the changelog.

Please make sure to read the Upgrade Notes before upgrading.

The tarball (signature) is available at downloads.powerdns.com. Packages for various distributions are available from repo.powerdns.com.

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.

This is the release of version 4.7.1 of the Authoritative Server.

After 4.7.0 (quite recently) was released, we realised the SQL schema update files were missing. 4.7.1 corrects this. It also contains a few small fixes in the catalog zones implementation.

A full list of changes can be found in the changelog.

Please make sure to read the Upgrade Notes before upgrading.

The tarball (signature) is available at downloads.powerdns.com. Packages for various distributions are available from repo.powerdns.com.

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.

This is the release of version 4.7.0 of the Authoritative Server.

4.7.0 brings support for Catalog Zones, developed by Kees Monshouwer. As part of that development, the freshness checks in the Primary code were reworked, reducing them from doing potentially thousands of SQL queries (if you have thousands of domains) to only a few. Installations with lots of domains will benefit greatly from this, even without using catalog zones.

4.7.0 also brings back GSS-TSIG support, previously removed for quality reasons, now reworked with many stability improvements.

Other things of note:

• LUA records, when queried over TCP, can now re-use a Lua state, giving a serious performance boost.
• lmdbbackend databases now get a UUID assigned, making it easy for external software to spot if a database was completely replaced
• lmdbbackend databases now optionally use random IDs for objects
• a new LUA function called ifurlextup, and improvements in other LUA record functions
• autoprimary management in pdnsutil and the HTTP API
• in beta, a key roller daemon, currently not packaged

A full list of changes can be found in the changelog.

Please make sure to read the Upgrade Notes before upgrading.

The tarball (signature) is available at downloads.powerdns.com. Packages for various distributions are available from repo.powerdns.com.

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.

We are proud to announce the first beta release of PowerDNS Recursor 4.8.0.

Compared to the previous major (4.7) release of PowerDNS Recursor, this release contains the following major changes:

• Structured Logging has been implemented for almost all subsystems. This allows for improved (automated) analysis of logging information. We’ve posted a blog about this feature recently.
• Optional Serve Stale functionality has been implemented, providing resilience against connectivity problems towards authoritative servers.
• Optional Record Locking has been implemented, providing an extra layer of protection against spoofing attempts at the price of reduced cache efficiency.
• Internal tables used to track information about authoritative servers are now shared instead of per-thread, resulting in better performance and lower memory usage.
• EDNS padding of outgoing DoT queries has been implemented, providing better privacy protection.
• Metrics have been added about the protobuf and dnstap logging subsystems and the rcodes received from authoritative servers.

As always, there are also many smaller bug fixes and improvements, please refer to the changelog for additional details. When upgrading do not forget to check the upgrade guide.

We are also announcing the removal of XPF support. If you are using this feature, switch to the proxy protocol.

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.

The tarball (signature) is available from our download server and packages for several distributions are available from our repository.

With the final 4.8 release, the 4.5.x releases will be marked “End of Life” and the 4.6.x and 4.7.x releases will go into critical fixes only mode. Consult the EOL policy for more details.

We would also like to mention that with the 4.5 release we stopped supporting systems using 32-bit time. This includes many 32-bit Linux platforms.

We are grateful to the PowerDNS community for the reporting of bugs, issues, feature requests, and especially to the submitters of fixes and implementations of features.

This is the first release candidate for Authoritative Server 4.7.0. We hope it will also be the last 🙂

4.7.0 brings support for Catalog Zones, developed by Kees Monshouwer. As part of that development, the freshness checks in the Primary code were reworked, reducing them from doing potentially thousands of SQL queries (if you have thousands of domains) to only a few. Installations with lots of domains will benefit greatly from this, even without using catalog zones.

4.7.0 also brings back GSS-TSIG support, previously removed for quality reasons, now reworked with many stability improvements.

Other things of note:

• LUA records, when queried over TCP, can now re-use a Lua state, giving a serious performance boost.
• lmdbbackend databases now get a UUID assigned, making it easy for external software to spot if a database was completely replaced
• lmdbbackend databases now optionally use random IDs for objects
• a new LUA function called ifurlextup, and improvements in other LUA record functions
• autoprimary management in pdnsutil and the HTTP API
• in beta, a key roller daemon, currently not packaged

A full list of changes can be found in the changelog.

Please make sure to read the Upgrade Notes before upgrading.

The tarball (signature) is available at downloads.powerdns.com. Packages for various distributions are available from repo.powerdns.com.

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.

This is the fourth part of a series of blog posts we are publishing, mostly around recent developments with respect to PowerDNS Recursor. The first blog post was Refreshing Of Almost Expired Records: Keeping The Cache Hot, the second Probing DoT Support of Authoritative Servers: Just Try It and the third Sharing data between threads in PowerDNS Recursor.

Complex programs like PowerDNS Recursor need to log information about their operation. In itself this is a delicate balance: too much logging will slow the process down, too little will make it harder to diagnose issues. The question “what and how to log” is also important: up until now we have used free-format text logging. The messages itself can go to a logging daemon (e.g. systemd-journald or syslogd), a text file or the console.

The problem with free text logging is that is it very hard to keep it consistent and hard to process automatically in a reliable way. It is also not always clear (unless the creator of the message is very careful) what information is actually logged and quoting of special values is often problematic. A typical example of a free format log message looks like this (set quiet=no when running Recursor to see these detailed messages, this is not recommended in a production environment as it generates an awful lot of messages):

3 [1/1] question for 'www.powerdns.com|A' from 127.0.0.1:53408

To illustrate, unless you are very familiar with the PowerDNS code base it is unclear what the 3 1/1 part means. These are: the Posix thread-id, the mthread-id (mthreads are the user level threads used by PowerDNS Recursor) and the number of queries being resolved concurrently. Observe that automated log analysis will probably fail if the name queried contains characters like a quote or vertical bar.

Structured Logging

A structured log message consists of a set of key-value pairs. The pairs can be exported in various formats, one of them being text lines. In the text representation, a message like the one above would look like:

msg="Question" subsystem="syncres" level="0" prio="Info" tid="3" ts="1664192640.282" ecs="" mtid="1" proto="udp" qname="www.powerdns.com" qtype="A" remote="127.0.0.1:63684"

Note that each value is labelled. That is a good start to make sure we know what each part means.

There are several keys that are common to each structured log entry. These are:

• msg a short text message indicating the subject of the message instance. This part is fixed to allow for easily selection by log analysis tools.
• subsystem the component which generated the message
• level the detail level
• prio the priority
• tid the Posix thread-id
• ts a timestamp
• mtid the mthread-id

The message instance specific parts are ecs, proto, qname, qtype and remote.

The timestamp is produced by Recursor itself, which means that it is not dependent in the system used to export the log messages The structured message also adds extra information left out in the original (e.g. proto), and leaves out one item, as it was deemed to be non-relevant (the number of concurrent queries being processed).

The level value indicates the amount of detail. Higher levels indicated very detailed information, only relevant when developing or when doing very deep analysis of logs. Priority indicates if action by the administrator is required and is the same as the priority value used by e.g. syslog.

From an implementation point of view, the code that implements structured logging has a big advantage that information associated with several related log lines only has to be set up once, each generated log line will share the common information. The existing logging code would need to repeat that information with each generated log line. The structured logging code also has methods to log specific value types, like internet addresses, making sure they are always logged in the same manner.

Text format and key-value format

By default, PowerDNS Recursor sends its structured information as a formatted text string containing key-value pairs with proper quoting and escaping of quotes. On Linux system using systemd, it can also send information to systemd-journald as structured log entries. In this case systemd-journald stores the entry as a sequence of key-value pairs in a log database.

To use this logging backend, add the --structured-logging-backend=systemd-journal to the command line in the systemd unit file. Note that adding it to the recursor configuration file does not work as expected, as this file is processed after the logging has been set up.

To query the log, use a command similar to

# journalctl -r -n 1 -o json-pretty -u pdns-recursor.service 

{
"_SYSTEMD_INVOCATION_ID" : "568cd5479a5f4ea29e3c793939cd31f6",
"REMOTE" : "127.0.0.1:40908",
"PRIORITY" : "6",
"_UID" : "107",
"ECS" : "",
"_SYSTEMD_UNIT" : "pdns-recursor.service",
"__CURSOR" : "s=3e46e7865e524e19bada5d3e56e08b69;i=100129;b=8a57b91cdb5346559d48
2f5fae75bd92;m=b09c7370;t=5e99425342dfd;x=d050d34430fdca60",
"QNAME" : "www.powerdns.com",
"__MONOTONIC_TIMESTAMP" : "2963043184",
"_CAP_EFFECTIVE" : "0",
"_HOSTNAME" : "pepper",
"_COMM" : "pdns_recursor",
"_GID" : "114",
"_MACHINE_ID" : "8b32d617439149049d62119e02e2fa10",
"_SYSTEMD_CGROUP" : "/system.slice/pdns-recursor.service",
"MTID" : "1",
"_BOOT_ID" : "8a57b91cdb5346559d482f5fae75bd92",
"SUBSYSTEM" : "syncres",
"TID" : "2",
"_EXE" : "/usr/sbin/pdns_recursor",
"_PID" : "23684",
"QTYPE" : "A",
"MESSAGE" : "Question",
"LEVEL" : "0",
"_SOURCE_REALTIME_TIMESTAMP" : "1664197372161506",
"__REALTIME_TIMESTAMP" : "1664197372161533",
"_CMDLINE" : "/usr/sbin/pdns_recursor --daemon=no --write-pid=no --disable-syslo
g --log-timestamp=no --structured-logging-backend=systemd-journal",
"TIMESTAMP" : "1664197372.161",
"PROTO" : "udp",
"_SYSTEMD_SLICE" : "system.slice",
"_TRANSPORT" : "journal",
"_SELINUX_CONTEXT" : "unconfined\n",
"SYSLOG_IDENTIFIER" : "pdns_recursor"
}

As can be seen, systemd-journald adds quite a bit of extra key-value pairs and capitalises the keys. A drawback is that the information in this form is hard to parse for humans, but programs that are used for log analysis process JSON easily.

The future

In the future we will add more logging backends, to make it easy to send the structured logging information to a program used to process logs.

Note that trace information (the very detailed information on each step of the resolving process collected when debugging specific query processing using rec_control trace-regex) is not converted to structured format yet. This will be done in the near future, together with functionality to send trace logs to a specific destination for further analysis. Until then trace logs will end up in the general log, as they do now.

Reverting to old-style logging

If you already have log analysis in place, the changing of the logging information might disrupt your log processing. Switch back to tradition logging by setting structured-logging to no. New functionality requiring logging will implement structured logging only. When structured-logging is set to no, these new subsystems will output a textual representation of the key-value pairs.

Status and Conclusion

The structured logging system has been used by a few subsystems already in recent releases. The full conversion will appear in version 4.8.0, to be released in the near future. Pre-releases already allow you to see structured logging in action. With structured logging, log analysis of PowerDNS Recursor will become more easy, as the information is structured in a uniform way.

We are proud to announce the first alpha release of PowerDNS Recursor 4.8.0.

Compared to the previous major (4.7) release of PowerDNS Recursor, this release contains the following major changes:

• Structured Logging has been implemented for almost all subsystems. This allows for improved (automated) analysis of logging information.
• Optional Serve Stale functionality has been implemented, providing resilience against connectivity problems towards authoritative servers.
• Optional Record Locking has been implemented, providing an extra layer of protection against spoofing attempts at the price of reduced cache efficiency.
• Internal tables used to track information about authoritative servers are now shared instead of per-thread, resulting in better performance and lower memory usage.
• EDNS padding of outgoing DoT queries has been implemented, providing better privacy protection.

As always, there are also many smaller bug fixes and improvements, please refer to the changelog for additional details. When upgrading do not forget to check the upgrade guide.

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.

The tarball (signature) is available from our download server and packages for several distributions are available from our repository.

With the final 4.8 release, the 4.5.x releases will be EOL and the 4.6.x and 4.7.x releases will go into critical fixes only mode. Consult the EOL policy for more details.

We would also like to mention that with the 4.5 release we stopped supporting systems using 32-bit time. This includes many 32-bit Linux platforms.

We also like to announce the upcoming removal of XPF support. If you are using this feature, plan switching to the proxy protocol.

We are grateful to the PowerDNS community for the reporting of bugs, issues, feature requests, and especially to the submitters of fixes and implementations of features.

Hello,

Today we have released a maintenance release of PowerDNS Recursor 4.5.11, 4.6.4 and 4.7.3, containing fixes for a few minor issues and performance enhancements in the case Recursor is confronted with connectivity issues to authoritative servers.

The changelogs are available at 4.5.11, 4.6.4, 4.7.3.

The source tarballs (4.5.11, 4.6.4, 4.7.3) and signatures (4.5.11, 4.6.4, 4.7.3) are available from our download server. Packages for various distributions are available from our repository.

Note that PowerDNS Recursor 4.4.x and older releases are End of Life. Consult the EOL policy for more details.

We would also like to repeat that starting with the 4.5 release branch we stopped supporting systems using 32-bit time. This includes most 32-bit Linux platforms.

We are grateful to the PowerDNS community for the reporting of bugs, issues, feature requests, and especially to the submitters of fixes and implementations of features.

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.

Hello!

this is the first Beta release for Authoritative Server 4.7.0, even though it is called beta2. (beta1 was never released because of bugs found during the release process).

4.7.0 brings support for Catalog Zones, developed by Kees Monshouwer. As part of that development, the freshness checks in the Primary code were reworked, reducing them from doing potentially thousands of SQL queries (if you have thousands of domains) to only a few. Installations with lots of domains will benefit greatly from this, even without using catalog zones.

4.7.0 also brings back GSS-TSIG support, previously removed for quality reasons, now reworked with many stability improvements.

Other things of note:

• LUA records, when queried over TCP, can now re-use a Lua state, giving a serious performance boost.
• lmdbbackend databases now get a UUID assigned, making it easy for external software to spot if a database was completely replaced
• lmdbbackend databases now optionally use random IDs for objects
• a new LUA function called ifurlextup, and improvements in other LUA record functions
• autoprimary management in pdnsutil and the HTTP API

A full list of changes can be found in the changelog.

Please make sure to read the Upgrade Notes before upgrading.

The tarball (signature) is available at downloads.powerdns.com. Packages for various distributions are available from repo.powerdns.com.

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.