[RZERC] Recommendations Regarding Signing Root Zone Name Server Data

[Wessels, Duane]

Hi Peter,

> On Dec 15, 2020, at 11:30 AM, Peter Koch <pk at DENIC.DE> wrote:
> 
> Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 
> 
> On Mon, Nov 30, 2020 at 04:46:02PM +0000, Wessels, Duane via RZERC wrote:
>> Since our November meeting was canceled, I wanted to have a discussion on the list about our draft "Recommendations Regarding Signing Root Zone Name Server Data" document.
>> 
>> During October meeting the discussion was around these three topics:
>> 
>> 1) Concerns on how the proposed research and the recommendations that follow could possibly impact TLDs and lower levels of the DNS in a trickle-down aspect.  An earlier version of our document included a recommendation to consider this, but we have since agreed to remove it.  Is this issue still a concern for commitee members, and if so can someone proposed text?
> 
> It is a concern because it claims that the root is 'special' and I couldn't
> explain why this should be the case w.r.t. signing the 'delegation'.  Not
> signing the delegation was a feature, not an oversight.

It sounds like this is still a concern of yours even after the removal of the recommendation?

I'm not sure that our document makes a claim that the root zone is special.  If I correctly understood what our GNSO representative says, there is now already a requirement for new gTLDs to have signed name server data.  It wasn't always that way, but this requirement was added at some point. I tried spending a little time going through the applicant guidebook to see if I could find the requirement, but I was not successful.

For what it's worth, I don't think of this as "signing the delegation" but rather as adding signatures to the authoritative data of the name server names and addresses.  

If not signing the delegation is truly considered a feature, is there something we can reference to support that?



> 
>> 2) What's the point of RZERC doing this when our recommendations are in some sense redundant with the recommendations from RSSAC028 of three years ago?  As I mentioned, during my conversations with ICANN OCTO staff they said that RZERC's input would be helpful.  Do we still have agreement to move forward with this as RZERC advice to the Board?
> 
> I am still not sure I understand RZERC's role in this, given that RSSAC already
> has a mandate to give advice to the Board.  RZERC could of course observe that RSSAC 028
> hasn't seen any followup, but maybe we can discuss why exactly an intervention by
> RZERC would be 'helpful' - or maybe more helpful than RSSAC getting back to the Board
> and asking for an update on the recognition of their previous advice.

To that point the best answer(s) I can give you are:

- The RZM representative (myself) initially brought this before RZERC, although with a slightly different focus, the committee agreed to take it on, spent some months discussing and refocusing it.  This is captured in the Introduction paragraph of the draft:

    During RZERCs May 2020 teleconference, the Root Zone Maintainer (RZM)
    representative presented a proposal to sign the authoritative root
    zone name server data, as contained in the root-servers.net zone.  The
    RZERC agreed that the topic falls within its charter remit since it
    would involve a significant change to root zone provisioning.  The
    RZERC discussed the topic at its regular meetings and came to consensus
    that it needs further study.  This document states the RZERCs position
    and recommendations on this matter.

- I have spoken with Matt Larson of ICANN OCTO and he conveyed to me that a document from RZERC on this topic would be helpful, although not strictly necessary from what I understand.


> In that case, RZERC could or could not pose the 'research questions' for the
> proposed studies to work on.  Who would receive and assess the results of those studies?

I would guess that to be RSSAC, RZERC, and the ICANN board.

DW


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4695 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/rzerc/attachments/20210108/60ffbe45/smime.p7s>