[rssac-caucus] FOR REVIEW: Elements of Potential Root Operators

[Shane Kerr]

Andrew,

At 2016-09-06 20:42:07 +0000
Andrew Mcconachie <andrew.mcconachie at icann.org> wrote:
 
> The work party invites you to review this document and provide your
> feedback by close of business 4 October 2016.
> 
> Feedback should be sent to the RSSAC Caucus list directly.

Interesting document. A bit strange but basically reasonable.

----

One thing that I would like to see is a request that all of the
information in this document be public. For example, descriptions of
zone distribution architecture. As someone without access to this for
current root server operators I have to infer this - I often don't
know whether something is broken in the root server system or whether
they are merely acting in ways that I didn't expect because I don't
know what's going on "under the hood".

I realize that this may be out of scope for a technical requirements
document, but on the other hand having details available for wider
review can result in higher quality service, so I can possibly justify
it in a hand-waving way. ;)

----

One minor point about addressing:

    3.3.3 Addressing Resources
    
    The candidate operator MUST have its own AS number(s) and IPv4 and
    IPv6 address allocations. It is assumed that IP anycast will be
    used. If IP anycast will not be used, a technology providing
    similar or better service levels SHOULD be specified. Provider
    address space or addresses that cannot be used with anycast are
    undesirable. The expected production IPv4 and IPv6 address blocks
    MUST be severable from the candidate’s organization to facilitate
    emergency or planned transfers.

Some RIRs have policies to allocate addresses for "critical use":

https://www.nro.net/rir-comparative-policy-overview/rir-comparative-policy-overview-2016-02#2-4-2

This means that potential root server operators probably do not need to
have address space in advance of being approved for being a root server
operator.

----

In the section on diversity (3.4), I am a little confused. The
introduction states: 

    Diversity _within_ a given operator is of benefit, but the candidate
    will also be evaluated in terms of increased diversity among operators.

But within each sub-section it is not at all clear which are intended
to apply for a specific operator and which are intended to be used to
analyze the root server system as a whole.

My concern is that this will naturally lead to "diversity inflation"
where each root server operator runs multiple versions of everything
without any real benefit, and in fact a potential reduction in
reliability of the overall system. (For example, if many root servers
run a given DNS software to maximize diversity and there is an
unpublished exploit, then it is possible that more root servers are
compromised rather than fewer.)

Nit: Unbound is a recursive resolver and would be unlikely to be run by
a root server operator. :)

----

Nit: "triannual" is easily confused with "triennial", so probably it
should just be stated that the root server operator meetings are three
times a year. 

https://en.wiktionary.org/wiki/triannual#Usage_notes 

Cheers,

--
Shane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20160907/f059d1c4/attachment.sig>