[Opendnssec-user] SOA serial keep strategy

[Yuri Schaeffer]

Hi,

One of the SOA serial strategies OpenDNSSEC has is keep. OpenDNSSEC will
never change the serial it receives from the master, it will be just
copied over. As a consequence only changes to the signed zone can be
made when a change from the master comes in. OpenDNSSEC will not be able
to refresh signatures (and thus they might expire) until a change comes
in. OpenDNSSEC can not ensure validity of a zone.

Personally I think the keep strategy is just generally a bad idea. I'm
thinking about deprecating the keep strategy in favour of simpler code
and less chance to shoot yourself in the foot. Therefore I'd like to
know if there (still) is actually any demand for this feature. An
important use case I'm missing. Is anyone using this?

Regards,
Yuri

[Roland van Rijswijk - Deij]

Hi Yuri,

Post by Yuri Schaeffer
One of the SOA serial strategies OpenDNSSEC has is keep. OpenDNSSEC will
never change the serial it receives from the master, it will be just
copied over. As a consequence only changes to the signed zone can be
made when a change from the master comes in. OpenDNSSEC will not be able
to refresh signatures (and thus they might expire) until a change comes
in. OpenDNSSEC can not ensure validity of a zone.
Personally I think the keep strategy is just generally a bad idea. I'm
thinking about deprecating the keep strategy in favour of simpler code
and less chance to shoot yourself in the foot. Therefore I'd like to
know if there (still) is actually any demand for this feature. An
important use case I'm missing. Is anyone using this?

If I remember correctly, the rationale for having this strategy is to
facilitate TLD operators, who run the signer manually once they have
produced a zone from data in their registry backend systems. Since they
generally have a regular refresh cycle, I don't think signature
expiration would be an issue for them.

So while I would agree that for most users this is a bad strategy (for
the reasons you mention), there might be an actual use case for it. Any
TLD operators want to jump in and comment?

Perhaps it makes sense to issue a (suppressable) warning in the logs if
this strategy is chosen.

Those were my €0.02 ;-)

Cheers,

Roland

[Tomas Simonaitis]

Hi,

we are using keep strategy and would prefer if this option
would stay available.
We are periodically generating new zone (with new serial),
making various checks, signing it and running checks against signed zone
- it's
convenient that serial stays the same after signing (as it was generated).

--
Best Regards,
Tomas Simonaitis
.lt, Domreg.lt

Post by Yuri Schaeffer
Hi,
One of the SOA serial strategies OpenDNSSEC has is keep. OpenDNSSEC will
never change the serial it receives from the master, it will be just
copied over. As a consequence only changes to the signed zone can be
made when a change from the master comes in. OpenDNSSEC will not be able
to refresh signatures (and thus they might expire) until a change comes
in. OpenDNSSEC can not ensure validity of a zone.
Personally I think the keep strategy is just generally a bad idea. I'm
thinking about deprecating the keep strategy in favour of simpler code
and less chance to shoot yourself in the foot. Therefore I'd like to
know if there (still) is actually any demand for this feature. An
important use case I'm missing. Is anyone using this?

[Peter van Dijk]

Hi Yuri,

Post by Yuri Schaeffer
One of the SOA serial strategies OpenDNSSEC has is keep. OpenDNSSEC will
never change the serial it receives from the master, it will be just
copied over. As a consequence only changes to the signed zone can be
made when a change from the master comes in. OpenDNSSEC will not be able
to refresh signatures (and thus they might expire) until a change comes
in. OpenDNSSEC can not ensure validity of a zone.
Personally I think the keep strategy is just generally a bad idea. I'm
thinking about deprecating the keep strategy in favour of simpler code
and less chance to shoot yourself in the foot. Therefore I'd like to
know if there (still) is actually any demand for this feature. An
important use case I'm missing. Is anyone using this?

I’m not using this, but here are my 2 cents: PowerDNS, when operating as a slave, will periodically check the SOA serial (like most DNS daemons do when configured as a slave for a zone). On top of that, we also check the expiry of the SOA RRSIG. If that changes, we also refetch the zone. Thus, with PowerDNS slaves, ‘keep’ is a legit use case. Other daemons may want to consider also implementing this. Users of daemons that do not implement this will, of course, need to be careful about either (a) updating their upstream zones periodically or (b) forcing periodic refetches from OpenDNSSEC.

Kind regards,

[Yuri Schaeffer]

Hi Peter,

I’m not using this, but here are my 2 cents: PowerDNS, when operating
as a slave, will periodically check the SOA serial (like most DNS
daemons do when configured as a slave for a zone). On top of that, we
also check the expiry of the SOA RRSIG. If that changes, we also
refetch the zone. Thus, with PowerDNS slaves, ‘keep’ is a legit use
case. Other daemons may want to consider also implementing this.
Users of daemons that do not implement this will, of course, need to
be careful about either (a) updating their upstream zones
periodically or (b) forcing periodic refetches from OpenDNSSEC.

Interesting idea. But it doesn't really solve the problem at hand.
Specifically if OpenDNSSEC would use 'keep', and it doesn't get an
update from the master. It isn't able to publish a new version of the
zone since it cannot bump the serial on its own. As signing software it
is in my opinion really a no-go to publish a zone twice with the same
version number but with different content. (imagine how this would screw
up IXFR amongst other problems.)

So even if PowerDNS would detect an expired RRSIG SOA it can't get a
'good' version from OpenDNSSEC until upstream bumps the unsigned zone.

Moreover the SOA signature is guaranteed to expire last. Since the SOA
WILL get resigned for every new version. So it is a poor method of
detecting a stale zone.

So the feature might enhance the refresh value from the SOA, which is
nice I guess, but I don't think it will solve much here.

//Yuri