Skip to main content
Resources

Política de transição de .COM, .NET e .JOBS para o WHOIS Thick

Esta página também está disponível em:

Por favor, observe que a versão em inglês de todo o conteúdo e dos documentos traduzidos são versões oficiais e que as traduções em outras línguas são apenas para fins de informar.

Notícias

Em 7 de novembro de 2019, a Diretoria da ICANN aprovou uma resolução para adiar a aplicação da conformidade contratual. A equipe de conformidade contratual da ICANN adiará a aplicação da Política de Transição do WHOIS Thick até que aconteça o seguinte:

  • a equipe de revisão de implementação (IRT) da política de dados de registro de gTLDs conclua sua análise e estabeleça um cronograma estimado de implementação das recomendações da Equipe do Processo de Desenvolvimento de Políticas Acelerado (EPDP) conforme adotadas pela Diretoria da ICANN em 15 de maio de 2019;
  • a organização da ICANN e a IRT forneçam ao Conselho da GNSO as informações necessárias sobre os impactos das recomendações da Equipe do EPDP sobre as políticas e os procedimentos existentes (incluindo a política de transição do WHOIS Thick), e
  • o Conselho da GNSO decida se tomará medidas em relação à atualização das políticas e dos procedimentos relevantes (que poderiam incluir mais trabalho de política, orientação ou outras ações a definir) que afetem a Política de Transição do WHOIS Thick.

As palavras-chave "DEVE", "NÃO DEVE", "OBRIGATÓRIO", "FARÁ", "NÃO FARÁ", "RECOMENDADO" e "PODE" neste documento devem ser interpretadas conforme o RFC 2119, disponível em http://www.ietf.org/rfc/rfc2119.txt.

Escopo:

Esta Política se aplicará aos Operadores de Registro dos gTLDs .COM, .NET e .JOBS, bem como aos Registradores responsáveis pelos registros de nomes de domínio nos gTLDs .COM, .NET e .JOBS.

Definições:

    • Thin (registro): nome de domínio para o qual o Operador de Registro mantém e fornece apenas informações técnicas (por exemplo, servidores de nome, status, data de criação) e o registrador responsável associado. As informações de contato do nome de domínio são mantidas pelo registrador responsável.
    • Thick (registro): nome de domínio para o qual o Registrador responsável fornece ao Operador de Registro uma cópia das informações de contato associadas. O Operador de Registro mantém as informações técnicas (por exemplo, servidores de nome, status, data de criação) e o registrador responsável associado ao nome de domínio. As informações de contato do nome de domínio são mantidas pelo registrador responsável.
    • Nome de domínio existente: nome de domínio criado ou com status pendingCreate antes de 1° de maio de 2018.
    • Métricas de andamento da transição: métricas criadas pelo Operador de Registro e comunicadas regularmente aos Registradores e à ICANN para permitir a avaliação do andamento da transição de Thin para Thick, incluindo pelo menos o número total de domínios gerenciados pelo Registrador, o número e a porcentagem de domínios com objetos de contato vinculados.

Política e datas de vigência:

3.1 Todos os novos registros de nomes de domínio DEVEM ser enviados como Thick a mais tardar a partir de 1° de maio de 2018.

3.2 Todos os dados de registro relevantes dos nomes de domínio existentes DEVEM ser migrados de Thin para Thick até 1° de fevereiro de 2019.

Os seguintes requisitos se aplicam apenas a Operadores de Registro:

4.1 O Operador de Registro DEVE implementar um mecanismo de EPP e um mecanismo alternativo de transferência em lotes até 1° de agosto de 2017 para que os registradores migrem os dados de registro dos nomes de domínio existentes (ou seja, a transição de Thin para Thick).

4.2 Até 1° de maio de 2017, o Operador de Registro DEVE fornecer aos Registradores aplicáveis e à ICANN a documentação refletindo as alterações no sistema necessárias para cumprir os requisitos da Seção 4.1.

4.3 Até 1° de maio de 2017, o Operador de Registro DEVE implementar um mecanismo de EPP e um mecanismo alternativo de transferência em lotes nos ambientes de teste operacional para que os registradores testem a migração dos dados de registro dos nomes de domínio existentes (ou seja, a transição de Thin para Thick).

