Shane Kerr <shane@time-travellers.org> writes:
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.
I'm confused about whether you're asking about the internal documentation about a particular operator (many (most?) operators of any networks don't like advertising their exact internal architectures for security-through-obscurity related reasons, which we shouldn't argue about here), or are you asking about the root zone distribution system, which is how IANA/ICANN/Versign/and-the-roots get data changes propagated through the system. This last system is fairly well documented publicly I think, no? I would need to go search for the document that describes it, but I'm sure there is one (including how zone changes are reviewed, etc).
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'd love to hear an example problem where you don't know of whether something is broken or not based on some external test.
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-o...
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.
I think the paragraph is trying to say "the candidate MUST have address space before coming an operator" not "before getting approved to be one". But it could probably be made more clear?
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.
There is certainly a large amount of debate to be had about how much diversity is a good thing. Single points of failure are known to be bad, and it would be bad if everyone ran the exact same version of bind (eg) and FreeBSD (eg). But too much diversity leads to more points of failure, which I suppose could be bad. Though if the system could lose X% of it's deployed infrastructure without visibly affecting the service itself, then high diversity is likely to be helpful since it's unlikely that the entire system could go down if the diversity ensured it would take multiple vulnerabilities to pass the X% threshold. -- Wes Hardaker USC/ISI