Describe the bug
When the primary has older version of the zone than secondary, and IXFR query arrives, the primary responds the IXFR query with a simple response, consisting of only his own SOA (with the older serial).
Although this situation is operationally undesirable, the response itself is perfectly correct.
When dnspython parses the response, in xfr.py:148 it throws SerialWentBackwards exception. This prevents further processing of the response.
I do understand that dnspython tries to warn the user about the situation. However, exception is perhaps not the best way.
In Knot DNS's test environment, we actually prepare this exact situation intentionally, and we would like that dnspython parses the response, so that we can check that it does contain exactly what it should: that single SOA. Currently we only obtain the exception and no insight into the received packet, its RRsets etc.
To Reproduce
Use dnspython to send IXFR to any nameserver that allows it, while setting the serial to a high number.
Comment
We are now observing this issue after upgrading to Ubuntu 26.04 from an older one. What is weird is that the code throwing the problematic exception is many years old. Is it possible that the code was there, yet non-functional, so that the exception was not thrown and the response parsed normally?
Context (please complete the following information):
- dnspython version 2.8.0
- Python version 3.14.4
- OS: Ubuntu 26.04
Describe the bug
When the primary has older version of the zone than secondary, and IXFR query arrives, the primary responds the IXFR query with a simple response, consisting of only his own SOA (with the older serial).
Although this situation is operationally undesirable, the response itself is perfectly correct.
When dnspython parses the response, in xfr.py:148 it throws SerialWentBackwards exception. This prevents further processing of the response.
I do understand that dnspython tries to warn the user about the situation. However, exception is perhaps not the best way.
In Knot DNS's test environment, we actually prepare this exact situation intentionally, and we would like that dnspython parses the response, so that we can check that it does contain exactly what it should: that single SOA. Currently we only obtain the exception and no insight into the received packet, its RRsets etc.
To Reproduce
Use dnspython to send IXFR to any nameserver that allows it, while setting the serial to a high number.
Comment
We are now observing this issue after upgrading to Ubuntu 26.04 from an older one. What is weird is that the code throwing the problematic exception is many years old. Is it possible that the code was there, yet non-functional, so that the exception was not thrown and the response parsed normally?
Context (please complete the following information):