[CWG-Stewardship] NTIA's Role in Root Zone Management

David Conrad david.conrad at icann.org
Mon Jan 19 20:45:28 UTC 2015


Chuck,

> For Verisign, that accountability has led to an excellent operational record
> of 17 years of uninterrupted uptime for .COM.

The effect does not appear to necessarily follow from the cause you claim.
For example, I believe Verisign is on record as having concerns with the
accountability of the root server system, yet the root has had significantly
longer than 17 years of uninterrupted uptime.  Similarly, .ARPA and its
sub-zones, or even .INT which, as you are aware, are run by the body you
claim to be unaccountable, all have uninterrupted uptimes I believe (but
haven't verified) longer than 17 years.

So perhaps the accountability associated with being a US-based for-profit
corporation isn't necessarily the only factor in ensuring uptime of DNS
zones (which, if you ask most DNS operations folk, given the design of the
DNS and use of anycast, isn't all that hard assuming sufficient resources
can be thrown at the problem).

> What stops an ICANN employee from going 'stark raving mad©ö

Pretty much the same that would stop a Verisign employee from going stark
raving mad: they'd (presumably) be fired.  Or are you suggesting something
about being a for-profit as opposed to a not-for-profit company disallows
stark raving madness in its employees?

However, even if an ICANN employee did go stark raving mad and was able to
bypass the numerous internal controls that would block inappropriate action
(the "insider threat" scenario), the result of that madness would (in this
context) be the submission of a request to the Root Zone Maintainer
(currently in parallel to the Root Zone Administrator) to make a
modification to the root zone. Since ICANN does not have access to the root
zone that is published to the root servers, that would be the sum total of
the result of the madness. The separation of functionality between the IANA
Function Operator and the Root Zone Maintainer, similar to the two-key
systems in US missile silos, reduces the likelihood that catastrophic events
would occur.

Well, it would, except the Root Zone Maintainer, if they went stark raving
mad, can _unilaterally_ make any change they choose because they edit AND
distribute the signed root zone to the Root Server Operators with no
mechanism in place for a third party to verify that the change made by the
Root Zone Maintainer matches the change that was requested by the IANA
Function Operator before publication.

And, in fact, if I recall correctly, such an event did occur back around
2004, albeit not as a result of stark raving madness, but rather when a bug
in Verisign's root zone management software caused an unanticipated change
in glue records for zones operated by AFNIC (detected by at least one ccTLD
manager after the root zone had been published IIRC). Of course Verisign
assures us the bug has been fixed (AFAIK, the code Verisign uses, as opposed
to code ICANN uses, is not open source so it is difficult to independently
verify, but given lack of reoccurrence in the intervening decade+, I think
it safe to assume the bug has been eradicated) and has indicated that
internal processes (AFAIK, undocumented but I'll admit not having looked for
documentation on Verisign's Root Zone Maintainer processes ¡ª are those
processes published anywhere?) are now in place to prevent a similar mistake
from occurring, however that does not change the fundamental truth that the
Root Zone Maintainer is the only entity that currently can unilaterally make
a change to the root zone.

There is nothing in the architecture of the DNS or the root system that
requires the process to be this way.  As a straw man, one potential
alternative model would be:
1. The proposed root zone changes submitted by TLD managers get publicly
posted by the IANA Function Operator after validation.
2. The Root Zone Maintainer fetches the proposed change, applies the change
to the root zone, signs the zone (thereby disallowing further change), and
publicly posts the new zone.
3. The IANA Function Operator fetches the new zone, verifies the change
implemented matches the change requested and distributes the zone to the
Root Server Operator. If the change implemented doesn't match the change
requested, you go back to step 1.

This model (one with myriad variations) provides true two-party controls,
regardless of who the IANA Function Operator and Root Zone Maintainer are.
If a model like this had been in place back in 2004, there would have been a
chance that the AFNIC mistake would have been caught before the incorrect
glue had be published to the global DNS by Verisign. This, of course,
shouldn't be taken as criticism of Verisign ¡ª bugs, like stark raving
madness, happen. This is merely an observation that the current multi-party
root zone management process may not be providing the level of
accountability people assume it does, regardless of the for-profit or
not-for-profit status of the implementers.

(I'll note in passing that if there a delay is inserted between steps 1 and
2 or between step 2 and 3, an appeal/injunction mechanism could
(potentially) be applied. I have no opinion on whether this would be a good
idea or not.)

In all the discussions I've seen on the transition of the stewardship of the
IANA Functions contract related to the Root Zone Management function, there
has been precious little discussion of the actual root zone management
processes despite the fact that, given NTIA will no longer be involved,
those processes MUST change and those changes will have DIRECT operational
impact on the Internet. I'll admit to a bit of surprise about this.

> or a post-transition ICANN from going Œstark-raving-greedy©ö?

I'll admit to not following the ICANN Accountability stuff all that closely
¡ª I'm just a technical person (or try to be) so much of that discussion is
beyond me. However, my understanding (which is probably wrong) is that
ultimately, Verisign, being a for-profit company incorporated in a state
that is (perhaps unfairly) known to have the least stringent corporate
responsibility requirements, has a fiduciary responsibility to its
shareholders to make a profit. ICANN, being a California public benefit
not-for-profit, has a fiduciary responsibility to serve the public interest
as interpreted by the State of California. While a for-profit like Verisign
being "stark-raving-greedy" is arguably appropriate (at least according to
the laws of the state of Delaware), I have some skepticism that State of
California would see an ICANN that was "stark-raving-greedy" as being in the
public interest.

And, of course, that is ignoring other accountability mechanisms already in
place at ICANN and whatever additional accountability mechanisms are put in
place as a result of the transition.

But I'm confused: my understanding, which is apparently flawed, was that the
CCWG (not the CWG) is focused on improving the accountability of ICANN to
the communities it serves and I wasn't actually asking about corporate
accountability, I was asking about the accountability of the root zone
process.

Regards,
-drc
(ICANN CTO, but speaking only for myself)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150119/5fb4b713/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4673 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150119/5fb4b713/smime.p7s>


More information about the CWG-Stewardship mailing list