[governance] "Oversight"

David Conrad drc at virtualized.org
Mon Jun 4 12:00:10 EDT 2012


Parminder,

Apologies for the deep dive in the minutiae of root zone management, but I think clarity here is important.

On Jun 4, 2012, at 3:05 AM, parminder wrote:
> For those who have been arguing that ICANN cannot remove individual websites, that might be true, but they can remove complete domain names, like cctlds, isnt it.

No, ICANN, acting unilaterally, cannot.  

ICANN, acting as the IANA Functions Manager under contract to the US Government, can at the direction of the administrators for the top-level domain in question _make a request_ to have that top-level domain removed.  That request (once validated by IANA staff) is sent to the US Dept. of Commerce NTIA for approval to ensure that existing policies and processes were followed, and when approved that request is forwarded to Verisign as the Root Zone Manager for that TLD's entry in the root zone to be deleted.  At that point, the modified zone file is DNSSEC-signed (by the Root Zone Manager with a key that is held by (handwave) the IANA Functions Manager) and pushed to the 13 root servers that will make the modified root zone available to the Internet.

> On the other hand, I am not completely sure what is the impact of the recent securitisation of the DNS/root zone with regard to possible domain seizures and other interferences, but I suspect that there are indeed some important implications of it.

There is no impact of DNSSEC-signing the root to domain name seizures.

The only thing DNSSEC-signing the root zone does is ensure that an attempt by someone who doesn't hold the root zone's private key to modify a response from a root server can be detected.  Responses from the root servers are (almost always) referrals to top-level domain name servers (that is, the root servers when asked 'what's the address for "foo.example.com"' respond with "don't know, but ask the name servers for .COM and here is a list of those name servers").  DNSSEC allows validating resolvers (typically operated by ISPs) to verify that no one has tried to insert bogus data in that referral.

An implication of this is that if the existing processes were somehow subverted and the Root Zone Manager (Verisign, _not_ ICANN) were able to insert something inappropriate into the root zone, the root server operators (a quarter of which are not based in the US and with one exception are under no contractual obligation to do anything) would be forced to make a decision: publish the "secure" root zone with the inappropriate data or refuse to publish the entire zone.  If such a subversion were to take place, I suspect a majority of root server operators (yes, even many of those in the US) would choose the latter with consequences so unappealing as to be comparable with Mutual Assured Destruction doctrine.

The point here is that no single party involved in root management, the TLD administrators, ICANN, NTIA, Verisign, or the root server operators, is able to unilaterally "remove complete domain names" and any attempt to do so would be "bad".

Regards,
-drc

P.S. I have argued that the current root zone management process has a flaw in that the publication of the root zone should not be done by the Root Zone Manager, rather it should be done by (or at least vetted by) the IANA Functions Manager to ensure the requested change was done correctly before it hits the root servers.  Haven't gotten much traction as some folks feel it would add yet another step in an already too Byzantine a process for something as simple as modifying a zone file.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.igcaucus.org/pipermail/governance/attachments/20120604/182650e2/attachment.htm>
-------------- next part --------------
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.igcaucus.org
To be removed from the list, visit:
     http://www.igcaucus.org/unsubscribing

For all other list information and functions, see:
     http://lists.igcaucus.org/info/governance
To edit your profile and to find the IGC's charter, see:
     http://www.igcaucus.org/

Translate this email: http://translate.google.com/translate_t


More information about the Governance mailing list