[LAC-Discuss] FYI - Planning for Registry Failure

[Lance Hinds]

-------> [ENGLISH] AUTOMATIC TRANSLATION NOT REVISED FROM THE ORIGINAL MILTILINGUAL



By Internet Infrastructure Features Staff

Even the unthinkable is conceivable, and you have to plan for it. ICANN is
developing plans for the failure of a registry administrator.

Just because a drastic event is highly, highly unlikely is no reason to
pretend it's impossible. Consider the failure of registries, as ICANN has
begun to do.

There might have been a time when the failure of a registry seemed
far-fetched, but last year's disastrous failure of Registerfly proved that
it can happen and that customers can be affected adversely with no recourse.
Clearly something had to be done, and ICANN has begun with their Registrar
Data Escrow Program.

But what about registries? Most of the entities that administer the
top-level domains on the Internet are responsible and stable companies or
government agencies. Still, it's only prudent to have plans in place in the
event of a disaster of some sort. And suspicion earlier this year that the
operator of the .TRAVEL registry was in trouble must have given even more
currency to these concerns.

Not all such disasters can be attributed to mismanagement, as in the
Registerfly case. It's possible that in the event of natural disaster or war
a registry's infrastructure could be damaged to a significant degree. The
ICANN document "Building Towards a Comprehensive gTLD Registry Failover
Plan" discusses a number of these scenarios, from government coups to power
blackouts to malicious computer attacks.

What is a TLD, or more specifically a gTLD? A TLD is a top-level domain, the
right-most part of a domain name. The TLD for whitehouse.gov, for example,
is .gov. That domain is administered by the U.S. General Services
Administration.

Two-letter TLDs are reserved for countries, like uk for United Kingdom and
cn for China, and are known as Country Code TLDs. TLDs with three or more
letters are Generic TLDs or gTLDs . The Registry Failover Plan applies to
gTLDs, presumably because ICANN attempts to defer to national authorities in
the administration of their ccTLDs.

What does a gTLD do that would require a backup plan? This interim report on
the development of the Failover plan includes a list of critical functions
of a registry: Here are some of them.

DNS data, zone file and nameserver maintenance -The most critical service on
a day-to-day basis; the registry provides services that allow names to
resolve on the Internet.

Shared Registration System - This is software used by the registry to
facilitate the registration of domain names.
Whois Service - This is the service on port 43 that allows users to
determine who owns a domain and what its authoritative DNS is.
Registrar Billing and Accounting Information - This is the billing and
account data for registrars that operate in that TLD, not information on
individual registrants.

Data Security and Data Escrow - There are already requirements for at least
some registries to escrow their registry data, but the requirements are not
uniform and are included in each registry's agreement with ICANN. A report
prepared as part of the research for the Registry Failover plan cites
examples from VeriSign's agreement for the .com domain. Expect the
designation in the future of a default escrow agent, as in the case of Iron
Mountain , the escrow agent for registrar data. Registrars also have the
option of escrowing with another approved service; the program is new and
none have yet been approved.

IDN Tables - This is data involved in the support of International Domain
Names, meaning names not in the English language.
DNSSEC Keys - These are the public and private keys used for DNSSEC, a
secure version of DNS.

Several of these functions involve data that is extremely sensitive and
commercially valuable, such as the billing data and the DNSSEC keys.
Procedures involving the handling of such data have to be as secure as
possible.

The ICANN plans have begun to spell out who at ICANN and other bodies would
be involved in the management of trouble at a registry, up to and including
the failure of that registry and the designation of a successor body to take
over.

The technical aspects are perhaps the easy part; there is plenty of
precedent from history when TLDs were transferred from one registry operator
to another, such as when .US was transferred to Afilias and when .ORG was
transferred from VeriSign to PIR. The IANA has established procedures for
changing TLDs in the root zone.

It's the business end of the business that's tricky; registry operators have
contractual rights that must be respected to the greatest extent possible.
And the process should be designed, at every stage, to maintain confidence
in the system.

