From justin at postgresql.org Thu Feb 4 14:22:34 2016 From: justin at postgresql.org (Justin Clift) Date: Thu, 4 Feb 2016 14:22:34 +0000 Subject: [Pdns-dev] Authoritative Server 3.4.8 released In-Reply-To: <01221263-FE95-46DD-B6FC-60DDC0D639C4@powerdns.com> References: <01221263-FE95-46DD-B6FC-60DDC0D639C4@powerdns.com> Message-ID: <7A6D11B0-AD7E-4120-85C1-49D10F055E39@postgresql.org> The MacOS X Homebrew port for pdns has been updated to 3.4.8 now too (as of yesterday). :) + Justin On 3 Feb 2016, at 11:01, Peter van Dijk wrote: > Hi everybody, > > We're pleased to announce version 3.4.8 of our Authoritative Server. > > This is a small bugfix release to 3.4.7. Additionally, the deb/RPM packages on > downloads.powerdns.com (those with -static in the name) for 3.4.8 have been > built against Botan 1.10.11 instead of Botan 1.10.3 like previous packages. > Please see [the Botan Security page](http://botan.randombit.net/security.html) > for more information on the fixes in Botan 1.10.11. As a PowerDNS user, these > issues only affect you if you ran our -static packages *and* allowed your > users to upload private keys to your configuration. > > Tar.gz and packages are available on: > > * https://downloads.powerdns.com/releases/ > * Soon: https://www.monshouwer.eu/download/3rd_party/pdns/ > (RHEL/CentOS, with the usual huge thanks to Kees Monshouwer). > > Warning: Version 3.4.8 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 for important information on correct and > stable operation, as well as notes on performance and memory use. > > Find the downloads on our download page, > https://www.powerdns.com/downloads.html > > Changes since 3.4.7: > - [commit edfa60a](https://github.com/PowerDNS/pdns/commit/edfa60a): Use AC_SEARCH_LIBS (Ruben Kerkhof) > - [commit 7b7a3af](https://github.com/PowerDNS/pdns/commit/7b7a3af): Check for inet_aton in libresolv (Ruben Kerkhof) > - [commit 9322aee](https://github.com/PowerDNS/pdns/commit/9322aee): Remove hardcoded -lresolv, -lnsl and -lsocket (Ruben Kerkhof) > - [commit 23d26d8](https://github.com/PowerDNS/pdns/commit/23d26d8): pdnssec: don't check disabled records (Pieter Lexis) > - [commit ce92ff1](https://github.com/PowerDNS/pdns/commit/ce92ff1): pdnssec: check all records (including disabled ones) only in verbose mode (Kees Monshouwer) > - [commit f745312](https://github.com/PowerDNS/pdns/commit/f745312): traling dot in DNAME content (Kees Monshouwer) > - [commit ed02761](https://github.com/PowerDNS/pdns/commit/ed02761): Fix luabackend compilation on FreeBSD i386 (RvdE) > - [commit 07ea6ac](https://github.com/PowerDNS/pdns/commit/07ea6ac): silence g++ 6.0 warnings and error (Kees Monshouwer) > - [commit c6077b1](https://github.com/PowerDNS/pdns/commit/c6077b1): add gcc 5.3 and 6.0 support to boost.m4 (Kees Monshouwer) > > Kind regards, > -- > Peter van Dijk > PowerDNS.COM BV - https://www.powerdns.com/ > > _______________________________________________ > Pdns-dev mailing list > pdns-dev at mailman.powerdns.com > https://mailman.powerdns.com/listinfo/pdns-dev at mailman.powerdns.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From megan at edgewave.com Fri Feb 19 06:15:25 2016 From: megan at edgewave.com (Michael Egan) Date: Fri, 19 Feb 2016 06:15:25 +0000 Subject: [Pdns-dev] Bug in "pdns-3.4.8" in m4/boost.m4 ? Message-ID: When trying to build pdns-3.4.8, I encountered a problem during boost version detection, which looked something like this when ./configure (with all options I wanted, run) ... pdns: checking for Boost headers version >= 1.35.0... /usr/include pdns: checking for Boost's header version... pdns: configure: error: invalid value: boost_major_version='' ... I think I tracked down the cause of this to m4/boost.m4 See this section of code in m4/boost.m4: ... ---- cut here ---- dnl # 1 "conftest.cc" dnl # 1 "" dnl # 1 "" dnl # 1 "conftest.cc" dnl # 1 "/opt/local/include/boost/version.hpp" 1 3 dnl # 2 "conftest.cc" 2 dnl boost-lib-version = dnl # 2 "conftest.cc" 3 dnl "1_56" dnl dnl So get rid of the # lines, and glue the remaining ones together. (eval "$ac_cpp conftest.$ac_ext") 2>&AS_MESSAGE_LOG_FD | grep -v '#' | tr -d '\r' | tr -s '\n' ' ' | $SED -n -e "$1" >conftest.i 2>&1], [$3], [$4]) rm -rf conftest* AC_LANG_POP([C++])dnl ])# _BOOST_SED_CPP # BOOST_REQUIRE([VERSION], [ACTION-IF-NOT-FOUND]) ---- cut here ---- ... Notice the line: "rm -rf conftest*" This removes not only "conftest.$ac_ext" but also removes "conftest.i" But we still need "conftest.i" later in the script in this section: ... ---- cut here ---- AC_CACHE_CHECK([for Boost's header version], [boost_cv_lib_version], [m4_pattern_allow([^BOOST_LIB_VERSION$])dnl _BOOST_SED_CPP([[/^boost-lib-version = /{s///;s/[\" ]//g;p;q;}]], [#include boost-lib-version = BOOST_LIB_VERSION], [boost_cv_lib_version=`cat conftest.i`])]) ---- cut here ---- ... Without "conftest.i" present, the detected version ends up being '' (empty) A suggested change? ---- cut here ---- --- pdns-3.4.8-orig/m4/boost.m4 2016-02-02 20:31:19.000000000 +0000 +++ pdns-3.4.8/m4/boost.m4 2016-02-19 06:11:51.832492331 +0000 @@ -94,12 +94,10 @@ $SED -n -e "$1" >conftest.i 2>&1], [$3], [$4]) -rm -rf conftest* +rm -rf conftest.$ac_ext AC_LANG_POP([C++])dnl ])# _BOOST_SED_CPP - - # BOOST_REQUIRE([VERSION], [ACTION-IF-NOT-FOUND]) # ----------------------------------------------- # Look for Boost. If version is given, it must either be a literal of the form @@ -229,6 +227,7 @@ [#include boost-lib-version = BOOST_LIB_VERSION], [boost_cv_lib_version=`cat conftest.i`])]) + rm -rf conftest.* # e.g. "134" for 1_34_1 or "135" for 1_35 boost_major_version=`echo "$boost_cv_lib_version" | sed 's/_//;s/_.*//'` case $boost_major_version in #( ---- cut here ---- Feedback welcome. Hope this helps, -ME -------------- next part -------------- An HTML attachment was scrubbed... URL: From megan at edgewave.com Fri Feb 19 10:40:28 2016 From: megan at edgewave.com (Michael Egan) Date: Fri, 19 Feb 2016 10:40:28 +0000 Subject: [Pdns-dev] Bug in "pdns-3.4.8" in m4/boost.m4 ? In-Reply-To: References: Message-ID: Apologies: report appears to be premature. There was an issue with how environmental variables were set, and interfering with boost library version detection. Please ignore. Thanks! -ME [chop] -------------- next part -------------- An HTML attachment was scrubbed... URL: From labs at hosting.de Fri Feb 19 16:38:00 2016 From: labs at hosting.de (labs at hosting.de) Date: Fri, 19 Feb 2016 17:38:00 +0100 Subject: [Pdns-dev] implement GSQLBackend::getDirectNSECx Message-ID: <56C744E8.8020601@hosting.de> Dear PDNS-Devs, we use PowerDNS version 3.4 for our nameserver backend. Recently we have added a signing server which signs zones with ldns. Ldns creates both NSEC(3) and NSEC3PARAM records. As PowerDNS synthesizes these records we have to throw them away and create record ordernames and domain metadata to add the zone to our nameservers. We couldn't find much documentation about how to add presigned zones to a PowerDNS database, so it took a while to get this to work. Now we have a signing server that is tightly coupled to our nameserver even though both systems work completely independently. While looking through the PowerDNS code we found the calls to UeberBackend::getDirectNSECx in PacketHandler::addNSEC and PacketHandler::addNSEC3 and noticed that UeberBackend::getDirectNSECx calls DNSBackend::getDirectNSECx for every backend. However, that method isn't implemented in the GSQLBackend, which we use. What we would like to do is implement GSQLBackend::getDirectNSECx to fetch NSEC(3) records from the database, if they are stored there, or else return false. Additionaly we would like to expand the PacketHandler::addNSEC3Param method to try to fetch the NSEC3PARAM record from the database before synthesizing one as well. What we would like to know is if you would be interested in those changes and would be willing to accept a corresponding pull request? Best regards, Sebastian Melinat hosting.de GmbH From cmouse at youzen.ext.b2.fi Sun Feb 21 08:10:03 2016 From: cmouse at youzen.ext.b2.fi (Aki Tuomi) Date: Sun, 21 Feb 2016 10:10:03 +0200 Subject: [Pdns-dev] implement GSQLBackend::getDirectNSECx In-Reply-To: <56C744E8.8020601@hosting.de> References: <56C744E8.8020601@hosting.de> Message-ID: <20160221081003.GA26965@pi.ip.fi> On Fri, Feb 19, 2016 at 05:38:00PM +0100, labs at hosting.de wrote: > Dear PDNS-Devs, > > we use PowerDNS version 3.4 for our nameserver backend. Recently we > have added a signing server which signs zones with ldns. Ldns > creates both NSEC(3) and NSEC3PARAM records. As PowerDNS synthesizes > these records we have to throw them away and create record > ordernames and domain metadata to add the zone to our nameservers. > We couldn't find much documentation about how to add presigned zones > to a PowerDNS database, so it took a while to get this to work. Now > we have a signing server that is tightly coupled to our nameserver > even though both systems work completely independently. > > While looking through the PowerDNS code we found the calls to > UeberBackend::getDirectNSECx in PacketHandler::addNSEC and > PacketHandler::addNSEC3 and noticed that > UeberBackend::getDirectNSECx calls DNSBackend::getDirectNSECx for > every backend. However, that method isn't implemented in the > GSQLBackend, which we use. > > What we would like to do is implement GSQLBackend::getDirectNSECx to > fetch NSEC(3) records from the database, if they are stored there, > or else return false. > > Additionaly we would like to expand the PacketHandler::addNSEC3Param > method to try to fetch the NSEC3PARAM record from the database > before synthesizing one as well. > > What we would like to know is if you would be interested in those > changes and would be willing to accept a corresponding pull request? > > Best regards, > > Sebastian Melinat > hosting.de GmbH Hi! Can you please open an issue at https://github.com/PowerDNS/pdns about this? It is not very difficult feature to implement, but it's best remembered if you open one. Aki From peter.van.dijk at powerdns.com Sun Feb 21 08:20:42 2016 From: peter.van.dijk at powerdns.com (Peter van Dijk) Date: Sun, 21 Feb 2016 09:20:42 +0100 Subject: [Pdns-dev] implement GSQLBackend::getDirectNSECx In-Reply-To: <56C744E8.8020601@hosting.de> References: <56C744E8.8020601@hosting.de> Message-ID: Hello Sebastian, On 19 Feb 2016, at 17:38, labs at hosting.de wrote: > we use PowerDNS version 3.4 for our nameserver backend. Recently we > have added a signing server which signs zones with ldns. Ldns creates > both NSEC(3) and NSEC3PARAM records. As PowerDNS synthesizes these > records we have to throw them away and create record ordernames and > domain metadata to add the zone to our nameservers. We couldn't find > much documentation about how to add presigned zones to a PowerDNS > database, so it took a while to get this to work. Now we have a > signing server that is tightly coupled to our nameserver even though > both systems work completely independently. Out of curiosity, why are you signing outside of PowerDNS instead of with PowerDNS itself? Second, have you looked at AXFRing the zones in from your signing solution, instead of mangling a presigned zone until PowerDNS likes it? If you let PowerDNS do the AXFR in, all the throwing away of records etc. happens automatically. > While looking through the PowerDNS code we found the calls to > UeberBackend::getDirectNSECx in PacketHandler::addNSEC and > PacketHandler::addNSEC3 and noticed that UeberBackend::getDirectNSECx > calls DNSBackend::getDirectNSECx for every backend. However, that > method isn't implemented in the GSQLBackend, which we use. These methods are gone in version 4 - they were only used by the LMDB backend for hacky reasons, and we dropped the LMDB backend in that form. > What we would like to do is implement GSQLBackend::getDirectNSECx to > fetch NSEC(3) records from the database, if they are stored there, or > else return false. Are you running into problems with the ‘synthesized’ NSEC(3)s? > Additionaly we would like to expand the PacketHandler::addNSEC3Param > method to try to fetch the NSEC3PARAM record from the database before > synthesizing one as well. > > What we would like to know is if you would be interested in those > changes and would be willing to accept a corresponding pull request? We need to understand what problem is being solved before we’ll consider this added complexity (ignoring, for a moment, that the -x calls are not even present in 4). Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From labs at hosting.de Mon Feb 22 11:20:50 2016 From: labs at hosting.de (labs at hosting.de) Date: Mon, 22 Feb 2016 12:20:50 +0100 Subject: [Pdns-dev] implement GSQLBackend::getDirectNSECx In-Reply-To: References: <56C744E8.8020601@hosting.de> Message-ID: <56CAEF12.4090106@hosting.de> Hi Peter, thanks for getting back to us that quickly. > Out of curiosity, why are you signing outside of PowerDNS instead of with PowerDNS itself? > ... > Second, have you looked at AXFRing the zones in from your signing solution, instead of mangling a presigned zone until PowerDNS likes it? > If you let PowerDNS do the AXFR in, all the throwing away of records etc. happens automatically. As described, we created a signing server only reachable internally for security reasons. This means all private keys are stored on this system and all signing is done there. Since pdns synthesizes the DNSSEC records it is not possible, besides via AXFR, to export and transfer these records. Therefore we decided to use LDNS for signing. > Are you running into problems with the ‘synthesized’ NSEC(3)s? Currently we have to create those empty traversals in order to get the correct NSEC records synthesized. Since signing with LDNS already gives us all necessary NSEC records it would be easier to just use those. I get the decission to do as much as possible automatically for DNSSEC since it is a complex subject. On the other hand it would be nice if there would be still the possibility to have more control over the process if you want to in case you have a more complex nameserver setup in mind. Best regards, Sebastian Am 21.02.2016 09:20, schrieb Peter van Dijk: > Hello Sebastian, > > On 19 Feb 2016, at 17:38, labs at hosting.de wrote: > >> we use PowerDNS version 3.4 for our nameserver backend. Recently we >> have added a signing server which signs zones with ldns. Ldns creates >> both NSEC(3) and NSEC3PARAM records. As PowerDNS synthesizes these >> records we have to throw them away and create record ordernames and >> domain metadata to add the zone to our nameservers. We couldn't find >> much documentation about how to add presigned zones to a PowerDNS >> database, so it took a while to get this to work. Now we have a >> signing server that is tightly coupled to our nameserver even though >> both systems work completely independently. > > Out of curiosity, why are you signing outside of PowerDNS instead of > with PowerDNS itself? > > Second, have you looked at AXFRing the zones in from your signing > solution, instead of mangling a presigned zone until PowerDNS likes > it? If you let PowerDNS do the AXFR in, all the throwing away of > records etc. happens automatically. > >> While looking through the PowerDNS code we found the calls to >> UeberBackend::getDirectNSECx in PacketHandler::addNSEC and >> PacketHandler::addNSEC3 and noticed that UeberBackend::getDirectNSECx >> calls DNSBackend::getDirectNSECx for every backend. However, that >> method isn't implemented in the GSQLBackend, which we use. > > These methods are gone in version 4 - they were only used by the LMDB > backend for hacky reasons, and we dropped the LMDB backend in that form. > >> What we would like to do is implement GSQLBackend::getDirectNSECx to >> fetch NSEC(3) records from the database, if they are stored there, or >> else return false. > > Are you running into problems with the ‘synthesized’ NSEC(3)s? > >> Additionaly we would like to expand the PacketHandler::addNSEC3Param >> method to try to fetch the NSEC3PARAM record from the database before >> synthesizing one as well. >> >> What we would like to know is if you would be interested in those >> changes and would be willing to accept a corresponding pull request? > > We need to understand what problem is being solved before we’ll > consider this added complexity (ignoring, for a moment, that the -x > calls are not even present in 4). > > Kind regards, From bert.hubert at powerdns.com Tue Feb 23 10:14:41 2016 From: bert.hubert at powerdns.com (bert hubert) Date: Tue, 23 Feb 2016 11:14:41 +0100 Subject: [Pdns-dev] An important update on new PowerDNS Products Message-ID: Hi everybody, This is a heads-up on some announcements you will be seeing on powerdns.com relating to new PowerDNS products which (gasp) are not fully Open Source. We know this is a sensitive subject, so before we go live, we want to inform you fully of what we are doing. We’d also like to hear & incorporate your feedback. The tl;dr: PowerDNS will remain enthusiastically Open Source, but we will be selling a ready-to use ‘Platform’ of PowerDNS Open Source & other technologies, without degrading our current products. For details, please read on. As you may know, PowerDNS sells support on the core nameserver technologies: PowerDNS Authoritative Server , PowerDNS Recursor and dnsdist . And this is going well, well enough to fund four full-time developers & engineers . This delivers a lot of value to the Open Source world. Over the past few years, as part of our paid support, we have also been delivering custom PowerDNS configurations based on our open source products. Such configurations integrate with Graphite, Ansible, exabgp, bird, iptables and loads of other products to deliver features like parental control, configuration management, governmental/judicial blacklists, DoS protection of (legacy) nameservers, malware filtering, quarantining, NXDOMAIN redirection, “customer communications”, monitoring, user-experience graphing, audit trail of configuration changes, (management) reporting, webbased control, BGP/OSPF/VRRP failover, ‘production’ DNS64 etc etc. What we have also found is that many of our users  (big hosters, large scale telecommunications service providers) need more from us than “/usr/sbin/pdns_recursor”. Although PowerDNS can easily be integrated with lots of things to deliver powerful functionalities and many of our users still love open source, they would prefer to get it packaged in a more ready to use way. Putting it more strongly: we have learned that many organizations simply no longer have the time or desire to assemble all the technologies themselves around our Open Source products. We will therefore be marketing the additional functionalities we have been delivering to our customers as a product tentatively called the “PowerDNS Platform”. I say tentatively because we want to inform you of this news first, even before we have settled on a name and updated our website with the new product. The “PowerDNS Platform” as we ship it consists of our core unmodified Open Source products, plus loads of other open source technologies, combined with a management shell that is not an Open Source product that we’ll in fact sell. Now, we understand this may be worrying some to some of you. Some formerly truly Open Source products like MySQL are going down a path where you can see their products turning into a sales pitch for the commercially licensed version. Some other Open Source nameservers have used their liberal licensing to sell ‘subscriber versions ‘ of their software that have additional core functionalities. This might create doubt if the product in its Open Source version will retain the capabilities discerning users of open software demand. We would therefore like to clarify that we regard our core Open Source products as our crown jewels, jewels which only shine because we are an integral part of the DNS and PowerDNS Communities with whom we work together to create great software.We will continue to make sure that our nameserver software is a viable and hopefully even the best choice for the Internet at large. And in fact, there will not be “two versions” of the PowerDNS nameserver software: of the actual daemons there will be just one version – also because we would otherwise not get the advantages of scale we get from over 150000 deployments! Simultaneously, we hope that by bringing PowerDNS in a more integrated fashion will enable more companies to benefit from running Open Source & open standards based software. Because this is what deeply believe in – that the future of the world is open , and that software can simultaneously be good Open Source and also work well in a commercial environment . Thank you for reading this to the end! We would like to hear your feedback and perhaps worries. Please contact me onbert.hubert at powerdns.com to let us know your thoughts and concerns. Bert -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.van.dijk at powerdns.com Tue Feb 23 10:49:19 2016 From: peter.van.dijk at powerdns.com (Peter van Dijk) Date: Tue, 23 Feb 2016 11:49:19 +0100 Subject: [Pdns-dev] implement GSQLBackend::getDirectNSECx In-Reply-To: <56CAEF12.4090106@hosting.de> References: <56C744E8.8020601@hosting.de> <56CAEF12.4090106@hosting.de> Message-ID: <92015242-C482-42F6-925D-5CC0EDED361B@powerdns.com> Hello, On 22 Feb 2016, at 12:20, labs at hosting.de wrote: > > Out of curiosity, why are you signing outside of PowerDNS instead of > with PowerDNS itself? > > ... > > Second, have you looked at AXFRing the zones in from your signing > solution, instead of mangling a presigned zone until PowerDNS likes > it? > > If you let PowerDNS do the AXFR in, all the throwing away of records > etc. happens automatically. > > As described, we created a signing server only reachable internally > for security reasons. This means all private keys are stored on this > system and all signing is done there. Since pdns synthesizes the > DNSSEC records it is not possible, besides via AXFR, to export and > transfer these records. Therefore we decided to use LDNS for signing. Understood. Of course AXFR is a fine export method, and the resulting file should be similar to your LDNS results. > > Are you running into problems with the ‘synthesized’ NSEC(3)s? > > Currently we have to create those empty traversals in order to get the > correct NSEC records synthesized. Since signing with LDNS already > gives us all necessary NSEC records it would be easier to just use > those. Can you clarify what you mean by empty traversals? What is your full procedure for serving a lens-signed zone file with PowerDNS today? Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From labs at hosting.de Tue Feb 23 12:18:32 2016 From: labs at hosting.de (labs at hosting.de) Date: Tue, 23 Feb 2016 13:18:32 +0100 Subject: [Pdns-dev] implement GSQLBackend::getDirectNSECx In-Reply-To: <92015242-C482-42F6-925D-5CC0EDED361B@powerdns.com> References: <56C744E8.8020601@hosting.de> <56CAEF12.4090106@hosting.de> <92015242-C482-42F6-925D-5CC0EDED361B@powerdns.com> Message-ID: <56CC4E18.8000106@hosting.de> Hello Peter, > Can you clarify what you mean by empty traversals? What is your full > procedure for serving a lens-signed zone file with PowerDNS today? following an example of a zone signed by ldns. As you can see, it contains not only RRSIG, but also 3 NSEC3 and the NSEC3PARAM record. In order to publish the zone with pdns we have to remove these 4 records from the zone. Then we have to take the content of the NSEC3PARAM record and add it to domainmetadata as a 'NSEC3PARAM' entry, along with a 'PRESIGNED' entry. The zone contains one record at its apex and one in sub2.sub1.dnssec-secured.com, but none in sub1.dnssec-secured.com, so next we have to create a record of type NULL for sub1.dnssec-secured.com, the empty traversal record. After that we have to determine the ordername for the A, NS, SOA and the empty traversal records, and have to remember to set the ordername to NULL in our RRSIG and DNSKEY records (but to an empty string, not NULL, for records on the apex if we sign with NSEC instead of NSEC3) If instead it would be possible to use the NSEC(3) and NSEC3PARAM records as ldns creates them we wouldn't have to do all this. We could just add the records to our database as they are and ignore the ordername and metadata. This would save us work, would make our system more robust and would be more secure when updating pdns. #################### dnssec-secured.com. 172800 IN SOA testns1.keenlogics.com. admin.dnssec-secured.com. 2016022302 86400 7200 3600000 3600 dnssec-secured.com. 172800 IN RRSIG SOA 8 2 172800 20160324114814 20160223114814 24828 dnssec-secured.com. RhmWWAJetR0cOLAVN2L8rMs/rECWpHCox0NCV6FR3VR9thDlrAPLqh5ImCQAg+LxlFq5Xensa2aQU8UvWVyJUJkt6tYHgP6cyDitq/jHPwrfEulpY1iOYGuRaLkNRP1VKRF189vhc0gAoKcGLt8++UpKorKUaK0AQZXlJ2tM0Os= dnssec-secured.com. 86000 IN A 172.27.171.106 dnssec-secured.com. 86000 IN RRSIG A 8 2 86000 20160324114814 20160223114814 24828 dnssec-secured.com. tBh8QHPoFoUypROAOeIWZD0O4j4ugiwaJUrTVyFFA+j/l393QLSRbxkZvjqGCrsf3pwTvEYALL3cepLg3JMwwXeTZEb84EK/hKPbhYyuyOYm2es+yghiswIuCD1ejx1TXD5jD4c6UMwNf2LI4AlHCfWVclWA1yktOo2Rhi8Rjr0= dnssec-secured.com. 86000 IN NS testns1.keenlogics.com. dnssec-secured.com. 86000 IN NS testns2.keenlogics.com. dnssec-secured.com. 86000 IN RRSIG NS 8 2 86000 20160324114814 20160223114814 24828 dnssec-secured.com. wXfzEvQNd5hLz1p6XN9T6LdcXPfdaS2W7IOgrMb3hwKQbSul03772DU0TxenJBYrJIBiVlp8/BjP5k68+1nT09muPTA8YTEjajLWowVtcdlQBNBvHqst8xVoGiojBvRcxOgx1riGoYXVDX2WqIZTxZKI5T9c4OUxPypuyT9BCVc= dnssec-secured.com. 3600 IN DNSKEY 256 3 8 AwEAAcKDdu9TSNxyuE4AxJBsSpLSlpmOjC3mSLIRL+O/ox+ip0kyu/kWia+ItyN8O+LQT7ZxPM0kgsPde5iNJm1oQzksYWqI9uWyN8Xg/z7+e8P7wXAU8hh+VsJ4CuKx0KitGgF8ywCBjvPBlXxW2wUqDZ/PuWS4pfDdPfJoGJOo+oBj ;{id = 24828 (zsk), size = 1024b} dnssec-secured.com. 3600 IN DNSKEY 257 3 8 AwEAAedRPE4ShQYyimigcjM5hkfkkILqc5MsEl1IOMH4Etxs+d0IqKqHiHIxuCWWvLIdhuInl9P1JwrusURKW0D0s2nrRgP/vJix766UcojySuANOzC2LKQ7YWbze/0k9OdMlvadmAr9vcs8PeJJ0OLA9ZTA+JIFxqliDceSKmACQE0l ;{id = 22939 (ksk), size = 1024b} dnssec-secured.com. 3600 IN RRSIG DNSKEY 8 2 3600 20160324114814 20160223114814 22939 dnssec-secured.com. yu/DVtu/e8sQWSbOKqngObf9ePpg6F8g1uh88g1ddEcSuOfbAj1J2Gkgo2a8DCSLiQXnV7ehNL1mYQfChRRWTXraVc65RyngM/bF8RFQDaoqJ2Jo+uNe723haStX8JGirFqPd9MyNoBRccAg0Yrd7GEhM6aZjXbqpaOrFdoFfEA= dnssec-secured.com. 3600 IN NSEC3PARAM 1 0 1 - dnssec-secured.com. 3600 IN RRSIG NSEC3PARAM 8 2 3600 20160324114814 20160223114814 24828 dnssec-secured.com. saBC+M4W+gUaa5a5zxUUFXliR71Xjmo+jX0FGUktRgZdufGAj/bCK66RaH/AANM6Spwhhf+snHti72iIZ5SvGTOWtiIMytgR2Q3dGeUGYwSN05Z/8jVklfj6drojV+ddn4xG6x9WvuFdvEpUJZeef5L9FrQr5ykuis6fqWExyBM= 31igt9vki6e04vr59abcnr3f5b6v00mq.dnssec-secured.com. 3600 IN NSEC3 1 0 1 - 84aemukrq7geiupopk0fbhfl9qdeuqtv A NS SOA RRSIG DNSKEY NSEC3PARAM 31igt9vki6e04vr59abcnr3f5b6v00mq.dnssec-secured.com. 3600 IN RRSIG NSEC3 8 3 3600 20160324114814 20160223114814 24828 dnssec-secured.com. MqziEpAWoMjDjSdQdXHBVQAGmQ2v9U0d+8MpS5lxZ/HKi8X8dUH6e/R9cHgihQGW5UU0P4TXLailA3RzjotWOXg1EoSbMl3D8BXjdJeMK3hFdh48CFBbRGiIea9CR8gPGMH2q1q8L0yFpYdRUBccTnegq6h/YIhA0aEaQ3oVnD4= 84aemukrq7geiupopk0fbhfl9qdeuqtv.dnssec-secured.com. 3600 IN NSEC3 1 0 1 - eahu8v3vmje1b3cef5687r8dmm2i5bu7 84aemukrq7geiupopk0fbhfl9qdeuqtv.dnssec-secured.com. 3600 IN RRSIG NSEC3 8 3 3600 20160324114814 20160223114814 24828 dnssec-secured.com. e9CqJcsIxieO0HOJ+Gi/a4m+d3eBBf7DSKdJLWDlpsVYSr7qMVCnFIvQoag16BewfcrakbYiUSZGHCG+lU0SUomLhAOpZkh2pxKFul+dUZ8eYIhk/qR7BgYt1Eejl1LELKVTk4XdS2wmJmdurWnREojCxy/6ZKQd98EHmB0px1Q= sub2.sub1.dnssec-secured.com. 86000 IN A 172.27.171.106 sub2.sub1.dnssec-secured.com. 86000 IN RRSIG A 8 4 86000 20160324114814 20160223114814 24828 dnssec-secured.com. u2okLkbbAL9w16qeOUo6q/Js3WPXbYFcMmQEu4sR34LYK5rKf0Xz8M1w54tN4By0v1gVflj9+LDytra1udHNTmNQpVRGxrBQArn2xDOjoAdgTSP4J2CCRPYWMHJeFxTNMCQkDUiM8dP1hhz23vPDLVmtVgIkBuy18lBm8hiZdzA= eahu8v3vmje1b3cef5687r8dmm2i5bu7.dnssec-secured.com. 3600 IN NSEC3 1 0 1 - 31igt9vki6e04vr59abcnr3f5b6v00mq A RRSIG eahu8v3vmje1b3cef5687r8dmm2i5bu7.dnssec-secured.com. 3600 IN RRSIG NSEC3 8 3 3600 20160324114814 20160223114814 24828 dnssec-secured.com. g6rPoNVsmlthX3B2wvrc8gSJFhpKHvD67XpnlJwCeIPf0p0hy8IH3/Kd2d+E3FT8kVOOhsRFjFtLRpfYfzWTguasK6RoVD6r5+IdJvhwFI/ZMNP7gHm60rk5juuDvA2wpJdulyqv2GYFY21P0BsoeBQMJ4VZIbF/KNwthl/lE9Q= ​ #################### Best regards, Sebastian hosting.de GmbH From justin at postgresql.org Tue Feb 23 13:27:57 2016 From: justin at postgresql.org (Justin Clift) Date: Tue, 23 Feb 2016 13:27:57 +0000 Subject: [Pdns-dev] An important update on new PowerDNS Products In-Reply-To: References: Message-ID: <4e2872cbd87bc16caf69450ba7ea34ef@postgresql.org> > We would therefore like to clarify that we regard our core Open Source products as our crown jewels This seems to be missing the reason why the new "Platform" is better off non-OSS? Is it a case of wanting the Platform to be a competative differentiator? (GitHub style?) + Justin From bert.hubert at powerdns.com Tue Feb 23 14:12:51 2016 From: bert.hubert at powerdns.com (bert hubert) Date: Tue, 23 Feb 2016 15:12:51 +0100 Subject: [Pdns-dev] An important update on new PowerDNS Products In-Reply-To: <4e2872cbd87bc16caf69450ba7ea34ef@postgresql.org> References: <4e2872cbd87bc16caf69450ba7ea34ef@postgresql.org> Message-ID: <20160223141251.GG26905@server.ds9a.nl> On Tue, Feb 23, 2016 at 01:27:57PM +0000, Justin Clift wrote: > > We would therefore like to clarify that we regard our core Open Source > > products as our crown jewels > > This seems to be missing the reason why the new "Platform" is better off > non-OSS? Hi Justin, That is because it is not universally better. I think you personally might find the "Platform" to be worse even! But read on for why. The best explanation may be found in the second to last link in the blogpost or email (if you have HTML email) on http://venturebeat.com/2015/12/06/its-actually-open-source-software-thats-eating-the-world/ About successful open source businesses, it says: "They’ve figured out that customers are more than happy to pay for an enterprise-grade version of the complete product, which may have security, management, or integration enhancements and come with support. And they also understand that keeping this type of functionality proprietary won’t alienate the community supporting the project the way something such as a performance enhancement would." Basically everything in the Platform is something you could build/hook yourself. You and I personally could do that easily, and the companies where we work would probably prefer that. In business this is referred as 'best of breed approach'. http://c2.com/cgi/wiki?BestOfBreed calls it: ".. the strategy of selecting the best product of each type (and integrating them yourself), rather than selecting one large integrated solution from a single vendor.". Not every company is like that though: they may prefer something that comes with loads of integrated features (graphing, failover, monitoring, graphical user interface, configuration audit trail etc) out of the box. Ideally, our "Platform" would consist of features that most of our Open Source friends would prefer to assemble themselves using the large amount of hooks (Pipe, Remotebackend, our backend API, our RestFUL/JSON API, Lua support, Carbon output, dnsdist DNSTAP (near future)) that we offer for that. The problem we are solving here is making ourselves more accessible for those places that do not in fact want to assemble all this themselves - without closing down the very open PowerDNS software. Does this help? Bert > > Is it a case of wanting the Platform to be a competative differentiator? > (GitHub style?) > > + Justin From peter.van.dijk at powerdns.com Wed Feb 24 09:43:13 2016 From: peter.van.dijk at powerdns.com (Peter van Dijk) Date: Wed, 24 Feb 2016 10:43:13 +0100 Subject: [Pdns-dev] implement GSQLBackend::getDirectNSECx In-Reply-To: <56CC4E18.8000106@hosting.de> References: <56C744E8.8020601@hosting.de> <56CAEF12.4090106@hosting.de> <92015242-C482-42F6-925D-5CC0EDED361B@powerdns.com> <56CC4E18.8000106@hosting.de> Message-ID: <1F00F4D5-5B8F-4D36-8C7D-85CF6D9FA57C@powerdns.com> Hello Sebastian, On 23 Feb 2016, at 13:18, labs at hosting.de wrote: > Hello Peter, > >> Can you clarify what you mean by empty traversals? What is your full >> procedure for serving a lens-signed zone file with PowerDNS today? > > following an example of a zone signed by ldns. As you can see, it > contains not only RRSIG, but also 3 NSEC3 and the NSEC3PARAM record. > In order to publish the zone with pdns we have to remove these 4 > records from the zone. Then we have to take the content of the > NSEC3PARAM record and add it to domainmetadata as a 'NSEC3PARAM' > entry, along with a 'PRESIGNED' entry. The zone contains one record at > its apex and one in sub2.sub1.dnssec-secured.com, but none in > sub1.dnssec-secured.com, so next we have to create a record of type > NULL for sub1.dnssec-secured.com, the empty traversal record. After > that we have to determine the ordername for the A, NS, SOA and the > empty traversal records, and have to remember to set the ordername to > NULL in our RRSIG and DNSKEY records (but to an empty string, not > NULL, for records on the apex if we sign with NSEC instead of NSEC3) In theory, at least for non-presigned zones, pdnssec/pdnsutil rectify-zone should do all of this - create the NULL entries, set the ordernames, etc. I’m not sure you need NULL on the RRSIG and DNSKEY records by the way. In second theory, loading your signed files into the bindbackend may be easier than all the database fiddling you are doing. In practice, loading your signed files into a non-database name server like NSD or BIND, and then letting PowerDNS AXFR the zone in, will make the database right down to the last detail. > If instead it would be possible to use the NSEC(3) and NSEC3PARAM > records as ldns creates them we wouldn't have to do all this. We could > just add the records to our database as they are and ignore the > ordername and metadata. This would save us work, would make our system > more robust and would be more secure when updating pdns. Re metadata: yes, NSEC3PARAM and PRESIGNED could be ‘inferred’ from zone data. But nothing would save you from having to fill in ordername - PowerDNS needs those, no matter how many tweaks we do to accommodate your situation. From where I’m sitting, you really would be best off if you can AXFR the zones into PowerDNS. Maybe we can think about making sure ‘pdnsutil load-zone’ does all of this correctly, but it would not be a big priority for us as the AXFR way already works well. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From pieter.lexis at powerdns.com Thu Feb 25 15:50:05 2016 From: pieter.lexis at powerdns.com (Pieter Lexis) Date: Thu, 25 Feb 2016 16:50:05 +0100 Subject: [Pdns-dev] PowerDNS Authoritative Server 4.0.0-alpha2 released Message-ID: <20160225165005.3c7dcfee@aardbei.mobile.plexis.eu> Hi all, We're pleased to announce the second alpha release of the PowerDNS Authoritative Server version 4.0.0. This release is the first release to use OpenSSL for nearly all crypto-primitives (GOST is still provided by Botan) and has a breaking change in the API compared to alpha 1. A list of new features of the upcoming 4.0.0 release is available on our documentation website[1]. Notable changes since 4.0.0-alpha1 (changelog with clickable links is online[2]): #3037 Remove superfluous gsql queries and stop relying on schema defaults #3176, #3139 OpenSSL support (Christian Hofstaedtler and Kees Monshouwer) #3128 ECDSA support to DNSSEC infra via OpenSSL (Kees Monshouwer) #3281, #3283, #3363 Remove Crypto++ and mbedTLS support #3298 Implement pdnsutil create-zone zone nsname, add-record, delete-rrset, replace-rrset #3407 API: Permit wildcard manipulation (Aki Tuomi) #3230 API: drop JSONP, add web security headers (Christian Hofstaedtler) #3428 API: Fix zone/records design mistake (Christian Hofstaedtler) Note: this is a breaking change from alpha1, please review the API documentation Bug fixes #3124 Fix several bugs with introduced with the change to a single signing key #3151 Catch DNSName build errors in dynhandler (Christian Hofstaedtler) #3264 GeoIP backend: Use correct id numbers for domains (Aki Tuomi) #3271 ZoneParser: Throw PDNSException on too many SOA data elements #3302 Fix bindbackend's feedRecord to handle being slave for the root #3399 Report OpenSSL RSA keysize in bits (Kees Monshouwer) Improvements #3119 Show DNSSEC keys for slaved zone (Aki Tuomi) #3255 Don't log authentication errors before sending HTTP basic auth challenge (Jan Broer) #3338 Add weight feature to GeoIP backend (Aki Tuomi) #3364 Shrink PacketID by 10% by eliminating padding. (Andrew Nelless) #3443 Many speedup and correctness fixes Tarballs are available on the download site[3] and packages are available from our repositories[4] (Raspbian packages will be updated tomorrow). 1 - https://doc.powerdns.com/changelog/#powerdns-authoritative-server-400 2 - https://doc.powerdns.com/changelog/#powerdns-authoritative-server-400-alpha2 3 - https://downloads.powerdns.com/releases 4 - https://repo.powerdns.com Best regards, Pieter on behalf of the PowerDNS team -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com From justin at postgresql.org Thu Feb 25 17:30:13 2016 From: justin at postgresql.org (Justin Clift) Date: Thu, 25 Feb 2016 17:30:13 +0000 Subject: [Pdns-dev] PowerDNS Authoritative Server 4.0.0-alpha2 released In-Reply-To: <20160225165005.3c7dcfee@aardbei.mobile.plexis.eu> References: <20160225165005.3c7dcfee@aardbei.mobile.plexis.eu> Message-ID: <76c03de31f769e889ae9ca6d00061039@postgresql.org> On 2016-02-25 15:50, Pieter Lexis wrote: > #3176, #3139 OpenSSL support (Christian Hofstaedtler and Kees > Monshouwer) > #3128 ECDSA support to DNSSEC infra via OpenSSL (Kees Monshouwer) > #3281, #3283, #3363 Remove Crypto++ and mbedTLS support Out of curiosity, why the move towards OpenSSL? :) Only asking because many OSS projects are moving *away* from it, due to OpenSSL's repeated (severe) vulnerabilities and known-lousy code base. Gluster was thinking about shifting away from OpenSSL a while back too, and alternatives such as PolarSSL, LibreSSL (etc) were raised in discussion. PowerDNS was an example I pointed out of PolarSSL usage, so it's not empty curiosity. :) Regards and best wishes, Justin Clift From pieter.lexis at powerdns.com Thu Feb 25 18:05:21 2016 From: pieter.lexis at powerdns.com (Pieter Lexis) Date: Thu, 25 Feb 2016 19:05:21 +0100 Subject: [Pdns-dev] PowerDNS Authoritative Server 4.0.0-alpha2 released In-Reply-To: <76c03de31f769e889ae9ca6d00061039@postgresql.org> References: <20160225165005.3c7dcfee@aardbei.mobile.plexis.eu> <76c03de31f769e889ae9ca6d00061039@postgresql.org> Message-ID: <20160225190521.5a0fb603@aardbei.mobile.plexis.eu> Hi Justin, On Thu, 25 Feb 2016 17:30:13 +0000 Justin Clift wrote: > Out of curiosity, why the move towards OpenSSL? :) > > Only asking because many OSS projects are moving *away* from it, due > to OpenSSL's repeated (severe) vulnerabilities and known-lousy code > base. > > Gluster was thinking about shifting away from OpenSSL a while back too, > and > alternatives such as PolarSSL, LibreSSL (etc) were raised in discussion. > > PowerDNS was an example I pointed out of PolarSSL usage, so it's not > empty > curiosity. :) So first off, we don't use the TLS stacks from any of the crypto libraries, just the hash and cryptographic primitives to sign for DNSSEC, so we're most likely hardly affected by OpenSSL TLS issues. The main reason we switched to OpenSSL is that in our testing, we noticed that signature generation was an order of magnitude faster with OpenSSL compared to mbedTLS and Crypto++ due to the ASM optimizations of OpenSSL. I tested builing against LibreSSL 2.3, which works :), so you can always do that. Best regards, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com From justin at postgresql.org Thu Feb 25 18:08:55 2016 From: justin at postgresql.org (Justin Clift) Date: Thu, 25 Feb 2016 18:08:55 +0000 Subject: [Pdns-dev] PowerDNS Authoritative Server 4.0.0-alpha2 released In-Reply-To: <20160225190521.5a0fb603@aardbei.mobile.plexis.eu> References: <20160225165005.3c7dcfee@aardbei.mobile.plexis.eu> <76c03de31f769e889ae9ca6d00061039@postgresql.org> <20160225190521.5a0fb603@aardbei.mobile.plexis.eu> Message-ID: On 2016-02-25 18:05, Pieter Lexis wrote: > So first off, we don't use the TLS stacks from any of the crypto > libraries, just the hash and cryptographic primitives to sign for > DNSSEC, so we're most likely hardly affected by OpenSSL TLS issues. > > The main reason we switched to OpenSSL is that in our testing, we > noticed that signature generation was an order of magnitude faster > with OpenSSL compared to mbedTLS and Crypto++ due to the ASM > optimizations of OpenSSL. I tested builing against LibreSSL 2.3, which > works :), so you can always do that. Thanks Pieter, that's the missing info. :) + Justin