Re: [Pdns-users] New PowerDNS Authoritative Server snapshot with DNSSEC + Release Notes
On Sat, 29 Jan 2011 00:38:12 +0100, Christof Meerwald wrote: That's really excellent news - I have just migrated my 2 nameservers to SVN revision 1928 and signed one of the zones (btw, the setup is: master using bind backend for the zone data and gsqlite3 for the key data - slave is using gsqlite3 and AXFR from master). Let's see what happens... Hmm, I still don't understand DNSSEC well enough to really make some sense of it all, but there are certainly some strange things here: The zone I am testing with is cmeerw.priv.at, master dns is ns.cmeerw.net and slave is ns2.cmeerw.net (and trying to use nsec3). Requesting the SOA record appears to work fine on both servers: dig +dnssec -t SOA cmeerw.priv.at @ns.cmeerw.net dig +dnssec -t SOA cmeerw.priv.at @ns2.cmeerw.net But if I try to query for NS, I get some RRSIG records in the additional section, but only from ns.cmeerw.net: ;; ADDITIONAL SECTION: ns2.cmeerw.net. 28800 IN A 80.190.133.60 ns2.cmeerw.net. 28800 IN RRSIG A 8 3 28800 2011021000 2011012700 35080 cmeerw.priv.at. mKFWS0sPy8sFs4kWGgs0dvniiDAGzpgxPw/LgsCZ88r/k9Lc/+6pHK8k nkh9QzshTFkHKfIsM5NBr8ABRMPSligLc+t6Qb2B3P+Sfz3kVoW1baoS VTJAjkbMzTa5uD/HD6C0qX3KdMy4wxOq8YZAHislWkuNydCcM+/vGmBt fvo= ns.cmeerw.net. 28800 IN A 84.200.12.152 ns.cmeerw.net. 28800 IN RRSIG A 8 3 28800 2011021000 2011012700 35080 cmeerw.priv.at. kfoB3v8GYzdKJ6afJR81msJ2AKGNQ/7HIsS50ISphbWqUK5UrLDe5kno s1L8JoshcXxUyxcMl2s4SaJX3h+ImFsact8Xunl8fl+AwSJJrbHd4Dsb M1OhxfpTaEHzvBgX/nR0Xam52xBm5ruqOL26mRZjjhbUqlSI21IbP9O6 UEY= not from ns2.cmeerw.net: ;; ADDITIONAL SECTION: ns.cmeerw.net. 28800 IN A 84.200.12.152 ns2.cmeerw.net. 28800 IN A 80.190.133.60 Note that both servers are authoritative for cmeerw.net, but the zone is not signed. And finally, if I try to query a non-existing record, the response seems reasonable from ns.cmeerw.net: ;; AUTHORITY SECTION: cmeerw.priv.at. 28800 IN SOA ns.cmeerw.net. domain.cmeerw.net. 2010080601 3600 900 1814400 3600 cmeerw.priv.at. 28800 IN NSEC3 1 0 1 AB SO== RRSIG cmeerw.priv.at. 28800 IN RRSIG SOA 8 3 28800 2011021000 2011012700 35080 cmeerw.priv.at. NQToBHA8ywWqjAtYM3ApLJw9fIbKe/mdUysBQ010d9FGCS0n8TQ2eEtO RjfAl4ZjNpv7oB+AukM3a2jwCIVQh8Tsb5PNOoNKL3UxaLtB/j/S7Dbg wAW6fAAhcharh665lHw07vECWbDvNDU5t4TmmHPrJ/dlph3xBOCrWw5n bpI= cmeerw.priv.at. 28800 IN RRSIG NSEC3 8 3 28800 2011021000 2011012700 35080 cmeerw.priv.at. kKbZ50zzk0drm29L7xbtjOo3hG4Xhj3NbwM290Lzckq2ipmb9/iDFnyO fKxWgJrsHYyigESCRAMUnYAqJvyfWw49Ke1dOu1uVMe6gtS9YDTws12z oIXj2H+Mo5UxvF02WYHwuSQsDeP8So4IctT466Xkv60LhS5G6y8lwvOf FK4= but very strange from ns2.cmeerw.net: ;; AUTHORITY SECTION: cmeerw.priv.at. 28800 IN SOA ns.cmeerw.net. domain.cmeerw.net. 2010080601 3600 900 1814400 3600 8b40po8goooqdt13tad1l7j5oht0puo3.cmeerw.priv.at. 7200 IN NSEC3 1 0 1 AB RRSIG=== NSEC3 cmeerw.priv.at. 28800 IN RRSIG SOA 8 3 28800 2011021000 2011012700 35080 cmeerw.priv.at. NQToBHA8ywWqjAtYM3ApLJw9fIbKe/mdUysBQ010d9FGCS0n8TQ2eEtO RjfAl4ZjNpv7oB+AukM3a2jwCIVQh8Tsb5PNOoNKL3UxaLtB/j/S7Dbg wAW6fAAhcharh665lHw07vECWbDvNDU5t4TmmHPrJ/dlph3xBOCrWw5n bpI= ca95b8nmpkjglrraoo4cu4m9sp7m2ma9.cmeerw.priv.at. 28800 IN NSEC3 1 0 1 AB 8B40PO8GOOOQDT13TAD1L7J5OHT0PUO3 RRSIG NSEC3 8b40po8goooqdt13tad1l7j5oht0puo3.cmeerw.priv.at. 7200 IN RRSIG NSEC3 8 4 7200 2011021000 2011012700 35080 cmeerw.priv.at. pFoJS2R2QOKLvCu8Lj3i3RWVSLf86pygLHB8WgsFVCMkcu3IaVbc1ZsL 5+cPm2yYgGAwMUw1ZdNutm8lZwempxhyXn3q4uJ8CBaKx6EYCpCiIuxZ ATIYSYR3apEfLDkNIHLZzlLFSEsHvNsxTOM4ZGgFu2ZLCh0p7HSYNE+n l4Y= ca95b8nmpkjglrraoo4cu4m9sp7m2ma9.cmeerw.priv.at. 28800 IN RRSIG NSEC3 8 4 28800 2011021000 2011012700 35080 cmeerw.priv.at. H76INArO3yFe9iIKs8NCdVy6+L7pj4vcn+ESjuEAuTH1pShXt7ZxuLQL t/TiF89/NbtbbAG6RB3KARA2c/FtGag5tR6/sxVGpyF4Kx0K25BwCtmO LHErS7g3860YvXBzUwhwCvOeG9oQJ4Fyi5NsrzR5O2Jc68Axqzo9Gfsq /O4= Any ideas on these observations? (feel free to query these nameservers yourself) 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] New PowerDNS Authoritative Server snapshot with DNSSEC + Release Notes
On Sat, Jan 29, 2011 at 10:30:47AM +0100, Christof Meerwald wrote: On Sat, 29 Jan 2011 00:38:12 +0100, Christof Meerwald wrote: That's really excellent news - I have just migrated my 2 nameservers to SVN revision 1928 and signed one of the zones (btw, the setup is: master using bind backend for the zone data and gsqlite3 for the key data - slave is using gsqlite3 and AXFR from master). Let's see what happens... Hmm, I still don't understand DNSSEC well enough to really make some sense of it all, but there are certainly some strange things here: Indeed. The zone I am testing with is cmeerw.priv.at, master dns is ns.cmeerw.net and slave is ns2.cmeerw.net (and trying to use nsec3). Ok, so the setup is that both ns and ns2 have all the keying materials, and ns serves a pre-signed zone over AXFR. ns2 receives this AXFR, should rectify it and serve it using its knowledge of the private keying material. Note: what HAS been tested is where the slave has no keying material, and serves the zone in 'pre-signed' mode. This is not what you are doing, but it should still work! Requesting the SOA record appears to work fine on both servers: dig +dnssec -t SOA cmeerw.priv.at @ns.cmeerw.net dig +dnssec -t SOA cmeerw.priv.at @ns2.cmeerw.net Looks good. But if I try to query for NS, I get some RRSIG records in the additional section, but only from ns.cmeerw.net: ;; ADDITIONAL SECTION: ns2.cmeerw.net. 28800 IN A 80.190.133.60 ns2.cmeerw.net. 28800 IN RRSIG A 8 3 28800 2011021000 2011012700 35080 cmeerw.priv.at. mKFWS0sPy8sFs4kWGgs0dvniiDAGzpgxPw/LgsCZ88r/k9Lc/+6pHK8k nkh9QzshTFkHKfIsM5NBr8ABRMPSligLc+t6Qb2B3P+Sfz3kVoW1baoS VTJAjkbMzTa5uD/HD6C0qX3KdMy4wxOq8YZAHislWkuNydCcM+/vGmBt fvo= ns.cmeerw.net.28800 IN A 84.200.12.152 ns.cmeerw.net.28800 IN RRSIG A 8 3 28800 2011021000 2011012700 35080 cmeerw.priv.at. kfoB3v8GYzdKJ6afJR81msJ2AKGNQ/7HIsS50ISphbWqUK5UrLDe5kno s1L8JoshcXxUyxcMl2s4SaJX3h+ImFsact8Xunl8fl+AwSJJrbHd4Dsb M1OhxfpTaEHzvBgX/nR0Xam52xBm5ruqOL26mRZjjhbUqlSI21IbP9O6 UEY= This is a bug, which will be fixed in the next commit. PowerDNS does not realize it should not be signing stuff added to a record from an insecure zone. not from ns2.cmeerw.net: ;; ADDITIONAL SECTION: ns.cmeerw.net.28800 IN A 84.200.12.152 ns2.cmeerw.net. 28800 IN A 80.190.133.60 Note that both servers are authoritative for cmeerw.net, but the zone is not signed. I bet ns.cmeerw.net has not been rectified on ns2.cmeerw.net. Even unsigned zones should be rectified! This should be automated in some way perhaps. And finally, if I try to query a non-existing record, the response seems reasonable from ns.cmeerw.net: ;; AUTHORITY SECTION: cmeerw.priv.at. 28800 IN SOA ns.cmeerw.net. domain.cmeerw.net. 2010080601 3600 900 1814400 3600 cmeerw.priv.at. 28800 IN NSEC3 1 0 1 AB SO== RRSIG No, this means that you have an NSEC3 configuration, but the 'order' field from the database has not been filled out. This is very weird since you tell me that ns.cmeerw.net runs with the BIND backend, which should do all that automatically. This smells like a separate bug. Can you confirm that ns.cmeerw.net has the cmeerw.priv.at zone in BIND, and can you show the output of 'pdnssec show-zone cmeerw.priv.at'? but very strange from ns2.cmeerw.net: ;; AUTHORITY SECTION: cmeerw.priv.at. 28800 IN SOA ns.cmeerw.net. domain.cmeerw.net. 2010080601 3600 900 1814400 3600 8b40po8goooqdt13tad1l7j5oht0puo3.cmeerw.priv.at. 7200 IN NSEC3 1 0 1 AB RRSIG=== NSEC3 This looks about as strange. This might be a follow-up bug fom what you see on ns.cmeerw.at, let's focus on that first. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] New PowerDNS Authoritative Server snapshot with DNSSEC + Release Notes
On Sat, 29 Jan 2011 15:42:56 +0100, Christof Meerwald wrote: [...] ns.cmeerw.net reads the zone data for cmeerw.priv.at from the bind backend and has the keying information in the db: Just noticed - does the order of the backends specified in launch= make a difference? Just noticed that I had it set to bind,gsqlite3 and now changed it to gsqlite3,bind. dig +dnssec -t a notthere.cmeerw.priv.at @ns.cmeerw.net and dig +dnssec -t a notthere.cmeerw.priv.at @ns2.cmeerw.net now seem to return the same results: ;; AUTHORITY SECTION: cmeerw.priv.at. 28800 IN SOA ns.cmeerw.net. domain.cmeerw.net. 2010080601 3600 900 1814400 3600 8b40po8goooqdt13tad1l7j5oht0puo3.cmeerw.priv.at. 7200 IN NSEC3 1 0 1 AB CA95B8NMPKJGLRRAOO4CU4M9SP7M2MA9 NS SOA MX RRSIG DNSKEY NSEC3PARAM cmeerw.priv.at. 28800 IN RRSIG SOA 8 3 28800 2011021000 2011012700 9895 cmeerw.priv.at. b6IVcHFLnJvuL1T+OVXDDiuPOPbooVgpNHw8SI21cXoo2Q2v89+UQd7+ H/SVjFYPL5RLjyCIcGWIJOrx5Wssg8vqbVqvkaG/AGmyZqhu5S5dVo1b ipK32UrcYrsknkYmzYaHD3ew2ka9hwZYND5MK+g3FNAJxnj3fJEiHEvG Lzo= ca95b8nmpkjglrraoo4cu4m9sp7m2ma9.cmeerw.priv.at. 28800 IN NSEC3 1 0 1 AB 8B40PO8GOOOQDT13TAD1L7J5OHT0PUO3 SRV RRSIG 8b40po8goooqdt13tad1l7j5oht0puo3.cmeerw.priv.at. 7200 IN RRSIG NSEC3 8 4 7200 2011021000 2011012700 9895 cmeerw.priv.at. Z8DhNswJETLP2mTC4HZoAtA9etKlPN/1Xrbi0/u6VGbawX03tqfRbE5J 1qGNKMUfedUf9c7ZVAm8rjVjVhe3n4Tyh72gBFXGt2NNxJhTeXLhGMz1 tEeQVd1PXsSKiV2fT/u25UV6S5LF6OxGZKKcEors5zw2T7ZsH77i8t7o zGM= ca95b8nmpkjglrraoo4cu4m9sp7m2ma9.cmeerw.priv.at. 28800 IN RRSIG NSEC3 8 4 28800 2011021000 2011012700 9895 cmeerw.priv.at. Z6OMBKYDpRoiuz2lFpLAwBcVh8Fakwgs8r80zdgYM6hLnl+ChhClzDVB UjM2igouJwMOMOelqjD4OyDTX4Do536L8z/aMeFygDY8/o1Jbn4Uhgu9 DWqt3OftMXcFNkYqzXeQ5uvcirzz3WVOHYyAlQ1VcEGB4nfDkaZO1+io 2pg= 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] New PowerDNS Authoritative Server snapshot with DNSSEC + Release Notes
On Sat, 29 Jan 2011 16:01:47 +0100, Christof Meerwald wrote: On Sat, 29 Jan 2011 15:42:56 +0100, Christof Meerwald wrote: [...] ns.cmeerw.net reads the zone data for cmeerw.priv.at from the bind backend and has the keying information in the db: Just noticed - does the order of the backends specified in launch= make a difference? Just noticed that I had it set to bind,gsqlite3 and now changed it to gsqlite3,bind. So I guess with that change it's mostly working now, except that ns2.cmeerw.net doesn't return a RRSIG record when requesting the DNSKEY: dig +dnssec -t dnskey cmeerw.priv.at @ns2.cmeerw.net ;; ANSWER SECTION: cmeerw.priv.at. 3600IN DNSKEY 256 3 8 AwEAAbtQ1LDh1ZA0dfBC6SjR6lPr2rpSxZTBV3EQF7N70usXzSm1raLn NAtE38wDK2U9g1PzO5yrj3vm3/T1RJl/qnDd6F8TPFsSYyI5Noh1lnZ8 0rbAJWywmb5mpTA+MD2Tp/xcbeVdyT/ar0gLljJHXUlHt/ih0pbTXrHi QW30sdh5 cmeerw.priv.at. 3600IN DNSKEY 257 3 8 AwEAAait7iglyLwXL1SzhoKZOXgVLsseaq2jFyW/vnda80UWMeZm60QD guYb39Yp5vFD1zI+Fc7Zg+NikFPsYudbW750LOHFtuShO8s3/6p7uyO6 OpXsmG4bQSOOFoNuYr1b8rSYnEMFVZF/iKH/CSk7AazA7P9VBAgSmXcV Q/3rO4teelfiZYERf9NqUFadn5eGgEmpZFovBNtO2DzuiDBb3GCDp7XD zam6LUeVHQgus0JRN7sKnFK0wuAFhZ5rvd/CuJkVOY/3ev5v+gOtTGel kypum88MzMhLaDPREZqLghzObAv0cAzG57dZDsHnn5BhkPHNIzdJMGMM NqhyDGn0nq8= cmeerw.priv.at. 3600IN DNSKEY 256 3 8 AwEAAYW/g3QmZaLIscI58InAyrx88SpiV1XR/e2j2hcjhSUdeLpHLp+r RjDr82XZt/T2VgSOHhztXaqzknTl35xlkYJjGDVz/kodJndeGXQPii9D WWulJd5vNno5xBlo823vN860PBUK0aH00H3wwms9jLEqB3Ha0CFdQogY z9UJC71H but it's fine on ns.cmeerw.net: dig +dnssec -t dnskey cmeerw.priv.at @ns.cmeerw.net ;; ANSWER SECTION: cmeerw.priv.at. 3600IN DNSKEY 257 3 8 AwEAAait7iglyLwXL1SzhoKZOXgVLsseaq2jFyW/vnda80UWMeZm60QD guYb39Yp5vFD1zI+Fc7Zg+NikFPsYudbW750LOHFtuShO8s3/6p7uyO6 OpXsmG4bQSOOFoNuYr1b8rSYnEMFVZF/iKH/CSk7AazA7P9VBAgSmXcV Q/3rO4teelfiZYERf9NqUFadn5eGgEmpZFovBNtO2DzuiDBb3GCDp7XD zam6LUeVHQgus0JRN7sKnFK0wuAFhZ5rvd/CuJkVOY/3ev5v+gOtTGel kypum88MzMhLaDPREZqLghzObAv0cAzG57dZDsHnn5BhkPHNIzdJMGMM NqhyDGn0nq8= cmeerw.priv.at. 3600IN DNSKEY 256 3 8 AwEAAYW/g3QmZaLIscI58InAyrx88SpiV1XR/e2j2hcjhSUdeLpHLp+r RjDr82XZt/T2VgSOHhztXaqzknTl35xlkYJjGDVz/kodJndeGXQPii9D WWulJd5vNno5xBlo823vN860PBUK0aH00H3wwms9jLEqB3Ha0CFdQogY z9UJC71H cmeerw.priv.at. 3600IN RRSIG DNSKEY 8 3 3600 2011021000 2011012700 43519 cmeerw.priv.at. pr/Ru+FVPKVMMpkS0PuXuXxP1dgMCJacflsaTpFDKJAHixybIRX1LmAu SwdWEhtaQpTKHb4xGmtZhK7co1lk534uE8xJKAJybXTBn/ejpx8M/raY dpsp7jhJaH8Vy9Zi/qzWYdpGJlWEhsLOY0paTZHkG8uLEr6JJCbKrSCT 8kZYO3aHvWqRPyxmCBrfPkm0UNVzIDq/cNhwebFBNVVnsoo8wdBPscHj xv0A57iS55eurFtxXDMc89cdtAAedNvEtMXX6d98d3ThozBS2iNcMJDR X1m7zYs7bk+yDKy3Fwh6D2QJ+A00HjBYF13yWeIIheeZ0JzsiZCB9dvd dH5LJg== cmeerw.priv.at. 3600IN DNSKEY 256 3 8 AwEAAbtQ1LDh1ZA0dfBC6SjR6lPr2rpSxZTBV3EQF7N70usXzSm1raLn NAtE38wDK2U9g1PzO5yrj3vm3/T1RJl/qnDd6F8TPFsSYyI5Noh1lnZ8 0rbAJWywmb5mpTA+MD2Tp/xcbeVdyT/ar0gLljJHXUlHt/ih0pbTXrHi QW30sdh5 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] New PowerDNS Authoritative Server snapshot with DNSSEC + Release Notes
On Sat, 29 Jan 2011 16:45:29 +0100, Christof Meerwald wrote: So I guess with that change it's mostly working now, except that ns2.cmeerw.net doesn't return a RRSIG record when requesting the DNSKEY: Hmm, seems to be working now... Not sure what could have changed... 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] New PowerDNS Authoritative Server snapshot with DNSSEC + Release Notes
On 01/27/2011 11:37 PM, bert hubert wrote:
Hi everybody,
(the short version, there is a snapshot worth looking at, packages on
http://powerdnssec.org/downloads - documentation on http://powerdnssec.org )
Since our previous 'PowerDNSSEC' announcement, a lot has happened.
PowerDNSSEC now offers support for almost all DNSSEC algorithms standardised
(RSASHA1, RSASHA256, RSASHA512, GOST), and even for some that aren't yet
(ECDSA).
In addition, we've added support for pre-signed zones, so you can now slave
signed zones from non-PowerDNS installations, and serve them. The other way
around works too, you can slave unsigned zones and serve them with DNSSEC
added to it, as a front-proxy.
Finally, there is now a lot of documentation, a good place to start reading
is still http://powerdnssec.org.
Today, we've released snapshot 20110127.1921 which is in reasonably wide
production. It powers every single access to the PowerDNS Wiki and the
PowerDNS Subversion repository.
Packages for 32 bit and 64 bit Linux distributions, plus source, can be
found on http://powerdnssec.org/downloads
We urge everybody with an interest in DNSSEC to give this snapshot and its
associated documentation a go, if only to find out if it would 'work for
you'.
Hi Bert and others,
So I wanted to atleast do a quick test last night. So I downloaded the
static 64-bit .deb and installed it on my 64-bit Ubuntu 10.10 desktop.
But it did not work. Eventually I found some of the problems, but a
CNAME problem remained. I have some suggestions as well.
I didn't want to setup a mysql or postgresql database, but first try to
setup the bind backend.
I've not created a bind zone file in ages, so I did a quick dig AXFR of
an existing zone in production and removed and replaced a lot of stuff,
this was the result:
test.net. 14400 IN SOA ns1.test.net.
hostmaster.test.net. 2011012731 10800 3600 604800 38400
test.net. 14400 IN NS ns2.test.net.
test.net. 14400 IN NS ns1.test.net.
test.net. 14400 IN NS ns3.test.net.
ns1.test.net. 3600IN A 10.0.0.101
ns2.test.net. 3600IN A 10.0.0.102
ns3.test.net. 3600IN A 10.0.1.13
web.test.net. 3600IN A 10.0.0.238
www.test.net. 3600IN CNAME web.test.net.
test.net. 14400 IN MX 100 mx1.test.net.
test.net. 14400 IN MX 100 mx2.test.net.
test.net. 14400 IN MX 400 mx3.test.net.
test.net. 14400 IN MX 400 mx4.test.net.
mx1.test.net. 3600IN A 10.0.0.111
mx2.test.net. 3600IN A 10.0.0.112
mx3.test.net. 3600IN A 10.0.0.116
mx4.test.net. 3600IN A 10.0.0.117
I created a named.conf:
zone test.net {
type master;
file /etc/powerdns/zones/test.net;
};
and added these settings to pdns.conf:
local-address=127.0.0.1
launch=bind
bind-config=/etc/powerdns/named.conf
Everything seemed to work fine. I tested this by sending:
dig +norec @127.0.0.1 www.test.net. A
I got the CNAME and the A-record of web.test.net as result as expect.
So just running the bind-backend seemed to work just fine.
If I don't want to setup a whole database server, for DNSSEC I would
need sqlite or sqlite3.
First problem: what do I need to specify at the launch parameter ?:
sqlite or sqlite3 ?
I checked pdns_server --list-modules
gsqlite or gsqlite3
I guess if I use the 'sqlite3' command to create the database I'll use
gsqlite3.
So I added that to the launch setting:
launch=gsqlite3,bind
created a database:
http://doc.powerdns.com/gsqlite.html#id621028 (gsqlite / Setting up the
database)
And added the dnssec changes:
http://wiki.powerdns.com/trac/export/1922/trunk/pdns/pdns/dnssec.schema.sqlite3.sql
Added to the config:
gsqlite3-database=/etc/powerdns/sql/powerdns.sqlite3
gsqlite3-dnssec
Everything still worked.
As I understand it, it is possible to use bind-zones and sqlite3 to
store the keys.
So I ran the commands:
$pdnssec secure-zone test.net
This should not happen, still no key!
So I ran check-zone:
$pdnssec check-zone test.net
no nsec3 for test.net
Jan 28 10:39:17 [bindbackend] Done parsing domains, 0 rejected, 1 new, 0
removed
Checked 17 records, 0 errors
Still the same error when I ran pdnssec secure-zone test.net
So I try:
$ pdnssec rectify-zone test.net
no nsec3 for test.net
Jan 28 10:41:46 [bindbackend] Done parsing domains, 0 rejected, 1 new, 0
removed
Adding NSEC ordering information
Done listing
so I run:
$ echo .dump | sqlite3 /etc/powerdns/sql/powerdns.sqlite3 21 | less -I
Nothing was added to the database.
So I run pdnssec secure-zone test.net
Still the same: This should not happen, still no key!
Now I think, well, maybe I should just move everything over to the
Re: [Pdns-users] New PowerDNS Authoritative Server snapshot with DNSSEC + Release Notes
On Fri, Jan 28, 2011 at 12:27:13AM +0100, Detlef Peeters wrote: On 27.01.2011 23:37, bert hubert wrote: (the short version, there is a snapshot worth looking at, packages on http://powerdnssec.org/downloads - documentation on http://powerdnssec.org ) I have upgraded to the snapshot on a CentOS5 i386 machine from 2.9.22 and have a problem to resolve external domains via PowerDNS-Recursor. I'm using the same configuration with PDNS 2.9.22 without problems. I can confirm this issue, apologies. The new DNSSEC code does not do Recursor handoff yet. This area has typically been problematic in case of mixed answers (question for a zone in PowerDNS, but it contains a CNAME to a zone not in PowerDNS, for example). DNSSEC is unlikely to ease this situation, but let's see what can be done. Have I to change something in the configuration? You can always wonder if it is advantageous to run in mixed recursor/auth mode. Bert ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
