Feature request: signal to a secondary that received REFUSED on ixfr, to retry IXFR instead of AXFR on next attempt
Use case as explained to Support:
We have BIND transferring from a DNS device that occasionally, and temporarily, cannot provide an [AI]XFR. It signals this with a REFUSED rcode. Unfortunately when our BIND server receives this REFUSED response, the next XFR request is an AXFR. I understand that this is likely for compatibility reasons as some master may refuse an IXFR because it doesn't support it, but that is not the case here. Never mind the fact that one might hope to receive NOTIMP in such a case. I know that when IXFR is not available for journal reasons, the device is able to send AXFR as IXFR and BIND handles that perfectly fine, so I don't think its necessary to fail over to AXFR for the somewhat more common scenario where IXFR is not possible but AXFR is possible.
Is there something that can be done on either end that would avoid this sub-optimal behaviour? Some ideas:
a) Have BIND not fail over to AXFR after BIND receives a REFUSED rcode b) Have our device send some other rcode that BIND would not cause BIND to fail over to AXFR. In this case I would be looking for guidance on what RCODE we ask the device vendor to use instead.
I could envisage a configuration option for how many IXFR attempts there are on a hard fail (for some definition of 'hard fail' that includes REFUSED) before trying again with a request for an AXFR, default being 0 (which is what we do now).
I have no idea if there's a better way to handle b), although I suspect that simply just not responding would cause an IXFR retry wouldn't it?
This is a genuine operational problem, so suggestions for workarounds would also be much appreciated.