4.4 Até 1° de agosto de 2017, o Operador de Registro DEVE aceitar todos os comandos de contato especificados no RFC5733, conforme descrito nesta cláusula. Os campos de contato do EPP <contact:id>, <contact:postalInfo type> e <contact:authInfo> são OBRIGATÓRIOS para o Operador de Registro. Até 1° de fevereiro de 2019, o Operador de Registro DEVE aceitar, mas NÃO DEVE exigir todos os outros elementos de dados de registro que permitam a conformidade com os requisitos para WHOIS (disponíveis pela porta 43) e serviços de diretório baseados na Web, descritos na Seção 1 da Especificação 4 do "Contrato Básico de Registro aprovado em 9 de janeiro de 2014" ("Contrato Básico de Registro") ou emendas subsequentes e na Política de rotulagem e exibição consistentes de serviços de diretório de registros.

4.5 A partir de 1° de maio de 2018, o Operador de Registro DEVE exigir dados de registro Thick para um comando <create> de objeto de domínio EPP, conforme descrito nesta cláusula. O Operador de Registro DEVE exigir todos os outros elementos de dados de registro que permitam a conformidade com os requisitos para WHOIS (disponíveis pela porta 43) e serviços de diretório baseados na Web, descritos na Seção 1 da Especificação 4 do "Contrato Básico de Registro aprovado em 9 de janeiro de 2014" ("Contrato Básico de Registro") ou emendas subsequentes e na Política de rotulagem e exibição consistentes de serviços de diretório de registros.

4.6 Entre 1° de agosto de 2017 e 1° de fevereiro de 2019, o Operador de Registro fornecerá Métricas de andamento da transição a cada registrador pelo menos uma vez por mês até as 23h59 UTC do primeiro dia do mês seguinte.

4.7 Entre 1° de agosto de 2017 e 1° de fevereiro de 2019, o Operador de Registro fornecerá à ICANN todas as métricas de andamento da transição de todos os registradores, pelo menos uma vez por mês até as 23h59 UTC do primeiro dia do mês seguinte.

4.8 O Operador de Registro PODE implementar os requisitos da Política de rotulagem e exibição consistentes de serviços de diretório de registros ("Política CL&D") em conjunto com a Seção 1 da Especificação 4 do "Contrato Básico de Registro aprovado em 9 de janeiro de 2014" ("Contrato Básico de Registro") ou emendas subsequentes até 1° de agosto de 2017.

4.9 O Operador de Registro DEVE cumprir os requisitos para WHOIS (disponíveis pela porta 43) e serviços de diretório baseados na Web descritos na Seção 1 da Especificação 4 do "Contrato Básico de Registro aprovado em 9 de janeiro de 2014" ("Contrato Básico de Registro") ou emendas subsequentes e na Política de rotulagem e exibição consistentes de serviços de diretório de registros até 1° de maio de 2018 para novos registros e até 1° de fevereiro de 2019 para nomes de domínio existentes.

