Hi,
how I understand the situation is that Daniel's primary server (which is
probably also a signer) is also a catalog consumer.
And the zone contents are probably derived from some database (or
something) and the question is, how to fill them into the primary, if
zone files are not desired for any reason.
Point is, that DDNS was always (and this is not limited to Knot DNS)
intended as an _update_ facility -- modifying existing zone. It does not
support bootstrapping, when the zone is not yet loaded from zone file
(or AXFRed from anywhere).
What I would recommend is to use generic zone file (which uses "@" in
all places where zone name would be) with dummy contents, so that the
newly created (by catalog) zone is loaded with something, and after that
fill the right contents with DDNS.
In the attachment, you can find an example of a generic zone file (it
can be much shorter, Knot might even forgive not including any apex NS).
With that, the catalog member template can be configured along following
ideas:
template:
- id: catalog_member
file: /somehwere/generic.zone
zonefile-sync: -1 # dont overwrite generic zonefile
journal-content: all
acl: allow_ddns
notify: [ secondary1, secondary2 ]
By the way, I would not recommend using SOA MNAME in 2025, better always
know the IP of the specific server you need to update.
Libor
On 29. 01. 25 20:49, Jan-Piet Mens wrote:
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
--
$TTL 3600
@ SOA dns1 hostmaster 2010111201 10800 3600 1209600 7200
NS dns1
NS dns2
MX 10 mail
dns1 A 192.0.2.1
AAAA 2001:DB8::1
dns2 A 192.0.2.2
AAAA 2001:DB8::2
mail A 192.0.2.3
AAAA 2001:DB8::3
--
