On Apr 6, 2014, at 20:52, Paul Hoffman <[email protected]> wrote:
> That does not make the document "impossible to implement", it makes it > unreliable when the child's nameserver is anycast. That's why the document > says not to do that in Section 2.2.1 My comment wasn’t that the “document was impossible to implement” but that with the advent of any cast one can never query all of the name servers (from one location). > Again: isn't your concern covered by the four steps in Section 2.2.1? As far as the SOA and NS, that is a good approximation, but it doesn’t cover the A and AAAA records that could be elsewhere. It is not that this stuff can’t work. It’s that ideas like this (adding to the DNS protocol’s management toolset) are only ever approximations that run the risk of adding complications when things don’t go well. The alternative is another protocol for this, and I expect a blank stare in return to the comment. So in the mean time, I just want to call out the rough edges of these proposals. 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. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
