Implement delegation update as complete replacement rather than diff

[johanix]

The current diff based logic has the drawback that if child for some reason gets out of sync with parent it will not recover automatically. On the other hand it is sort of, perhaps, "safer" because it only adds and deletes individual RRs, never deletes a complete RRset.

By comparision, a wholesale replace is much "simpler": drop what you have, use this instead...

We should, at least as an alternative, implemented a complete replacement strategy. I.e. when the delegation data has changed we should send an update that contains:
DEL child.parent. NS RRset
DEL all known glue that was in use for the old NS RRset
for each RR in new child.parent. NS RRset:
ADD new child.parent. NS RR
for each in-bailiwick NS in new NS RRset:
ADD any address RRs

Also, it is important to remember that when deleting in-bailiwick glue RRs in the parent, it is necessary to verify that those glue RRs are not needed for any other delegation. That check can only be made by the parent, so perhaps an even simpler UPDATE would be:

• DEL old NS RRset (should trigger the parent to delete the old NS RRset plus all associated glue)
• ADD new NS RRset
• ADD new in-bailiwick address RRs

The parent should examine the entire update to make a decision:

• Only allow the DEL NS RRset if there are enough subsequent ADD NS RR.
• Only delete old glue if it is not in use by any other child (i.e. what ISC calls "sibling glue").

[ljliman]

[I get these ... and sometimes I read them. 😉 I wonder what happens if I just reply to this message?] ***@***.*** 2024-09-23 01:05 [-0700]:

... Also, it is important to remember that when deleting in-bailiwick glue RRs in the parent, it is necessary to verify that those glue RRs are not needed for any *other* delegation. ...

I would argue that this case can be ignored. Either the glue is in-bailiwick, in which case it can be safely deleted; or it's not in-bailiwick, in which case it shouldn't be considered at all (a.k.a. "someone else's problem"). There is the strange corner case where A is delegated to ns.B, and B is delegated to ns.A (cross-delegation) and variants thereof, but I'd argue that that's just broken intent which the automator should be allowed to disregard. That setup is kind of "designed (by the customer) to break". If they _really_ want to use that setup, for some ungodly reason*, it's fair to say that they have to keep track of that themselves, and perform carefully designed DNS transactions accordingly. Cheers, /Liman * ungodly reaon, other than two tall travelling twits who would naturally "just do this" to annoy people and stresstest the systems. 😉