Hi Daniel, On Wed, Jan 29, 2025 at 08:41:42AM +0100, Daniel Salzman wrote: > you are right, this is not possible. It's a historical design and I don't > know if there is still a good reason for that. We will investigate.
Awesome! Thanks for taking the time. > However, I don't understand the benefits of DDNS over XFR? Me neither, that's why I'm experimenting :-) My current understanding is that the main tradeoffs are these: - AXFR needs a static IP for master vs. nsupdate allows dynamic IP - AXFR needs DNSSEC keys on machine keeping zonefiles vs nsupdate can delegate signing to server (but doesn't have to) - AXFR makes multi-master complicated^TM - nsupdate doesn't care as long as SOA is increasing. Consider a setup where zone files are in git and I want to push DNS updates in a gitops'y way. I could in principle setup a knot AXFR master as part of the CI build, perhaps along with some VPN to satisfy the static IP requirement, send a NOTIFY, parse logs to figure out if all slaves went and got them and tear down the build, but it's a major hassle. AFAICT there is no way to have knot slaves come back to the IP that sent them a NOTIFY (not to mention other implementations) so there is no way to escape needing a static IP for the master. Additionally error reporting is non-existent in that setup unless I pain stakingly add checks by parsing logs. I'd sooner go back to SSHing to the master. OTOH nsupdate just tells me if something failed as we saw. Anyway, my personal use-case is similar: zonefiles are (file) synced across my workstation(s) but in addition to having dynamic IPs and machines not always being up and there's two of them and I want to work on DNS on either :-) So that makes nsupdate+nsdiff look a lot more convinient and clean to me. Thanks, --Daniel --
