> On Dec 15, 2017, at 10:48 AM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > >> While it's conceptually elegant to have this mechanism easily available to >> the operator of nameservers for any zone, it's not clear to me that this is >> supported by a tangible use case. > > A TLD operator who doesn't really like the fact that ICANN and Verisign > control the contents of the root zone declares that their KSK has tag 12321 > and will have that tag until further notice. They suggest that everyone who > wants to trust them should install their current KSK as a trust anchor > because who knows what evil or incompetent thing ICANN and Verisign will do > in the future. A user wants to see if their resolver operator has done so. > > (I wish this was far-fetched. Since starting to work for ICANN, I have been > told **by people on this list** that this could happen for their TLDs.)
Even if someone says "this could happen for their TLD", I think the sentiment is really "they fear that this could happen for their TLD". And people are afraid of a lot of things that have an extremely low probability of occurring, which is the territory we're in when it comes to fearing that ICANN would do something "evil or incompetent" with the root zone. Since I've been at ICANN, I've been impressed with the extent to which the community's wishes drive what the organization does, and since the IANA transition, there are no actors besides the ICANN community to influence root zone management. As for Verisign, they are ICANN's contractor for root zone management, so they are prohibited by contract from doing anything evil, and Verisign's competence when it comes to root zone management is not a thing I worry about. So having been on the inside of both ICANN and Verisign, I can state without hesitation that concern about evil or incompetence regarding root zone policy and management should be low on everyone's list. Matt P.S. Though this message is in reply to Paul, he knows all of this and I'm stating it for the record. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
