I wonder if there's some confusion here, possibly on my end. :) 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 :) 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. 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. Indeed. That's why XFR was invented. With a single target, I don't disagree; with multiple, well I've commented on that. Regards, -JP

Hi Jan-Piet, Libor, On Wed, Jan 29, 2025 at 08:49:06PM +0100, Jan-Piet Mens wrote: I should have explained my topology better. The nsupdate based setup looks like this: [Workstation] ->RFC2136 [Primary] ->AXFR [Slaves...] The tradeoffs I'm referring to are in that first hop. Primary always has a static IP that's no problem, but with AXFR between Workstation and Primary the Workstation needs a static IP too. That's what I'm avoiding by using nsupdate. Note for auth I'd be using just TSIG here no IP ACL, or perhaps one that allows my entire /48 space. I wouldn't mind both an apple and some chocolate right now, all I have is bananas on the long journey to FOSDEM :-) Right, here I was confused. If I accept the "spin up a temporary knot" approach this is also possible with AXFR. Perhaps my point should have been this: the nsupdate approach is (also) flexible with regard to who the signer is. No, I'm intending to add a second primary (ok, technically first-level secondary if you're thinking in AXFR terms) if the basic setup works. I'm still experimenting with that. Ofc signing is going to make things complicated. Perhaps that will make having keys on the Workstation preferable to dealing with that or I'll just drop the multi-master idea. We'll see. I dont think I get your meaning? If XFR was invented for this particular use-case I sure hope the setup wouldnt need to be as convoluted and difficult as I'm describing :-) Libor, On Thu, Jan 30, 2025 at 08:46:22AM +0100, Libor Peltan wrote: Correct. No database (or something). Just zonefiles on my workstation(s). The tricky bit is that I switch between working on my laptop and desktop machines. That's my personal use-case, but you can just as well imagine an organizational use-case where different people should be able to work on the same zonefiles synced via git instead of syncthing (which I use). Note that in the git based scenario you could use CI automation for deploying or people could just run nsupdate on their machines. Doesn't matter. Which is a nice property of this setup IMO. Right. I have considered the basic idea of using a dummy zonefile and discarded the idea as janky :-P. My approach would have been a cronjob that parses the catalog zone, but your approach of using just a generic zonefile does make this significantly more appealing. I see one problem: say I have secondaries where the relevant zone already exists, now I redeploy the primary (after, say, the machine goes up in flames). For a short while there secondaries will see the dummy zone's serial. IF I'm unlucky and the serial-math works out whatever serial the secondaries have right now could conceivably be lower than whatever is in the dummy zone (remember: RFC1982) causing them to empty the zone causing an otherwise harmless hidden-primary outage to escalate significantly. Now that scenario is impossible in my lab as I use date-based serials but I'd (ideally) like this setup to also be applicable to high update rate zones where those won't work. Thanks! I'm going to use this to carry on my experiments but I do think an option to allow UPDATE to create zones (if they are in the catalog already) would still be useful. The server has IP ACLs and requires TSIG for UPDATEs I don't see why it matters where nsupdate gets the server name from. I know knsupdate doesn't support this I'd probably still script that with (k)dig if needed ;-) I'm not as well read in the more recent DNS RFCs as I perhaps should be (did anything important happen since 1987 anyway? ;-P), is there a good reason that I'm not seeing? Thanks, --Daniel

On Fri, Jan 31, 2025 at 10:28:42AM +0100, Libor Peltan wrote: Who's to say. I learned yesterday some people stream video over DNS :D $ dig +short TXT {0..92}.vid.demo.servfail.network | sed 's/[" ]*//g' | base64 -d | mpv - Seriously though. It is unlikely, but it's just one of those nagging things I don't want to have in the back of my mind and/or communicate if I recommend this setup to people. Keep in mind it's not so much about what I'm going to do with this, but what other people might come up with once I publish it. I'm ofc. happy to send patches if y'all are to busy to enable this niche use-case. How do you mean? I'm not aware of this behaviour, is that documented somewhere? Thanks, --Daniel

Hi Peter, I wonder how often you observe a missed NOTIFY. Knot uses TCP for sending NOTIFY and if it fails, another attempt is scheduled. Also I'm not convinced that the zone serial property can improve the situation. It just moves individual zone NOTIFYs to more frequent catalog updates and sending NOTIFYs. Have you already seen this concept in practice? Daniel On 2/1/25 11:49, Peter Thomassen via knot-dns-users wrote: