[dns-operations] .RU zone failed ZSK rotation

2024-01-30 Thread Sergey Myasoedov


https://dnsviz.net/d/ru/ZbjruA/dnssec/
https://dnsviz.net/d/ru/ZbkVXw/dnssec/

And there is about 1hr outage by now


--
Sergey
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations


Re: [dns-operations] [Ext] Re: Contingency plans for the next Root KSK Ceremony

2020-03-26 Thread Sergey Myasoedov

There is no specific concern. Any KSK operation can be performed without the 
physical 
TCRs presence. There is no other source of confidence except TCRs, and their 
absence 
or accessing the private key without their presence isn’t good for trust.

I understand the extraordinariness of the moment, and if you have no choice, 
you’ll jump to 
Option 2 and Option 3 then. Is the disaster recovery procedure (Option 3) the 
one that should’ve 
been done on Verisign’s disaster recovery site? Does it require to access the 
cards? Or we’re 
discussing the non-disaster remote ceremony?


--
Kind regards,
Sergey Myasoedov


> On 26 Mar 2020, at 23:21, Kim Davies  wrote:
> 
> Quoting Sergey Myasoedov on Thursday March 26, 2020:
>> 
>>> • Using 3 TCRs’ credentials, either by having their access key 
>>> transferred to us in a secure manner in advance of the ceremony, or by 
>>> drilling the safety deposit box that holds their secure elements.
>> 
>> Accessing the credentials without the TCRs present will shatter confidence 
>> in TCR model. Better avoid that.
> 
> It would be good to better understand this concern, because we are
> facing scenarios where we may not have a choice but to do it in this
> manner. What is your specific concerns about the lack of physical TCR
> participation, and what would be the best way to remediate them? 
> 
> Bear in mind our goal is to continue to involve TCRs remotely in an
> active role as much as possible, much in the same way they would
> participate in a regular ceremony. They would oversee custody of their
> credential, along with having the opportunity to interject and advise
> along the way.
> 
> kim


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations


Re: [dns-operations] Contingency plans for the next Root KSK Ceremony

2020-03-26 Thread Sergey Myasoedov

>   • Using 3 TCRs’ credentials, either by having their access key 
> transferred to us in a secure manner in advance of the ceremony, or by 
> drilling the safety deposit box that holds their secure elements.

Accessing the credentials without the TCRs present will shatter confidence in 
TCR model. Better avoid that.


--
Kind regards,
Sergey Myasoedov

> On 26 Mar 2020, at 02:52, Kim Davies  wrote:
> 
> Colleagues,
>  
> The IANA team, and the broader ICANN organization, have been giving 
> significant thought to the Coronavirus pandemic and its impact on root zone 
> KSK operations. Managing the KSK is centred on conducting "key signing 
> ceremonies", where trusted community representatives (TCRs) attend from 
> around the world to witness utilization of the root zone KSK private key. 
> This approach seeks to engender trust in the broader community that the key 
> has not been compromised, in addition to more typical controls such as 
> third-party auditing.
>  
> In light of world events we have developed contingency plans around how to 
> hold key ceremonies in the short term. To that end, we identified a graduated 
> set of options, in summary:
>   • Hold the next ceremony as planned on April 23, with a quorum of 
> participants globally.
>   • Hold the next ceremony on a different date using only US-based TCRs.
>   • Hold the next ceremony using our disaster recovery procedure, which 
> provides for a staff-only ceremony (i.e. no TCRs would be physically present).
> In general, our goal has been to navigate from Option 1, and if that is not 
> possible, Option 2, and so on. However, at this time, our focus is on 
> developing a plan around Option 3.
>  
> The ceremony is currently scheduled unusually early in the quarter (it is 
> typically held in May), and needs to be held to generate signatures that will 
> be needed in production for July. Our contingency plan is comprised of:
>  
>   • Holding the ceremony with a bare minimum of staff (approximately 6);
>   • Using 3 TCRs’ credentials, either by having their access key 
> transferred to us in a secure manner in advance of the ceremony, or by 
> drilling the safety deposit box that holds their secure elements.
>   • Holding the ceremony under typical audit coverage, allowing for 
> remote witnessing of events by all, plus providing additional opportunities 
> for TCRs to stay involved in the process remotely.
>   • Signing key materials to cover one or more subsequent quarters, to 
> provide relief from the need to necessarily hold ceremonies later in 2020 if 
> circumstances disallow it. (The additional signatures would be withheld 
> securely until they are needed.)
> Our key management facilities were designed with the disaster recovery 
> capability of performing staff-only ceremonies in mind, but this is a 
> significant shift from normal operations and we want to promote broader 
> community awareness of this work. Those directly involved in key ceremonies - 
> the trusted community representatives, our vendors and auditors - have been 
> consulted and are broadly supportive of this effort.
>  
> Should there be any specific feedback you would like to share with our team, 
> please let me know or respond to this thread. We will take it into 
> consideration as we finalize our plans.
> Thank you for your support,
>  
>  
> Kim Davies
> VP, IANA Services, ICANN
> President, Public Technical Identifiers (PTI)
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations


Re: [dns-operations] any registries require DNSKEY not DS?

2020-01-22 Thread Sergey Myasoedov

I think .ru/.рф were requiring DNSKEY together with DS to publish the DS. Or 
maybe the registrars were performing additional checks if the DS correspond to 
DNSKEY.


--
Sergey

> On 22 Jan 2020, at 23:13, Tony Finch  wrote:
> 
> Are there any registries that configure secure delegations from DNSKEY
> records (and do their own conversion to DS records) rather than accepting
> DS records from the registrant? I think I have heard that .de is one.
> Looking at OpenSRS as an example of a registrar that supports lots of
> TLDs, I see that they don't support DNSSEC for .de
> http://opensrs.help/chart and their API only supports DS records
> https://domains.opensrs.guide/docs/set_dnssec_info
> 
> Also, I am uncomfortable with the endianness of their support domain names...
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> responsible stewardship of the earth and its resources
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations