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

Wed Apr 17 13:01:16 UTC 2013

Hi,

On 04/12/2013 12:46 PM, Ville Mattila wrote:
> 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.

If you do really need the signer zone state, the signer engine will
store the state per zone in the working directory (usually
/var/opendnssec/tmp). It will store the inbound and outbound serial
amongst other data.

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

A long time ago (version 1.1 I believe) we changed the behavior to make
the serial always increment the serial in the unsigned zone to provide
an easy integration of new unsigned zones added to OpenDNSSEC. In code:

    prev = max(db->outserial, inbound_serial);
    if (!db->is_initialized) {
        prev = inbound_serial;
    }

And make sure that the new serial increments prev. That's why the signer
engine does not like the unixtime in your case.

(I will follow-up on this in SUPPORT-57).

Best regards,
  Matthijs

> 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
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20130417/a9520443/attachment.bin>