[Opendnssec-user] Hot standby redundancy with OpenDNSSEC 1.4 and DNS Input Adapter

[Rick van Rein (OpenFortress)]

Hi Ville,

> 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
>> signing.
> 
> 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!

 -Rick