On Wed 2018-01-31 10:55:53+0800 Davey wrote:
So I'm inspired that it is not necessary for additional set of root server and coordination between server and resolver for this purpose. All the work can be done in server side.
This is true.
It can be implemented on server side with "two logic views"(similar but different from BIND multiple view mechanism. When authoritative server recognize the resolvers who support RFC5011 (via rfc8145 or combined with kskroll-sentinel), it can roll the key only for them. Roll KSK not once for all but per-resolver. In that case there is no need any modification on resolver. Root server operator should do this work only. So there is no interoperability problem. No specification of DNS is needed which shorten the time and concerns.
There is still risk in this. Many end users are behind NATs. This means that some queries from an IP can signal that it is using the new key, while others could signal it is not. Instead of making this some sort of automatic process, it could be entirely opt-in if root-servers configured views based on destination address and simply listened on an additional anycast address. But this still leaves the problem of how to advertise the new address, and wouldn't deal with the problem of resolvers which switched to the new address even though they weren't configured to trust the new keys. If we could convince the resolver implementations to ship with multiple hints files, and to selected on at startup based on configured trust anchors, we could see the traffic shift are resolvers were updated. -- Robert Story <http://www.isi.edu/~rstory> USC Information Sciences Institute <http://www.isi.edu/>