Hi, a brief follow-up to this...
The problem isn't that the IXFR request is malformed per the DNS protocol; the reason tcpdump doesn't decode the request correctly is that the request is split over two different TCP datagrams. It seems needlessly wasteful to send the first two bytes of the DNS request in its own TCP datagram (the "push" TCP flag is set on the two-byte TCP segment, even). However, wireshark managed to "reassemble" the DNS request (I'm suitably impressed!) and decode it. It seems that the problem is that the SOA version number used in the IXFR request is totally "off the wall"; I'm seeing 3180924024, which is way bigger than what's in the .xfrd-state file (2014091709), but still "bigger" according to the serial number arithmetic used for SOA version numbers. So "of course" BIND just responds with the current SOA record in its 1-record reply and times out the TCP connection after 30 seconds because no further requests are received from OpenDNSSEC. More code reading is needed to find out why OpenDNSSEC messes up the version number in the IXFR request. It seems the same SOA version number is used in the immediately preceding UDP-based IXFR request, so at least it's consistent... Regards, - Håvard _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
