BIND 9.18 unable to successfully transfer zone from axfrdns primary

[Michael Sinatra]

Right, BIND 9.18 now enforces Section 2.2 of RFC 5936, specifically, this:
    "The AXFR server MUST copy the
    Question section from the corresponding AXFR query message into the
    first response message's Question section.  For subsequent messages,
    it MAY do the same or leave the Question section empty."

There are some older implementations out there that don't do this 
correctly.  I have a vendor supported IPAM implementation, where I have 
gone back to the vendor and quoted the above, and they have fixed the 
implementation.

michael

On 8/31/23 17:34, Ian Bobbitt wrote:
> That gets me more information, and I think puts the problem onto 
> axfrdns. Thanks.
> 
> xfer-in: info: zone example.net/IN: Transfer started.
> xfer-in: debug 1: zone example.net/IN: forced reload, requesting AXFR of 
> initial version from 198.51.100.1#53
> xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
> connected using 198.51.100.1#53
> xfer-in: debug 3: transfer of 'example.net/IN' from 198.51.100.1#53: 
> sent request data
> xfer-in: debug 3: transfer of 'example.net/IN' from 198.51.100.1#53: 
> missing question section
> xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: 
> failed while receiving responses: FORMERR
> xfer-in: debug 1: zone example.net/IN: zone transfer finished: FORMERR
> xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
> Transfer status: FORMERR
> 
> Looks like this isn't going to be solvable on my side. 
> https://gitlab.isc.org/isc-projects/bind9/-/blob/v9.18.17/lib/dns/xfrin.c?ref_type=tags#L1657-1663
> 
> Packet capture confirms that we are indeed not getting a response with 
> the question section.
> 
> I'm running the same version of dig, on the same system. Interesting 
> that dig isn't as strict about this.
> 
> -- Ian
> 
> On 8/31/23 7:58 PM, Mark Andrews wrote:
>> Set debug level 3 on the xfrin channel.  There are some debug level 
>> messages that really should be set to error level in lib/dns/xfrin.c 
>> on FORMERR.
>>
>> Also make sure you are running dig from the same version as later 
>> versions are more strict in parsing responses from the wire.
>>
>>> On 1 Sep 2023, at 09:23, Ian Bobbitt <ibobbitt at grnoc.iu.edu> wrote:
>>>
>>> I have a system running BIND 9.18.17 that needs to transfer a zone 
>>> from djbdns/axfrdns. I receive FORMERRs, and haven't been able to get 
>>> any log messages indicating the problem.
>>>
>>> xfer-in: info: zone example.net/IN: Transfer started.
>>> xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
>>> connected using192.0.2.1 #53
>>> xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: 
>>> failed while receiving responses: FORMERR
>>> xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
>>> Transfer status: FORMERR
>>> xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
>>> Transfer completed: 0 messages, 0 records, 0 bytes, 0.008 secs (0 
>>> bytes/sec) (serial 0)
>>>
>>> This replaced a long obsolete system running 9.8.2 that was able to 
>>> successfully transfer the zone. I can also successfully transfer the 
>>> zone with `dig -t axfr ...` from the new system, which gives no 
>>> errors. named-checkzone on the resulting data also gives no errors, 
>>> and BIND is able to successfully load it as a primary.
>>>
>>> How do I go about finding the cause of the FORMERR and resolve it?
>>>
>>> -- Ian
>>> -- 
>>> Visit https://lists.isc.org/mailman/listinfo/bind-users to 
>>> unsubscribe from this list
>>>
>>> ISC funds the development of this software with paid support 
>>> subscriptions. Contact us at https://www.isc.org/contact/ for more 
>>> information.
>>>
>>>
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users