[Pdns-users] Question concerning multiple database backends
s.posner at telekom.de
Thu Oct 27 20:45:45 UTC 2011
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
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
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..
More information about the Pdns-users