Florian Obser wrote: > > With the possibility to say "use this database backend for private > > key material only", I could use another databse backend to store > > the signed zones, replicate this database and nonetheless neither > > powerdns doesn't store signatures in the database backend when running > in live signing mode. (If you're running pre-signed you wouldn't store > the keys in the database in the first place.) > > | 4.2. Signatures > | > | In PowerDNS live signing mode, signatures, as served through RRSIG > | records, are calculated on the fly, and heavily cached. > ( http://doc.powerdns.com/powerdnssec.html ) > > Presumably the database replication slaves duplicate the calculation of > RRSIGs and therefore need the (private) keys.
Definately clear, if you don't keep the zones in storage signed, you have to spread the keys to enable signing "on the fly" on every single backend-slave. Could the pdns staff perhaps just magically jump in and explain the reasons for forcing proliferation of secret key material without there really being a need for it? (That is, reasons beside "We just forgot it", "We couldn't think of a way to handle this" and "We are monkeys on crack and your argument is futile" xD) . . . Second thoughts jump in to answer the question: To know when or whether an update of RRSIGs is needed, zone content must be passed through PowerDNS, either in or out. Outgoing, PowerDNS just delivers a snapshot of the required content (be it single RRs or an AXFR) from the backend, making sure the RRSIGs delivered with the content match the content's state to exactly this moment. Incoming, PowerDNS can diff present content with received content, and if some backend data needs to be updated, corresponding RRSIG needs to be recalculated too. But if the modification happens backend-internally (by some site-local administrational interface or alike), PowerDNS has no chance to know it would have to calculate and store an updated RRSIG. So PowerDNS can either be used for outbound AXFR of signed zones from backend-"controlled" data, or to receive (pre-)signed zones via AXFR and put these into the backend to have replication for signed content on backend level. That's one of the tradeoffs of having a "stateless" nameserver and not needing to reload your nameserver if zone contents have been modified on disk, it seems.. Dang. Should have thought about this problem one week earlier, would have been interested to find out what the Bind10-folks are planning on this.. kind regards, Sebastian _______________________________________________ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users