[Opendnssec-user] Hot standby redundancy with OpenDNSSEC 1.4 and DNS Input Adapter
Rick van Rein (OpenFortress)
rick at openfortress.nl
Fri Apr 12 11:23:59 UTC 2013
> It is ok to let the standby signer generate new
> signatures (and NSEC3 chain) for everything when promoted as active.
> And KASP database seems to contain everything the standby server must
> have (including NSEC3 salt).
People don't realise it, but DNSSEC does not interfere with a
master-master mode of running DNS. In fact, NSD could host that,
but if you mention that to Wouter his eye starts twitching ;-)
It is the general path of maturing for replicated databases, but DNS
does not seem to need it, so master-slave is fine. But it is still good
to realise this when designing systems around OpenDNSSEC.
>> The only place where this scheme could get into trouble is with SOA
>> serial numbers, which would normally be resolved with the next day's
> This wouldn't be a problem if we could make OpenDNSSEC use `unixtime' as
> SOA serial number. But we can't because our zone management system only
> supports `datecounter' (YYYYMMDDNN) format which makes OpenDNSSEC
> fallback to `counter' mode:
What Jakob says. And if that wouldn't work then I think you'd have better
reworked your zone management system than trying to change OpenDNSSEC,
at least from an architectural/idealistic point of view.
>> Not sure how dynamic you need to be around a calamity.
> We can of course accept that changes to unsigned zones do not propagate
> to DNS due to signing system failure for, say, until next business day,
> as those failures are rare.
Of course you should make sure that all signatures are valid for at least that
day under normal circumstances. And perhaps a long weekend as well :)
And what should be clear is that you can always do manual stuff to your
zones to up the SOA serial. I don't think OpenDNSSEC ever considered
a facitlity to bump to a higher SOA than on the authoritative NS, which
would be helpful to get immediate updates hurtling out to them.
>> Note that this last SOA value could be found in public space, namely
>> your authoritative name servers, so there is no real need for
>> replicating it `hot'.
> Yes, but is there a way to tell OpenDNSSEC what the last public SOA
> serial value is? I mean other than <Serial>keep</Serial> in kasp.xml
> which cannot be used in our case.
I think this would make a valid feature request. Why don't you enter it in JIRA
with a bit of background on your usecase? We'd like to have it too.
>> Hope this helps.
> Thanks, it certainly did. (And I think we can sort out the problems
> getting the outbound SOA increase on standby server activation, too.)
Good luck then!
More information about the Opendnssec-user