The failure of a significant registry is so unlikely that it almost makes it
not worth planning for. Almost, but not quite.

Lance Hinds
Chief Technology Officer
BrainStreet Technologies
24A Eping Avenue, Bel Air Park
Georgetown Guyana

____________________________________________________________________________
____________________________________________________________________________
_______________
This message contains information that may be privileged and/or confidential
and is the property of BrainStreet Technologies or BrainStreet Learning. The
information contained herein is intended only for the individual or entity
to whom it is addressed and others authorized to receive it . If you are not
the intended recipient, you are not authorized to read, print, retain, copy,
disseminate, distribute, or take  any action in reliance to the contents of
this information or any part thereof and it may be unlawful to do so. If you
receive this message in error, please notify the sender immediately and
delete all copies of this message from your system. BrainStreet Technologies
or BrainStreet Learning are neither liable for the proper and complete
transmission of the information contained in this communication nor any
delay in its receipt.


-----Original Message-----
From: lac-discuss-bounces at atlarge-lists.icann.org
[ mailto:lac-discuss-bounces at atlarge-lists.icann.org ] One Behalf Of
Carlos aguirre Feels: Tuesday, December 04, 2007 9:41 PM
To: lac-discuss at atlarge-lists.icann.org
Subject: Re: [LAC-Discuss] Congratulation Vanda Scartezini

Posting guidelines to ensure machine translations of emails sent to this
list are more accurate:
http://www.funredes.org/mistica/english/emec/method_emec/presentation.html#a
nexo1
- - - - -


-------> [PORTUGUESE] TRADUCAO AUTOMATICA NAO REVISADA DO ORIGINAL




Por Internet Infrastructure Caracteriza A Equipe de funcionários

Mesmo o unthinkable é concebível, e você tem que planear
para ele. ICANN está desenvolvendo plantas para a falha de um
administrador do registro.

Apenas porque um evento drástico é altamente, altamente improvável
é nenhuma razão fingi-lo é impossível. Considere a falha dos
registros, porque ICANN começou a fazer.

Pôde ter havido uma época em que a falha de um registro parecesse
far-fetched, mas a falha desastrosa do ano passado de Registerfly
provou que pode acontecer e que os clientes podem ser afetados
adversamente com nenhum recourse. Claramente algo teve que ser feito,
e ICANN começou com seu programa do escrow dos dados do registrar.

Mas que sobre registros? A maioria das entidades que administram os
domínios top-level no Internet são companhias ou agências de
governo responsáveis e estáveis. Ainda, é somente prudent ter
plantas no lugar no evento de um disastre de alguma sorte. E a
suspeita mais cedo este ano que o operador do registro do TRAVEL
estava no problema deve ter dado mesmo mais moeda corrente a estes
interesses.

Não todos tais disastres podem ser atribuídos ao mismanagement, como
no exemplo de Registerfly. É possível que no evento do disastre
natural ou guerreia infrastructure de um registro poderia ser
danificado a um grau significativo. O original "edifício de ICANN
para uma planta detalhada de Failover do registro do gTLD" discute um
número estes de scenarios, dos coups do governo para power
escurecimentos aos ataques maliciosos do computador.

Que é um TLD, ou mais especificamente um gTLD? Um TLD é um domínio
top-level, a parte right-most de um Domain Name. O TLD para
whitehouse.gov, para o exemplo, é gov. Esse domínio é administrado
pela administração geral dos serviços de ESTADOS UNIDOS.

TLDs two-letter é reserved para países, como o Reino Unido para
Reino Unido e cn para China, e é sabido como o código de país TLDs.
TLDs com três ou mais letras é TLDs genérico ou gTLDs. A planta de
Failover do registro aplica-se aos gTLDs, presumably porque ICANN
tenta adiar para autoridades nacionais na administração de seus
ccTLDs.

_ que um gTLD faç que reque um apoio plane? Este relatório de
ínterim no desenvolvimento da planta de Failover inclui uma lista de
funções críticas de um registro: Estão aqui alguma delas.

