Hi,
(800-81 author here)
That needs to be updated as it was from the earlier revision of 800-81.
It really should stress the use of RFC 5011 automated trust anchor
update process. The first version of the doc assumed RFC 5011 was not
available in the majority of implementations, which is not the case now.
I’d probably update that to recommend (and stress) to always use the
RFC 5011 rollover process.
As for emergency rollovers, some admins do worry about it and plan for
it by having a pre-published KSK in the DNSKEY RRset at all times (not
just during an actual rollover process). RFC 5011 can be used there too
(see the “Scenarios” section in RFC 5011). There isn’t a single
doc that focuses on KSK rollovers, but it is discussed in the BCP docs
like RFC 6781 and other implementation-specific documents.
Scott
On 3 Aug 2017, at 11:50, Aanchal Malhotra 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]
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf>
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
===================================
Scott Rose
NIST ITL
scott.r...@nist.gov
+1-301-975-8439
GV: +1-571-249-3671
===================================
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
