**Note**: Beyond PowerDNS 2.9.20, the Authoritative Server and Recursor are released separately.
+# PowerDNS Recursor 3.6.2
+
+**Note**: Version 3.6.2 is a bugfix update to 3.6.1. Released on the 30th of October 2014.
+
+[Official download page](https://www.powerdns.com/downloads.html)
+
+A list of changes since 3.6.1 follows.
+- [commit ab14b4f](https://github.com/PowerDNS/pdns/commit/ab14b4f): expedite servfail generation for ezdns-like failures (fully abort query resolving if we hit more than 50 outqueries)
+- [commit 42025be](https://github.com/PowerDNS/pdns/commit/42025be): PowerDNS now polls the security status of a release at startup and periodically. More detail on this feature, and how to turn it off, can be found in [Section 2, “Security polling”](secpoll.html "2. Security polling").
+- [commit 5027429](https://github.com/PowerDNS/pdns/commit/5027429): We did not transmit the right 'local' socket address to Lua for TCP/IP queries in the recursor. In addition, we would attempt to lookup a filedescriptor that wasn't there in an unlocked map which could conceivably lead to crashes. Closes [ticket 1828](https://github.com/PowerDNS/pdns/issues/1828), thanks Winfried for reporting
+- [commit 752756c](https://github.com/PowerDNS/pdns/commit/752756c): Sync embedded yahttp copy. API: Replace HTTP Basic auth with static key in custom header
+- [commit 6fdd40d](https://github.com/PowerDNS/pdns/commit/6fdd40d): add missing \#include \<pthread.h\> to rec-channel.hh (this fixes building on OS X).
+
+# PowerDNS Authoritative Server 3.4.1
+
+**Warning**: Version 3.4.1 of the PowerDNS Authoritative Server is a major upgrade if you are coming from 2.9.x. Additionally, if you are coming from any 3.x version (including 3.3.1), there is a mandatory SQL schema upgrade. Please refer to the [Upgrade documentation](authoritative/upgrading.md) for important information on correct and stable operation, as well as notes on performance and memory use.
+
+Released October 30th, 2014
+
+Find the downloads [on our download page](https://www.powerdns.com/downloads.html).
+
+This is a bugfix update to 3.4.0 and any earlier version.
+
+A list of changes since 3.4.0 follows.
+
+- [commit dcd6524](https://github.com/PowerDNS/pdns/commit/dcd6524), [commit a8750a5](https://github.com/PowerDNS/pdns/commit/a8750a5), [commit 7dc86bf](https://github.com/PowerDNS/pdns/commit/7dc86bf), [commit 2fda71f](https://github.com/PowerDNS/pdns/commit/2fda71f): PowerDNS now polls the security status of a release at startup and periodically. More detail on this feature, and how to turn it off, can be found in [Section 2, “Security polling”](secpoll.html "2. Security polling").
+- [commit 5fe6dc0](https://github.com/PowerDNS/pdns/commit/5fe6dc0): API: Replace HTTP Basic auth with static key in custom header (X-API-Key)
+- [commit 4a95ab4](https://github.com/PowerDNS/pdns/commit/4a95ab4): Use transaction for pdnssec increase-serial
+- [commit 6e82a23](https://github.com/PowerDNS/pdns/commit/6e82a23): Don't empty ordername during pdnssec increase-serial
+- [commit 535f4e3](https://github.com/PowerDNS/pdns/commit/535f4e3): honor SOA-EDIT while considering "empty IXFR" fallback, fixes [ticket 1835](https://github.com/PowerDNS/pdns/issues/1835). This fixes slaving of signed zones to IXFR-aware slaves like NSD or BIND.
+
# PowerDNS Authoritative Server 3.4.0
Released September 30th, 2014
Databases empathically do not need to run on the same machine that runs PDNS! In fact, in benchmarks it has been discovered that having a separate database machine actually improves performance.
Separation will enhance your database security highly. Recommended.
+
+# Security Polling
+As of Authoritative Server 3.4.1 and Recursor 3.6.2, PowerDNS products can poll the security status of their respective versions. This polling, naturally, happens over DNS. If the result is that a given version has a security problem, the software will report this at level 'Error' during startup, and repeatedly during operations.
+
+By default, security polling happens on the domain 'secpoll.powerdns.com', but this can be changed with the security-poll-suffix. If this setting is made empty, no polling will take place. Organizations wanting to host their own security zones can do so by changing this setting to a domain name under their control.
+
+To make this easier, the zone used to host secpoll.powerdns.com is available [here](https://github.com/PowerDNS/pdns/blob/master/pdns/docs/secpoll.zone).
+
+To enable distributors of PowerDNS to signal that they have backported versions, the PACKAGEVERSION compilation-time macro can be used to set a distributor suffix.
+
+## Details
+PowerDNS software sadly sometimes has critical security bugs. Even though we send out notifications of these via all channels available, we find that not everybody actually find out about our security releases.
+
+To solve this, PowerDNS software will start polling for security notifications, and log these periodically. Secondly, the security status of the software will be reported using the built-in metrics. This allows operators to poll for the PowerDNS security status and alert on it.
+
+In the implementation of this idea, we have taken the unique role of operating system distributors into account. Specifically, we can deal with backported security fixes.
+
+Finally, this feature can be disabled, or operators can have the automated queries point at their own status service.
+
+### Implementation
+PowerDNS software periodically tries to resolve 'auth-x.y.z.security-status.secpoll.powerdns.com|TXT' or 'recursor-x.y.z.security-status.secpoll.powerdns.com'.
+
+The data returned is in one of the following forms:
+
+* NXDOMAIN or resolution failure -> 0
+* "1 Ok" -> 1
+* "2 Upgrade recommended for security reasons, see http://powerdns.com/..." -> 2
+* "3 Upgrade mandatory for security reasons, see http://powerdns.com/..." -> 3
+
+In cases 2 or 3, periodic logging commences. The metric security-status is set to 2 or 3 respectively. If at a later date, resolution fails, the security-status is not reset to 1. It could be lowered however if we discover the security status is less urgent than we thought.
+
+If resolution fails, and the previous security-status was 1, the new security-status becomes 0 ('no data'). If the security-status was higher than 1, it will remain that way, and not get set to 0.
+
+In this way, security-status of 0 really means 'no data', and can not mask a known problem.
+
+### Distributions
+Distributions frequently backport security fixes to the PowerDNS versions they ship. This might lead to a version number that is known to us to be insecure to be secure in reality.
+
+To solve this issue, PowerDNS can be compiled with a distribution setting which will move the security polls from: 'auth-x.y.z.security-status.secpoll.powerdns.com' to 'auth-x.y.z-n.debian.security-status.secpoll.powerdns.com
+
+Note two things, one, there is a separate namespace for debian, and secondly, we use the package version of this release. This allows us to know that 3.6.0-1 (say) is insecure, but that 3.6.0-2 is not.
+
+### Configuration Details
+The configuration setting 'security-poll-suffix' is by default set to 'secpoll.powerdns.com'. If empty, nothing is polled. This can be moved to 'secpoll.yourorganization.com'.
+
+If compiled with PACKAGEVERSION=3.1.6-abcde.debian, queries will be sent to "auth-3.1.6-abcde.debian.security-status.security-poll-suffix".
+
+### Delegation
+If a distribution wants to host its own file with version information, we can delegate dist.security-status.secpoll.powerdns.com to their nameservers directly.
projects / pdns / commitdiff