When NSD is in a role of being both slave for a zone and providing XFR services for that zone, what would be the expected behaviour when while doing an AXFR, it gets notified or get a new AXFR/IXFR from upstream ? Would it be terminating the in-progress transfer abruptly or still going thru until the transfer ends ?
It sounds like you have a problem or concern that you didn't describe.
If you have frequent transfers of large zones (maybe to slow slaves or from a slow master?) you'll be better off having the intermediary "transfer hub" run something that can serve IXFR transfers. Bind works well for this, even if the upstream can't do IXFRs.
Then the downstream hosts will just get a small update to apply.
It sounds like you have a problem or concern that you didn't describe.
Indeed, but I'm trying not to categorise something as a problem before knowing what the expected outcome was.
If you have frequent transfers of large zones (maybe to slow slaves or from a slow master?) you'll be better off having the intermediary "transfer hub" run something that can serve IXFR transfers. Bind works well for this, even if the upstream can't do IXFRs.
Then the downstream hosts will just get a small update to apply.
Ask
Upstream can do IXFR, and the fetch process from upstream uses IXFR for 99.9% of times (AXFR is forced every few days).
Downstream slave is the one forcing AXFR.
BTW, it would be interesting to know whether this has changed in newer NSD 3.2 or 4.x builds, or if there is still a design decision to interrupt downstream AXFR if there is notification of a zone update.
It sounds like you have a problem or concern that you didn't
describe.
Indeed, but I'm trying not to categorise something as a problem
before knowing what the expected outcome was.
BTW, it would be interesting to know whether this has changed in
newer NSD 3.2 or 4.x builds, or if there is still a design decision
to interrupt downstream AXFR if there is notification of a zone
update.
There is no transfer interruption. The transfer should conclude, the
notify is simply recorded for future actions once the current actions
are done.
If the downstream transfer is very slow, it will get interrupted as
the new zone is hosted and the old-zone's process gets killed off.
BTW, it would be interesting to know whether this has changed in
newer NSD 3.2 or 4.x builds, or if there is still a design decision
to interrupt downstream AXFR if there is notification of a zone
update.
There is no transfer interruption. The transfer should conclude, the
notify is simply recorded for future actions once the current actions
are done.
At least with 3.2.17, transfer interruption is exactly what's happening.
If the downstream transfer is very slow, it will get interrupted as
the new zone is hosted and the old-zone's process gets killed off.
The downstream transfer is taking somewhere between 13 and 59 seconds depending on network conditions, so it's slow but not incredibly slow. Sometimes it's happening while the zone gets updated, and then the TCP session is simply ended in the middle of the transfer.