[Opendnssec-user] Version 1.4.7 IXFR problems

[Sebastian Wiesinger]

Hello,

I noticed a problem with OpenDNSSEC 1.4.7 and IXFRs.

I have a zone configured in OpenDNSSEC that interacts with a BIND
server. OpenDNSSEC pulls the zone via IXFR and the BIND server
transfers the signed zone back, also via IXFR.

I noticed that when I only change the default TTL of the zone (via
$TTL statement) that the new TTL for the RRs is not transfered from
OpenDNSSEC back to BIND in the signed version of the zone via IXFR but
the RRSIG for the RR has the new TTL.

When I disable IXFRs for opendnssec in BIND the zone is transferred
with the correct TTLs. Also when I do a manual 'rndc retransfer
<zone>' it will fix the TTLs.

I reproduced this with two different zones.

Example Zone:
$TTL 1800
@ IN SOA ns1.karotte.org. hostmaster.6v6.de. (
106 ; Serial
10800 ; Refresh
3600 ; Retry
2419200 ; Expire
3600 ) ; Neg. TTL

86400 NS ns1.karotte.org.
86400 NS dns.noris.net.
86400 NS ns6.gandi.net.

sukzessiv CNAME upmbey4aer5jjkun.myfritz.net.

I now change the $TTL from 1800 to 2000.

When I AXFR the zone directly from OpenDNSSEC I get the right TTL for the
"sukzessiv" RR and the RRSIG:

sukzessiv.6v6.de. 2000 IN CNAME upmbey4aer5jjkun.myfritz.net.
sukzessiv.6v6.de. 2000 IN RRSIG CNAME 8 3 2000 20150909065841 20150810105620 57288 6v6.de. G5LxbfqWAZZ+D9FbbnNlId0vqk0Q0T62P5GTp57/ys9fzxOx9vl6mK+0 fQYtbR8JXI9lXFGCfj/9w0BTTivpqVsB7/uv5X8LMf0cMvnLRBvOylq1 4CXdtQRmWPspoRSPCt6jlcfUL46d69N9BqLwylnDQmpjeAMN87L5V5km zmo=

When I do the same AXFR towards the BIND server that transmitted the
zone from OpenDNSSEC via IXFR I get:

sukzessiv.6v6.de. 2000 IN RRSIG CNAME 8 3 2000 20150909065841 20150810105620 57288 6v6.de. G5LxbfqWAZZ+D9FbbnNlId0vqk0Q0T62P5GTp57/ys9fzxOx9vl6mK+0 fQYtbR8JXI9lXFGCfj/9w0BTTivpqVsB7/uv5X8LMf0cMvnLRBvOylq1 4CXdtQRmWPspoRSPCt6jlcfUL46d69N9BqLwylnDQmpjeAMN87L5V5km zmo=
sukzessiv.6v6.de. 1800 IN CNAME upmbey4aer5jjkun.myfritz.net.

Notice the old TTL of the CNAME.

When I now do a 'rndc retransfer 6v6.de IN default', which forces bind
to retransfer the whole zone, it has the correct TTL again:

sukzessiv.6v6.de. 2000 IN RRSIG CNAME 8 3 2000 20150909065841 20150810105620 57288 6v6.de. G5LxbfqWAZZ+D9FbbnNlId0vqk0Q0T62P5GTp57/ys9fzxOx9vl6mK+0 fQYtbR8JXI9lXFGCfj/9w0BTTivpqVsB7/uv5X8LMf0cMvnLRBvOylq1 4CXdtQRmWPspoRSPCt6jlcfUL46d69N9BqLwylnDQmpjeAMN87L5V5km zmo=
sukzessiv.6v6.de. 2000 IN CNAME upmbey4aer5jjkun.myfritz.net.


It seems that OpenDNSSEC is not sending the changed CNAME TTL back to
BIND when it answers the IXFR request.

As a workaround I can specify

server <opendnssec> {
provide-ixfr no;
request-ixfr no;
};

in the BIND config. It would be nice if there would be a switch to
disable IXFR in opendnssec as well.

Regards

Sebastian

[Jan-Piet Mens]

It would be nice if there would be a switch to disable IXFR in
opendnssec as well.

I concur. Using NSD 4.1.3 I also see issues with IXFR running against
OpenDNSSEC 1.4/devel. Some examples:

nsd[20457]: info: xfrd: zone m04 bad transfer 6 from 192.168.1.110

===

