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

Reply via email to