29 Led
2025
29 Led
'25
10:14
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