nsd[20458]: warning: diff: RR <m04., RRSIG> rdata element 0 differs from RR num 5 rdata (rdata data)
nsd[20458]: warning: diff: RR <m04., RRSIG> rdata element 0 differs from RR num 6 rdata (rdata data)
[...]
nsd[20458]: warning: diff: RR <m04., RRSIG> rdata element 0 differs from RR num 7 rdata (rdata data)
nsd[20458]: warning: diff: RR <m04., RRSIG> does not exist
nsd[20458]: error: Failed to apply IXFR cleanly (deletes nonexistent RRs, adds existing RRs). Zone m04. contents is different from master, starting AXFR. Transfer received update to serial 8 at 2015-08-10T08:02:55 from 192.168.1.110
nsd[20458]: info: zone m04. received update to serial 8 at 2015-08-10T08:02:55 from 192.168.1.110 of 9720 bytes in 0.000194 seconds
nsd[20457]: error: xfrd: zone m04: soa serial 8 update failed, restarting transfer (notified zone)
nsd[20457]: info: xfrd: zone m04 written received XFR packet from 192.168.1.110 with serial 8 to disk
nsd[20457]: info: xfrd: zone m04 committed "received update to serial 8 at 2015-08-10T08:02:55 from 192.168.1.110"
nsd[20458]: info: rehash of zone m04. with parameters 1 0 5 9a8991824201b96d
nsd[20458]: info: zone m04. received update to serial 8 at 2015-08-10T08:02:55 from 192.168.1.110 of 4682 bytes in 0.000167 seconds
nsd[20457]: info: zone m04 serial 7 is updated to 8.

===

nsd[19726]: info: notify for m04. from 192.168.1.110
nsd[20457]: info: xfrd: zone m04 written received XFR packet from 192.168.1.110 with serial 32 to disk
nsd[20457]: info: xfrd: zone m04 written received XFR packet from 192.168.1.110 with serial 32 to disk
nsd[20457]: info: xfrd: zone m04 written received XFR packet from 192.168.1.110 with serial 32 to disk
nsd[20457]: info: xfrd: zone m04 written received XFR packet from 192.168.1.110 with serial 32 to disk
nsd[20457]: info: xfrd: zone m04 written received XFR packet from 192.168.1.110 with serial 32 to disk
nsd[20457]: info: xfrd: zone m04 reverted transfer 32 from 192.168.1.110

I've given up on that and now configure NSD to use AXFR only:

request-xfr: AXFR 192.168.1.110 NOKEY
^^^^

Regards,

-JP

[Havard Eidnes]

Post by Sebastian Wiesinger
I noticed a problem with OpenDNSSEC 1.4.7 and IXFRs.

Me too. I think I discussed this already under the slightly
misleading subject "TTL clamped to minimum 3600". It turns out that
only change of TTL does not flag those records for inclusion in an
IXFR, and my last message on the subject of January 22 pointed the
finger of suspicion on a code fragment in zone_add_rr(). I've not
seen any further comments on this, though.

This is also reported as

https://issues.opendnssec.org/browse/SUPPORT-186

Regards,

- Håvard

[Berry A.W. van Halderen]

Post by Havard Eidnes
Me too. I think I discussed this already under the slightly
misleading subject "TTL clamped to minimum 3600". It turns out that
only change of TTL does not flag those records for inclusion in an
IXFR, and my last message on the subject of January 22 pointed the
finger of suspicion on a code fragment in zone_add_rr(). I've not
seen any further comments on this, though.

We had report in slightly different form of this issue as well.
A candidate solution has been placed out for testing in the reporters
environment, and pending the outcome we want to merge this in.

We have made a pull-request which you can try as well, if you're
able to fetch it. It is at:
https://github.com/opendnssec/opendnssec/pull/375
This change is for the 2.0 release, but it be applied to 1.4 as well.
I've placed a patch that can be applied to 1.4 source tree in the
support issue:
https://issues.opendnssec.org/browse/SUPPORT-186
that can be applied to the latest 1.4 release.

The issue had been reproducible at our end and relates, as our
conclusions go, to a change in the TTL only for RR records isn't
properly recognized, and skipped. Since the issue seems to
come in different forms there remains the uncertainty that there
is just a single issue.
For OpenDNSSEC, any change and also just a TTL change is best handled
by the removal of the record and re-adding it. The change in the pull
request works this way.

It would be nice to see this solution being confirmed so we can place
it in and possibly make a release.

Berry van Halderen