Hello Aanchal, I don't know if you consider this a solution, but you may want to take a look at RFC 8145, aka "Signaling Trust Anchor Knowledge."
Per this RFC, validators can convey trust anchor contents to zone operators via periodic queries. By looking at the signal data you can see how many (and which) validators have old versus new keys. It is implemented in recent versions of BIND and Unbound. DW > On Aug 3, 2017, at 8:50 AM, Aanchal Malhotra <aanch...@bu.edu> wrote: > > Dear all, > > May be this has been discussed long ago on the list or elsewhere. Please > guide me to proper pointers, if any. > > Section 11.2.1 in [1] states the following for KSK rollover for locally > secure zones: > > "In rolling over the KSK, the secure zone may not know which resolvers have > stored the public key as a trust anchor. If the network administrator has an > out-of-band method of contacting resolver administrators that have stored the > public key as a trust anchor (such as e-mail), the network administrator > should send out appropriate warnings and set up a trusted means of > disseminating the new trust anchor. Otherwise, the DNS administrator can do > nothing except pre-publish the new KSK with ample time to give resolver > administrators enough time to learn the new KSK." > > I have the following questions: > > a) This might work in case of an active KSK rollover. However in case of KSK > compromise, which would require an emergency KSK rollover, what does the > network administrator do in the 'Otherwise' situation from the above quote? > > b) I am just curious to know if this is even an issue or do network > administrators care about it? And if it is, Is there any RFC or relevant doc > or mailing list that discusses this problem/solutions, etc.? > > References: > [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf > > Thanks, > Aanchal Malhotra. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
