On Aug 23, 2018, at 9:23 PM, Paul Vixie <p...@redbarn.org> wrote: > http://family.redbarn.org/~vixie/defupd.txt > <http://family.redbarn.org/~vixie/defupd.txt> > > the IETF DNSIND WG rejected this draft on the basis of its complexity. the > idea of a zone having timers inside it, for self-modification, was just a > bridge too far at that time. given what is now called "the camel" i think > pendulum has swung _well_ away from that point of view, but is now in the > process of swinging back. if i had hope, i would submit DEFUPD again, exactly > as it was in 1996, because it still deftly threads the needle posed by > UPDATE. your needs may differ.
I think that defupd is the core of a good idea, but it's more complicated than it needs to be. Another way to accomplish the same thing would be to have an RR that just contains an update and a time when the update is to be done, hanging off of the name to be updated. This could be included in the DNS update that creates the record, or created automatically by the server based on the update lease EDNS(0) option. IOW I don't think there's any need for a new DEFUPD opcode, but the idea otherwise ought to be considered alongside Tom's proposal to see which one we think is easier to specify and implement.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
