[ksk-rollover] 答复: Architectural reconsideration on ICANN's Root Zone KSK rollover

[Robert Story]

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/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20180131/762b718f/attachment.sig>