Dados do DNS, lima da zona e manutenção do nameserver - o serviço o
mais crítico em uma base cotidiana; o registro fornece os serviços
que permitem que os nomes resolvam no Internet.

Sistema compartilhado do registo - este é software usado pelo
registro facilitar o registo de nomes do domínio. Serviço do WHOIS -
este é o serviço no porto 43 que permite que os usuários determinem
quem possuem um domínio e o que seu DNS authoritative é. Faturamento
do registrar e informação de contabilidade - este é os dados para
os registrars que operam naquele TLD, não informação do faturamento
e do cliente em registrants individuais.

Segurança de dados e escrow dos dados - há já umas exigências para
ao menos alguns registros ao escrow seus dados do registro, mas as
exigências não são uniformes e são incluídas no acordo de cada
registro com ICANN. Um relatório preparado como a parte da pesquisa
para a planta de Failover do registro cites exemplos do acordo de
VeriSign para o domínio do com. Espere a designação no futuro de um
agente do escrow do defeito, como na caixa da montanha do ferro, o
agente do escrow para dados do registrar. Os registrars têm também a
opção de escrowing com um outro serviço aprovado; o programa é
novo e nenhuns foram aprovados ainda.Tabelas de IDN - este é dados envolvidos na sustentação de nomes
internacionais do domínio, significando nomes não na língua
inglesa. Chaves de DNSSEC - estas são o público e as chaves
confidenciais usados para DNSSEC, uma versão segura do DNS.

Diversas destas funções envolvem os dados que são extremamente
sensíveis e comercialmente valiosos, como os dados do faturamento e
as chaves de DNSSEC. Os procedimentos que envolvem a manipulação de
tais dados têm que ser como seguros como possíveis.

As plantas de ICANN começaram a soletrar para fora de quem em ICANN e
outros corpos seriam envolvidos na gerência do problema em um
registro, até e incluindo a falha desse registro e a designação de
um corpo do sucessor fazer exame sobre.

Os aspectos técnicos são talvez a parte fácil; há uma abundância
do precedent do history quando TLDs foi transferido de um operador do
registro a outro, como quando os US foram transferidos a Afilias e
quando o ORG foi transferido de VeriSign a PIR. O IANA estabeleceu
procedimentos para mudar TLDs na zona da raiz.

É o fim do negócio do negócio que é complicado; os operadores do
registro têm as direitas contractual que devem ser respeitadas à
extensão a mais grande possível. E o processo deve ser projetado, em
cada estágio, manter a confiança no sistema.

A falha de um registro significativo é assim improvável que o faz
quase não worth planear para. Quase, mas não completamente.

Avenida Principal Das Tecnologias 24A Eping De BrainStreet Do Oficial
Da Tecnologia De Hinds Do Lance, Parque Georgetown Guyana Do Ar Do
Bel

____________________________________________________________________________

____________________________________________________________________________
_______________ Esta mensagem contem a informação que pode ser
privilegiada e/ou confidential e é a propriedade de tecnologias de
BrainStreet ou da aprendizagem de BrainStreet. A informação contida
nisto é pretendida somente para o indivíduo ou a entidade a quem é
dirigida e a outra autorizado para recebê-la. Se você não for o
receptor pretendido, você não está autorizado ler, para imprimir,
para reter, para copí, para disseminate, para distribuir, ou fazer
exame de toda a ação no reliance aos índices desta informação ou
qualquer parte disso e ele pode ser ilegal fazer assim. Se você
receber esta mensagem no erro, notifique por favor o remetente
imediatamente e suprima todas as cópias desta mensagem de seu
sistema. As tecnologias de BrainStreet ou a aprendizagem de
BrainStreet são nem responsáveis para o apropriado e a transmissão
completa da informação contida nesta comunicação nem algum atrasa
em seu recibo.


