Paul Hoffman <[email protected]> writes: >> The document does do a good job of handling as many as it can, but >> there’s still the underlying limitations of one-way-only message >> passing. The only way this will work (in the sense of scale and >> stability over time) is if the parental agent gets notified reliably >> to check and the child’s (agent?) stays on the ball until the action >> is completed. > > That is a good summary; maybe it should be added to the end of Section > 1.
Ed/Paul, Sorry for the delay in getting back to you. A number of non-work emergencies came up I had to deal with first. Anyway, I think maybe the right thing to do is add text saying that the parental agent may wish to offer another configuration entry to specify which master agent to poll when checking. IE, rather than pulling a random NS, actually allow for a directed master that isn't anycast or is potentially even a hidden master. This would take care of much of this concern, no? And this is already in the text: Parental agents MAY offer a configuration interface to allow child operators to specify which nameserver should be considered the master to send data queries too. This master may not be one of the publically listed nameservers in the NS set (i.e., it may be a "hidden master"). And I'll add the following paragraph below this as well: Parental agents MAY offer a programmatic interface to let children indicate that new CSYNC records and data are available for polling. The problem, of course, is that the whole reason for this solution instead of an update push is that the whole "who do you talk" to problem comes about. So, your notion of "the parental agent gets notified reliably" is super-difficult to implement in today's deployed world. I agree, that CSYNC isn't ideal, but it's the best choice we have in today's environment. -- Wes Hardaker Parsons _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
