[Opendnssec-user] 1.4.9: Zones not properly updating -- fallout from upgrade?

[Havard Eidnes]

Hi,

following up to my own message with some more information:

> And querying the OpenDNSSEC server from the public master (using
> the TSIG key configured, of course) gives:
>
> korunikhum.no.          3600    IN      SOA     ns.uninett.no. elisabeth.uninett.no. 2016022600 28800 3600 604800 900
>
> and
>
> korunikhum.no.          86400   IN      NS      nn.uninett.no.
> korunikhum.no.          86400   IN      NS      ns.uninett.no.
> korunikhum.no.          86400   IN      RRSIG   NS 8 2 86400 20160318015502 20160226120504 31363 korunikhum.no. kd0J2sH6ksROVmfRigVlaGv7to1HtkGE24aI2Z2ihxEuy6Jqn0POXQ7W Xq7c1OpER+AGuVsfG9T0vALyn6f6s3kA41zeI+rlXLeb9M21hCqBM59E WKXDtFnHxut9ejtaSOMVM+ex2bSHHTz5DTqCmoqvGXAMazKBdBwzIy5Y AZI=
>
> So OpenDNSSEC responds with the updated signature on the NS set,
> but also with a newer SOA version number.  However, come zone
> transfer time, precious few records are transferred, and neither
> the SOA nor the NS RRSIG records are updated.

If I do an AXFR from ns.uninett.no towards my OpenDNSSEC host for
this zone, I get (somewhat surprisingly):

; ...
korunikhum.no.          3600    IN      SOA     ns.uninett.no. elisabeth.uninett.no. 2016022600 28800 3600 604800 900
; ...
korunikhum.no.          86400   IN      NS      nn.uninett.no.
korunikhum.no.          86400   IN      NS      ns.uninett.no.
korunikhum.no.          86400   IN      RRSIG   NS 8 2 86400 20160318015502 20160226120504 31363 korunikhum.no. kd0J2sH6ksROVmfRigVlaGv7to1HtkGE24aI2Z2ihxEuy6Jqn0POXQ7W Xq7c1OpER+AGuVsfG9T0vALyn6f6s3kA41zeI+rlXLeb9M21hCqBM59E WKXDtFnHxut9ejtaSOMVM+ex2bSHHTz5DTqCmoqvGXAMazKBdBwzIy5Y AZI=
; ...

I.e. I do get the SOA and the RRSIG from the backup2 file.  So
it's "only" IXFR which is failing, but since it on a protocol
level appears to work fine (albeit with quite a few warnings as
seen from the verbose logging), reversion to AXFR does not take
place.

I always thought it was a little strange that OpenDNSSEC would
support a strictly optional but "high degree of difficulty"
operation such as IXFR in the initial implementation of the "zone
transfer" in+out feature.  The present case shows that doing so
robustly is not easy...

Regards,

- Håvard