Mensagem Original De: lac-discuss-bounces at atlarge-lists.icann.org
[ mailto:lac-discuss-bounces at atlarge-lists.icann.org ] On Behalf Of
carlos aguirre Sent: Tuesday, December 04,.2007 9:41 PM
: assunto de lac-discuss at atlarge-lists.icann.org: Re: [ LAC-Discuta ]
Congratulation Vanda Scartezini

Afixando guidelines para assegurar traduções de máquina dos
email emitidos a esta lista seja mais exato:
http://www.funredes.org/mistica/english/emec/method_emec/presentation.html#a
nexo1
- - - - -


-------> [ESPAÑOL] TRADUCCIÓN AUTOMATICA NO REVISADA DEL ORIGINAL MULTILINGÜE




Por Internet Infrastructure Ofrece A Personal

Incluso el increíble es concebible, y usted tiene que planear
para él. ICANN está desarrollando los planes para la falta de un
administrador del registro.

Apenas porque un acontecimiento drástico está altamente, altamente
inverosímil no hay razón de fingirlo es imposible. Considere la
falta de registros, pues ICANN ha comenzado a hacer.

Pudo haber habido una época en que la falta de un registro se
parecía far-fetched, pero la falta desastrosa del año pasado de
Registerfly probó que puede suceder y que los clientes pueden ser
afectados al contrario sin recurso. Algo tuvo que ser hecho
claramente, e ICANN ha comenzado con su programa del Fideicomiso de los
datos del secretario.

¿Pero qué sobre registros? La mayoría de las entidades que
administran los dominios a nivel superior en el Internet son
compañías o agencias de estatal responsables y estables. No
obstante, es solamente prudente tener planes en lugar en el
acontecimiento de un desastre de una cierta clase. Y la suspicacia
este año que el operador del registro del TRAVEL estaba en apuro debe
haber dado anterior aún más modernidad a estas preocupaciones.

No todos tales desastres se pueden atribuir a la mala gestión, como
en el caso de Registerfly. Es posible que en el acontecimiento del
desastre natural o guerrea la infraestructura de un registro podría
ser dañado a un grado significativo. El documento "edificio de ICANN
hacia un plan comprensivo de Failover del registro del gTLD" discute
un número de estos panoramas, de golpes del gobierno para
accionar apagones a los ataques malévolos de la computadora.

¿Cuál es un TLD, o más específicamente un gTLD? Un TLD es un
dominio a nivel superior, la parte de derecha de un Domain Name. El
TLD para whitehouse.gov, por ejemplo, es gov. Ese dominio es
administrado por la administración general de los servicios de
ESTADOS UNIDOS.

TLDs two-letter es reservado para los países, como Reino Unido para
Reino Unido y el cn para China, y se conoce como código de país
TLDs. TLDs con tres o más letras es TLDs genérico o gTLDs. El plan
de Failover del registro se aplica a los gTLDs, probablemente porque
ICANN procura diferir a las autoridades nacionales en la
administración de sus ccTLDs.

¿_ qué uno gTLD hacer que requerir uno reserva planear? Este informe
provisional sobre el desarrollo del plan de Failover incluye una lista
de funciones críticas de un registro: Aquí están algunas de ellas.

Datos del DNS, archivo y mantenimiento del nameserver - el servicio
más crítico de la zona sobre una base cotidiana; el registro
proporciona los servicios que permiten que los nombres resuelvan en el
Internet.

Sistema compartido del registro - éste es software usado por el
registro para facilitar el registro de los nombres del dominio.
Servicio del WHOIS - éste es el servicio en el puerto 43 que permite
que los usuarios se determinen quién posee un dominio y cuál es su
DNS autoritario. Facturación del secretario e información de
contabilidad - éste es los datos para los secretarios que funcionan
en ése TLD, no información de la facturación y de la cuenta sobre
registrants individuales.

