[Pdns-users] PowerDNSSEC Slaves
Hi there. I am testing powerdnssec with one of my domains spam.co.nz I have 2 PowerDNSSEC servers set up one as master and one as slave. I have used the normal powerdns for a long time with no problems Both set up using gmysql backends (one on each) ,adding the data into the master mysql database and they replicate via zone transfers all ok into the slave mysql database; I set up as in the instructions for the domain Spam.co.nz Master.. pdnssec secure-zone spam.co.nz And gmysql-host=127.0.0.1 gmysql-user=root gmysql-password= gmysql-dbname=pdns gmysql-dnssec master=yes Slave pdnssec set-presigned spam.co.nz (set the domain to be presigned as its coming from ns1) gmysql-host=127.0.0.1 gmysql-user=root gmysql-password= gmysql-dbname=pdns gmysql-dnssec' slave=yes I can update 114.23.33.130 and it updates on 114.23.33.131 Testing.. dig +dnssec T A spam.co.nz @114.23.33.130 gives spam.co.nz. 86400 IN A 114.23.33.130 spam.co.nz. 86400 IN RRSIG A 8 3 86400 2011061600 2011060200 45201 spam.co.nz. G8dEGkabnpInz47441Q6nUZkil0fBOjzll1jTRC8qGLx17baG7b30stf aNcRlVvWncvRWvjzMpWocKfUQJuGC5+F7rPLDVK/rRO4L7DATjEZ95eC tw2YfKEZHivKZbOlAEHKncd6A/VV4IOHRpl1ebx6/yQ8Vr36tojI06RW k9k= dig +dnssec T A spam.co.nz @114.23.33.130 spam.co.nz. 86400 IN RRSIG A 8 3 86400 2011061600 2011060200 45201 spam.co.nz. G8dEGkabnpInz47441Q6nUZkil0fBOjzll1jTRC8qGLx17baG7b30stf aNcRlVvWncvRWvjzMpWocKfUQJuGC5+F7rPLDVK/rRO4L7DATjEZ95eC tw2YfKEZHivKZbOlAEHKncd6A/VV4IOHRpl1ebx6/yQ8Vr36tojI06RW k9k= spam.co.nz. 86400 IN A 114.23.33.130 So I extract the keys .. pdnssec export-zone-dnskeys spam.co.nz 1 | grep DNSKEY trustedkey And test on 114.23.33.130 dig +dnssec +sigchase +trusted-key=./trustedkey t A spam.co.nz @114.23.33.130 And.. .. .. ;; WE HAVE MATERIAL, WE NOW DO VALIDATION ;; VERIFYING A RRset for spam.co.nz. with DNSKEY:45201: success ;; OK We found DNSKEY (or more) to validate the RRset ;; Ok, find a Trusted Key in the DNSKEY RRset: 22621 ;; VERIFYING DNSKEY RRset for spam.co.nz. with DNSKEY:22621: success ;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS Works.. But dig +dnssec +sigchase +trusted-key=./trustedkey t A spam.co.nz @114.23.33.131 ;; WE HAVE MATERIAL, WE NOW DO VALIDATION ;; VERIFYING A RRset for spam.co.nz. with DNSKEY:45201: success ;; OK We found DNSKEY (or more) to validate the RRset ;; Now, we are going to validate this DNSKEY by the DS ;; the DNSKEY isn't trusted-key and there isn't DS to validate the DNSKEY: FAILED Can someone help why the slave is failing I cannot find any documentation on slaves and powerdnssec and how it should be done properly.. Thanks Craig ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] PowerDNSSEC Slaves
On Wed, 08 Jun 2011 18:21:14 +1200, Craig Whitmore wrote: [...] Can someone help why the slave is failing=8A I think one of the DNSSEC records is being truncated on the slave as it exceeds 256 bytes - you might need to update the database schema on the slave to allow for longer records. I cannot find any documentation on slaves and powerdnssec and how it should be done properly.. If you happen to have non-PowerDNS slaves, you might also want to set SOA-EDIT to INCREMENT-WEEKS in the domainmetadata table for that domain (this isn't needed if you only have PowerDNS slaves). Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] PowerDNSSEC Progress: ready for a first look
would be an excellent way into dnssec. This wouldn't require any change to the existing (non-dnssec) powerdns setups, and would allow us to test with real things, easily migrate single domains to a dnssec setup (just change the nameservers), rollback when needed to the old and tested setup etc. Am I correct that this would only work via AXFR style transfers from the non-dnssec pdns to the new pdns-dnssec slaves? Frank On 06 Jan 2011 wk 1, at 20:00, bert hubert wrote: On Thu, Jan 06, 2011 at 11:55:24AM -0500, Mathew Hennessy wrote: Excellent! BTW, can PowerDNSSEC operate in the following way as one would expect: PowerDNS supermaster which has DNSSEC RRs but doesn't do DNSSEC (aka traditional PowerDNS) providing data to PowerDNS slaves. If you use the new code with a compatible backend on the slaves (such as gsqlite3), and your whois servers only point to those slaves, will it work? Almost! If you did that up till just now, you would have had to run 'pdnssec rectify-zone' on your slaves after each AXFR. However, thank you for raising this idea, this sounds like a very valid use case. It has just been implemented in changeset http://wiki.powerdns.com/trac/changeset/1819 I tested it against an ancient server, and now I have a fully operational DNSSEC zone! It works fully automatic on retrieving a zone for which we have local keying material. In this way, PowerDNSSEC can now be used to 'dnssec-ify' existing data, a bit like 'phreebird'. http://freshmeat.net/projects/phreebird Bert Thanks, = Matt On Jan 6, 2011, at 10:13, bert hubert wrote: Dear PowerDNS Community, With the help of many of you, we've now brought 'PowerDNSSEC' to the point where it might make sense for you to trial it on test domains. We expect to make move some of our own important domains over to PowerDNSSEC early next week. PowerDNS.COM underlies the commercial DNS hosting service 'Express', and may have to wait a bit longer. To test, head over to http://www.powerdnssec.org (which of course is powered by PowerDNSSEC). More information is on http://wiki.powerdns.com/trac/wiki/PDNSSEC - including how to get started, and how to get help. In brief, PowerDNSSEC will allow you to continue operating as normal in many cases, with only slight changes to your installation. There is no need to run signing tools, nor is there a need to rotate keys or run scripts. Particularly, if you run with Generic MySQL, Generic PostgreSQL or Generic SQLite3, you should have an easy time. A small schema update is required, plus an invocation of 'pdnssec secure-zone domain-name pdnssec rectify-zone domain-name' per domain you want to secure. And that should be it. Supported are: * NSEC * NSEC3 in ordered mode (pre-hashed records) * NSEC3 in narrow mode (unmodified records) * Zone transfers (for NSEC) * Import of 'standard' private keys from BIND/NSD * Export of 'standard' private keys * RSASHA1 * Pure PostgreSQL, SQLite3 MySQL operations * Hybrid BIND/PostgreSQL/SQLite3/MySQL operation To join the fun, download the tarball which can be found on the sites above, and let us know how it works for you! To clarify, we do not recommend taking the current code snapshot into production, but we are getting close. Kind regards, Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users Frank -- Frank Louwers Operations -- Openminds bvbahttp://openminds.be fr...@openminds.be +32.9 225 82 91 Schrijf je nu in op onze nieuwsbrief: http://openminds.be/nieuwsbrief ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] PowerDNSSEC Progress: ready for a first look
On 01/06/2011 08:00 PM, bert hubert wrote: On Thu, Jan 06, 2011 at 11:55:24AM -0500, Mathew Hennessy wrote: Excellent! BTW, can PowerDNSSEC operate in the following way as one would expect: PowerDNS supermaster which has DNSSEC RRs but doesn't do DNSSEC (aka traditional PowerDNS) providing data to PowerDNS slaves. If you use the new code with a compatible backend on the slaves (such as gsqlite3), and your whois servers only point to those slaves, will it work? Almost! If you did that up till just now, you would have had to run 'pdnssec rectify-zone' on your slaves after each AXFR. However, thank you for raising this idea, this sounds like a very valid use case. It has just been implemented in changeset http://wiki.powerdns.com/trac/changeset/1819 I tested it against an ancient server, and now I have a fully operational DNSSEC zone! It works fully automatic on retrieving a zone for which we have local keying material. In this way, PowerDNSSEC can now be used to 'dnssec-ify' existing data, a bit like 'phreebird'. http://freshmeat.net/projects/phreebird Bert Hi Bert, Thank you for all your work so far, it is probably a lot of work. I was thinking what about the opposite ? A (possibly hidden) supermaster which does all the DNSSEC signing and the superslaves which only do zone-trasfers and no online DNSSEC-signing but do understand enough of the protocol to be able to serve it. I guess during the zone-transfer it would update any parts of the zone that are not yet (correctly) DNSSEC-signed ? Would that also work ? Technically/DNSSEC-wise I would expect it to work but maybe you don't have the right configuration options yet. Also judging from the current documentation it currently is not a mode of operations. I ask this because I have a feeling not everyone wants their private key material in several physical locations or do not yet want to be hindered by the the DNSSEC-performance of the current release for their public authoritive servers. Most of these requirements are already handled by the SQL-replication mode of operation. I have a hunch not atleast someone out there currently runs a supermaster/superslave operation and would like to only add DNSSEC to the supermaster and only upgrade (if needed) the slaves. __ I really like how PowerDNSSEC and Phreebird are trying to lower the administrative/operational burden. But their is one part I'm missing a way to hook up an EPP-client for sending the DS-record to the parent-zone. Because when you setup the DS-record(s) at the parent-zone, you'll eventually need to update it and the point it is time when it needs to be updated is kind of dictated by the software/crypto-algoritm. So far the only effort I've seen is a some experimental/beta code created by the OpenDNSSEC-people. Any thoughts on that yet ? Or is it just to early at this point ? Are their to many TLD's that do not have the needed EPP-extensions at this time ? Or are their to many different authentication scheme's ? Probably worse, I guess for some people they have registrars in between. And some currently have EPP, but probably not many have DNSSEC yet. Anyway, when is the new DS known to PowerDNSSEC (and in the database) so communication with all parties that are involved can be initiated and how can it be recognised. Would it be enough to run some script every day for example ? I hope this is going to be a good year for everyone, Leen Besselink. Thanks, = Matt On Jan 6, 2011, at 10:13, bert hubert wrote: Dear PowerDNS Community, With the help of many of you, we've now brought 'PowerDNSSEC' to the point where it might make sense for you to trial it on test domains. We expect to make move some of our own important domains over to PowerDNSSEC early next week. PowerDNS.COM underlies the commercial DNS hosting service 'Express', and may have to wait a bit longer. To test, head over to http://www.powerdnssec.org (which of course is powered by PowerDNSSEC). More information is on http://wiki.powerdns.com/trac/wiki/PDNSSEC - including how to get started, and how to get help. In brief, PowerDNSSEC will allow you to continue operating as normal in many cases, with only slight changes to your installation. There is no need to run signing tools, nor is there a need to rotate keys or run scripts. Particularly, if you run with Generic MySQL, Generic PostgreSQL or Generic SQLite3, you should have an easy time. A small schema update is required, plus an invocation of 'pdnssec secure-zone domain-name pdnssec rectify-zone domain-name' per domain you want to secure. And that should be it. Supported are: * NSEC * NSEC3 in ordered mode (pre-hashed records) * NSEC3 in narrow mode (unmodified records) * Zone transfers (for NSEC) * Import of 'standard' private keys from BIND/NSD * Export of 'standard' private keys * RSASHA1 * Pure PostgreSQL, SQLite3 MySQL operations * Hybrid
[Pdns-users] PowerDNSSEC Progress: ready for a first look
Dear PowerDNS Community, With the help of many of you, we've now brought 'PowerDNSSEC' to the point where it might make sense for you to trial it on test domains. We expect to make move some of our own important domains over to PowerDNSSEC early next week. PowerDNS.COM underlies the commercial DNS hosting service 'Express', and may have to wait a bit longer. To test, head over to http://www.powerdnssec.org (which of course is powered by PowerDNSSEC). More information is on http://wiki.powerdns.com/trac/wiki/PDNSSEC - including how to get started, and how to get help. In brief, PowerDNSSEC will allow you to continue operating as normal in many cases, with only slight changes to your installation. There is no need to run signing tools, nor is there a need to rotate keys or run scripts. Particularly, if you run with Generic MySQL, Generic PostgreSQL or Generic SQLite3, you should have an easy time. A small schema update is required, plus an invocation of 'pdnssec secure-zone domain-name pdnssec rectify-zone domain-name' per domain you want to secure. And that should be it. Supported are: * NSEC * NSEC3 in ordered mode (pre-hashed records) * NSEC3 in narrow mode (unmodified records) * Zone transfers (for NSEC) * Import of 'standard' private keys from BIND/NSD * Export of 'standard' private keys * RSASHA1 * Pure PostgreSQL, SQLite3 MySQL operations * Hybrid BIND/PostgreSQL/SQLite3/MySQL operation To join the fun, download the tarball which can be found on the sites above, and let us know how it works for you! To clarify, we do not recommend taking the current code snapshot into production, but we are getting close. Kind regards, Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] PowerDNSSEC
Hi, I'm currently evaluating the PowerDNSSEC implementation and found 2 issues: -) Is it possible to disable the signing-on-demand feature? I want the powerdns to act as slave to a hidden-master which does the signing of the domain, and the powerdns should just serve the signed zone (without any resigning and without access to the Keys). -) I tried the PostgreSQL-Backend, but I allways received the following error message: TCP server is unable to launch backends - will try again when questions come in: Undefined but needed argument: 'gpgsql-dnssec'. What is the format of the missing gpgsql-dnssec'-Parameter I've to add? Best, Michael ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] PowerDNSSEC
On 06/24/2010 03:08 PM, Michael Braunoeder wrote: Hi, Hi, I'm currently evaluating the PowerDNSSEC implementation and found 2 issues: As no person which is more knowledgable answered your question, I thought I would answer with what I know. -) Is it possible to disable the signing-on-demand feature? I want the powerdns to act as slave to a hidden-master which does the signing of the domain, and the powerdns should just serve the signed zone (without any resigning and without access to the Keys). The disable the 'signing-on-demand'-feature has been discussed on this mailinglist before, the answer was: it will be optional in a future version. -) I tried the PostgreSQL-Backend, but I allways received the following error message: TCP server is unable to launch backends - will try again when questions come in: Undefined but needed argument: 'gpgsql-dnssec'. What is the format of the missing gpgsql-dnssec'-Parameter I've to add? I like your choose of database, but I don't have any information on the current state of this or any other bankend in combination with DNSSEC, other than I've used the 'bind-backend' (text-file). I do know that every database backend needs to implement some basic extra functions before it can work with DNSSEC. That information can be found here: http://wiki.powerdns.com/trac/wiki/PDNSSEC/backends As linked from: http://wiki.powerdns.com/trac/wiki/PDNSSEC But I did see on that page it says: Things to be aware of Only BIND and Generic MySQL (gmysql) backend right now It's also the same page that mentions: Next The completely live auto-signing nature of PowerDNSSEC is not what everyone wants. Other DNSSEC modes will be added soon. Best, Michael ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] PowerDNSSEC, PowerDNS @ ICANN38
Hi everybody, I'll be part of the 'DNSSEC Workgroup' over at ICANN in Brussels this coming week. There, I will present 'PowerDNSSEC' plus our vision of DNSSEC on the resolver side of large ISPs. More details can be found on http://brussels38.icann.org/node/12491 and you can even join in virtually, http://brussels38.icann.org/chat/silverhall Exact agenda is on http://brussels38.icann.org/meetings/brussels2010/agenda-dnssec-workshop-23jun10-en.pdf I'll be around on Tuesday evening and Wednesday. As always, I enjoy meeting PowerDNS users enthousiasts, so I hope to meet you there! Drop me a note if you want to coordinate. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
