29 Led
2025
29 Led
'25
19:49
Me neither, that's why I'm experimenting :-)
I wonder if there's some confusion here, possibly on my end. :)
- AXFR needs a static IP for master vs. nsupdate
allows dynamic IP
XFR from a primary (or secondary) needs a known address, correct, but directing
an RFC2136 update to a server requires knowing that server's IP as well.
Without specifying a target, the UPDATE will be sent to the SOA MNAME by
default.
To me this is comparing apples and slices of chocolate :)
- AXFR needs DNSSEC keys on machine keeping zonefiles
vs nsupdate can
delegate signing to server (but doesn't have to)
DNSSEC keys must exist on the signer, typically a primary; it's independent on
whether that will be an XFR source or an UPDATE target. The signer needs the
keys.
nsupdate doesn't "delegate signing"; the update target will sign if signed.
- AXFR makes multi-master complicated^TM - nsupdate
doesn't care as long
as SOA is increasing.
This sounds to me as though you intend sending UPDATEs to each of your
secondaries individually. Good luck doing that and keeping the result
consistent, particularly if you're signing.
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.
Indeed. That's why XFR was invented.
So that makes nsupdate+nsdiff look a lot more
convinient and clean to me.
With a single target, I don't disagree; with multiple, well I've commented on
that.
Regards,
-JP