Seguridad de datos y Fideicomiso de los datos - hay ya requisitos para
por lo menos algunos registros al fideicomiso sus datos del registro,
pero los requisitos no son uniformes y se incluyen en el acuerdo de
cada registro con ICANN. Un informe se preparó como parte de la
investigación para el plan de Failover del registro cita ejemplos del
acuerdo de VeriSign para el dominio del com. Cuente con la
designación en el futuro de un agente del fideicomiso del defecto,
como en la caja de montaña del hierro, el agente del fideicomiso para
los datos del secretario. Los secretarios también tienen la opción
de escrowing con otro servicio aprobado; el programa es nuevo y no se
ha aprobado ningunos todavía.Tablas de IDN - éste es datos implicados en la ayuda de los nombres
internacionales del dominio, significando nombres no en la lengua
inglesa. Llaves de DNSSEC - éstas son el público y las llaves
privadas usados para DNSSEC, una versión segura del DNS.

Varias de estas funciones implican los datos que son extremadamente
sensibles y comercialmente valiosos, por ejemplo los datos de la
facturación y las llaves de DNSSEC. Los procedimientos que implican
la dirección de tales datos tienen que estar como seguros como sea
posible.

Los planes de ICANN han comenzado a explicar hasta quién en ICANN y
estarían implicados otros cuerpos en la gerencia del apuro en un
registro, e incluyendo la falta de ese registro y la designación de
un cuerpo del sucesor de asumir el control.

Los aspectos técnicos son quizás la parte fácil; hay un montón de
precedente de la historia cuando TLDs fue transferido a partir de un
operador del registro a otro, por ejemplo cuando los US fueron
transferidos a Afilias y cuando el ORG fue transferido de VeriSign a
PIR. El IANA ha establecido los procedimientos para cambiar TLDs en la
zona de la raíz.

Es el final del negocio del negocio que es difícil; los operadores
del registro tienen derechas contractuales que se deban respetar al
grado más grande posible. Y el proceso se debe diseñar, en cada
etapa, para mantener confianza en el sistema.

La falta de un registro significativo es tan inverosímil que casi lo
hace no digno de planear para. Casi, pero no absolutamente.

Avenida De las Tecnologías 24A Eping De BrainStreet Del Oficial De
la Tecnología De Hinds De la Lanza Principal, Parque Georgetown
Guyana Del Aire Del Belio

____________________________________________________________________________

____________________________________________________________________________
_______________ Este mensaje contiene la información que puede ser
privilegiada y/o confidencial y es la característica de las
tecnologías de BrainStreet o de aprender de BrainStreet. La
información contenida adjunto se piensa solamente para el individuo o
la entidad a quienes se trata y las otras autorizada para recibirla.
Si usted no es el recipiente previsto, le no autorizan a leer,
imprimir, conservar, copiar, diseminarse, distribuir, o llevar
cualquier acción en confianza el contenido de esta información o
cualquier parte de eso y él puede ser ilegal hacer tan. Si usted
recibe este mensaje en error, notifique por favor el remitente
inmediatamente y suprima todas las copias de este mensaje de su
sistema. Las tecnologías de BrainStreet o el aprender de BrainStreet
son ni obligado para el apropiado y la transmisión completa de la
información contenida en esta comunicación ni cualquier retrasa en
su recibo.


Mensaje Original De: lac-discuss-bounces at atlarge-lists.icann.org
[ mailto:lac-discuss-bounces at atlarge-lists.icann.org ] On Behalf Of
carlos aguirre Sent: Tuesday, December 04,.2007 9:41 PM
: tema de lac-discuss at atlarge-lists.icann.org: Re: [ Laca-Discuta ]
Enhorabuena Vanda Scartezini

Fijando pautas para asegurar traducciones automáticas de los
email enviados a esta lista sea más exacto:
http://www.funredes.org/mistica/english/emec/method_emec/presentation.html#a
nexo1
- - - - -




Intercomprehension aid service 
 Check the rules for better use: http://funredes.org/tradauto/index.htm/rules 

Serviço do dae de compreensão 
 Verificar as réguas para o uso melhor: http://funredes.org/tradauto/index.htm/reguas 

Servicio de ayuda a la intercomprensión 
 Leer las reglas para un mejor uso: http://funredes.org/tradauto/index.htm/reglas