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

[Ville Mattila]

Hi Rick, list,

On 11.04.2013 17:57, Rick van Rein (OpenFortress) wrote:

>> What would be a proper way to snapshot the signing state of a zone from
>> a server running OpenDNSSEC 1.4?
> 
> If you mean the state of the ods-signer process, you do not need to replicate it.

With signing state of a zone I was thinking of the state of key
roll-overs found in KASP db, the published signatures and DNS Input
Adapter internal operational parameters.  But I was wrong.  The standby
server generally does not indeed need the current published signed
version of the zone, nor the DNS Input Adapter state.  (Though DNS
Output Adapter state might be needed.)

> It is perfectly safe to re-sign the zone as long as you use the same
> key set.  This means that you need to use the same signconf process,
> which in turns means that the KASP database should be replicated.  And
> that should be all you need to do.

You are right.  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).

I was confused because for some reason I was thinking we should make the
standby server activation invisible to the outside world.  But in our
case it's perfectly ok to let the standby generate new signatures and
NSEC3 chain causing all zones to be AXFR'ed to DNS servers,
as we have only about 10MB total unsigned zone data in only about 1000
zones.

> 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:

Apr 12 12:34:17 signer1 ods-signerd: [namedb] update serial:
format=unixtime in=0 internal=0 out=0 now=1365759257
Apr 12 12:34:17 signer1 ods-signerd: [namedb] unable to use unixtime as
serial: 1365759257 does not increase 2013041212. Serial set to 2013041213
Apr 12 12:34:17 signer1 ods-signerd: [namedb] update serial: 2013041212
+ 1 = 2013041213

In our case the signer's DNS Input Adapter inbound SOA serial only
changes when the unsigned zone is changed which does not happen
regularly/automatically: we have zones which were last changed 12 years
ago.  Thus it would be really nice if OpenDNSSEC signerd could be
configured to run a user-specified command which would be passed the
zone name (and perhaps the DNS output adapter configuration) on the
command line and/or STDIN and which would then return (on it's STDOUT)
the SOA serial number signerd should put in the signed zone file: we
would then write a script which looks up the highest serial number from
zone's authoritative servers and return something higher.

> 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.  But it's also nice if the redundancy could
be easily exploited in system administration to avoid service breaks:
e.g. promote standby server as active while installing updates on and
rebooting the primary, then switch back the active signing role to
primary, and preferably all this doable within one hour.

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

>> Is there going to be something like 'ods-signer snapshot <zone>
>> <serial>' suitable for this purpose?  Or possibly have ods-signerd
>> export the snapshot automatically in a spool file for NotifyCommand to
>> consume?
> 
> I don't understand this fully, but I'm intruiged.  What exactly should these do?

I was thinking of the snapshot of the signing state of the zone as
defined earlier (KASP+signerd state and inbound/internal/outbound SOA
serials).  But 'ods-ksmutil database backup' may be enough as discussed
above.

>> Note:  A hot standby might not need a fully exact and complete snapshot
>> of OpenDNSSEC state.  We just need a hot standby ready to (be manually
>> activated to) carry on signing the zones from the point of last
>> _published_ version of the zones, should the primary server fail at any
>> given time.
> 
> That's how we also set it up, http://dnssec.surfnet.nl/
> 
> 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.)

Ville Mattila
CSC/Funet