On 21 Feb 2019, at 14:34, Mark Andrews <[email protected]> wrote: > Machines die. Machines are unplugged. Server are unreachable at critical > times. Externally driven cleanup can never be reliable.
I'm not disputing any of that. I guess my first question was first whether cleanup is necessary, and second (assuming it is) whether cleanup can't just be handled as an implementation detail as opposed to a protocol extension. If the master server that receive UPDATEs matching particular names could be configured to remove them after a suitable interval, wouldn't that do the trick? Slave servers would get new copies of the zones concerned following the updates in the normal manner. Zone propagation is pretty swift with NOTIFY. The master could apply policy based on criteria like owner name pattern matching or source of the update. Garbage collection might not happen with the kind of split-second accuracy that I sense this mechanism's proponents are suggesting, but does it need to? Don't we believe that applications that expect more than loose coherence from the DNS are broken? I hear and acknowledge there is a desire for this kind functionality (i.e. I believe you that it's necessary) but I'm still not clear on what need there is for interoperability (and hence standardisation). Every DNS implementation contains their own special features that are not standardised and that don't need to be. Couldn't this be another one? I remain open to the idea that I am just missing the point because I don't spend enough time in enterprise or campus networks. I think I'm possibly not the only one in that boat, though, and I don't think it's unreasonable for the draft to explore its applicability and explain clearly why standardisation or in-zone signalling (hence RRs) is necessary as a prerequisite to standardisation. As I mentioned before, the bar for experimental is surely much lower, and the bar for simple codepoint assignment lower still. Joe _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