4.10 Entre 1° de agosto de 2017 e 1° de fevereiro de 2019, para nomes de domínio existentes que tenham os seguintes campos de resultados de RDDS sem dados no SRS (Sistema de Registro Compartilhado, o Operador de Registro PODE tratar os seguintes campos do RDDS como Opcionais, conforme descrito no esclarecimento 1 do "Informe: esclarecimentos do contrato de registro e do contrato de credenciamento de registradores (RAA) 2013 em relação às especificações aplicáveis do serviço de diretório de dados de registro (WHOIS)".

    • ID do Registrante/Administrador/Técnico do Registro
    • Nome do Registrante/Administrador/Técnico
    • Endereço do Registrante/Administrador/Técnico
    • Cidade do Registrante/Administrador/Técnico
    • País do Registrante/Administrador/Técnico
    • Telefone do Registrante/Administrador/Técnico
    • E-mail do Registrante/Administrador/Técnico

4.11 A menos que seja exigido pelo Contrato de Registro, o contato de "Faturamento" é opcional. A Política de Registro pode definir se esse contato é obrigatório, opcional ou não é aceito. Se forem aceitas, as informações de contato de faturamento devem ser exibidas conforme as instruções do "Informe: esclarecimentos do contrato de registro e do contrato de credenciamento de registradores (RAA) 2013 em relação às especificações aplicáveis do serviço de diretório de dados de registro (WHOIS)" (seção 22).

Os seguintes requisitos se aplicam apenas a Registradores:

5.1 Entre 1° de agosto de 2017 e 1° de fevereiro de 2019, os Registradores DEVEM migrar para o Operador de Registro Relevante todos os campos obrigatórios dos Nomes de Domínio Existentes que estejam disponíveis no banco de dados do Registrador e que permitam que o Operador de Registro mantenha a conformidade com os requisitos para WHOIS (disponíveis pela porta 43) e serviços de diretório baseados na Web, descritos na Seção 1 da Especificação 4 do "Contrato Básico de Registro aprovado em 9 de janeiro de 2014" ("Contrato Básico de Registro") ou emendas subsequentes e na Política de rotulagem e exibição consistentes de serviços de diretório de registros.

5.2 Os Registradores PODEM fornecer ao Operador de Registro dados completos sobre o Registro Thick, que permitam a conformidade com os requisitos para WHOIS (disponíveis pela porta 43) e serviços de diretório baseados na Web, descritos na Seção 1 da Especificação 4 do "Contrato Básico de Registro aprovado em 9 de janeiro de 2014" ("Contrato Básico de Registro") ou emendas subsequentes e na Política de rotulagem e exibição consistentes de serviços de diretório de registros, em caso de criação de novos registros de nomes de domínio a partir de 1° de agosto de 2017.

5.3 Os Registradores PODEM fornecer ao Operador de Registro dados completos sobre o Registro Thick, que permitam a conformidade com os requisitos para WHOIS (disponíveis pela porta 43) e serviços de diretório baseados na Web, descritos na Seção 1 da Especificação 4 do "Contrato Básico de Registro aprovado em 9 de janeiro de 2014" ("Contrato Básico de Registro") ou emendas subsequentes e na Política de rotulagem e exibição consistentes de serviços de diretório de registros, em caso de criação de novos registros de nomes de domínio a partir de 1° de maio de 2018.

Observação sobre a Implementação

Se houver conflitos entre as leis locais relacionadas a privacidade e os requisitos desta Política, o procedimento da ICANN para lidar com conflitos de WHOIS com leis de privacidade está disponível para Operadores de Registro e Registradores

Histórico

A Diretoria adotou as recomendações de políticas consensuais do Grupo de Trabalho da GNSO sobre WHOIS Thick em relação ao uso de WHOIS Thick por todos os registros de gTLDs em 7 de fevereiro de 2014, depois que essas recomendações foram aprovadas pelo Conselho da GNSO. A Recomendação #1 diz que "A prestação de serviços de WHOIS Thick, com rotulagem e exibição consistentes, de acordo com o modelo definido na especificação três do [Contrato de Credenciamento de Registradores] de 2013, deve tornar-se um requisito para todos os registros de gTLDs, existentes e futuros". Veja as resoluções 2014.02.07.08 - 2014.02.07.09 da Diretoria da ICANN em http://www.icann.org/en/groups/board/documents/resolutions-07feb14-en.htm#2.c).

A ICANN trabalhou com uma equipe de membros da comunidade (a equipe de revisão de implementação) para implementar as recomendações de políticas. Durante a implementação e antes da adoção, a ICANN pediu comentários da comunidade sobre as recomendações de políticas propostas e o texto desta Política. (Consultehttps://www.icann.org/public-comments/proposed-implementation-gnso-thick-rdds-whois-transition-2016-10-26-en).

O Relatório Final [PDF, 1,23 MB] do Grupo de Trabalho do PDP de WHOIS Thick incluiu também, na Seção 7.2 ('Considerações sobre a implementação') orientações relacionadas ao cronograma e aos requisitos para a implementação da transição do WHOIS thin para o thick. O documento observa especificamente que "O Grupo de Trabalho destaca que a implementação de uma parte da recomendação (por exemplo, a transição dos registros de gTLD thin existentes para o modelo thick) não devem atrasar desnecessariamente a implementação de outra parte da recomendação (por exemplo, a rotulagem e exibição consistentes de tais dados)".

Como consequência, a organização da ICANN trabalhou com a equipe de revisão de implementação em caminhos de implementação paralelos para a transição de registros de WHOIS Thin para Thick com rotulagem e exibição consistente de dados de WHOIS. Para saber mais, consulte https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."