Skip to main content
Resources

Sobre o programa de conformidade de gTLDs

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

A seguinte visão geral do Programa de conformidade de gTLDs [PDF, 890 KB] serve apenas como guia. As partes contratadas sempre devem conhecer e cumprir todos os requisitos de seus contratos com a ICANN, bem como as políticas aplicáveis.

O programa de conformidade de gTLDs foi desenvolvido através da divisão das cláusulas contratuais do contrato de registro de gTLDs em áreas gerais de conformidade. Essas áreas são implementadas por meio de uma combinação de trabalho de monitoramento interno, processamento de denúncias e recursos externos, como notícias do setor. Um novo serviço ou uma mudança em protocolos ou políticas pode impulsionar maior monitoramento de conformidade em uma área.

Os contratos de registro de gTLDs têm uma estrutura básica comum, embora os requisitos específicos possam variar. A seguir, temos algumas áreas de conformidade de gTLDs e as cláusulas relevantes no contrato de registro de novos gTLDs. Os registros que não utilizam o formato do contrato de novos gTLDs podem ter requisitos diferentes. Para saber mais, acesse o contrato de registro específico de cada gTLD.

A ICANN não tem autoridade contratual para tomar medidas de conformidade contra operadores de ccTLDs.

Áreas de conformidade

  1. Especificações funcionais e de desempenho

    Especificações funcionais são como os sistemas técnicos de um registro funcionam, como DNS, EPP e RDDS. As especificações definem padrões de disponibilidade, interrupções, tempo de processamento e frequência de atualização. Para determinar a conformidade nessas áreas, a ICANN implementa o monitoramento técnico interno, quando disponível. Além disso, os relatórios mensais fornecidos pelos operadores de registro são usados para comparar os requisitos do contrato de nível de serviço com as medidas reais de desempenho obtidas pelo monitoramento interno no mês em questão.

    Algumas cláusulas relevantes são as especificações 6 e 10 do contrato de registro de novos gTLDs. As denúncias relacionadas aos requisitos do contrato de nível de serviço de um operador de registro podem ser enviadas por meio do formulário de denúncia de registro: https://www.icann.org/resources/pages/performance-2013-06-28-en.

  2. Serviço de diretório de dados de registro (WHOIS) e acesso ao WHOIS em massa

    Os registros que assinaram o contrato de registro de novos gTLDs devem fornecer um serviço público de WHOIS por meio da porta 43, além de um serviço de diretório baseado na Web contendo os elementos de dados necessários em um formato especificado. Eles também devem fornecer acesso aos dados de registro em massa (WHOIS) à ICANN semanalmente. A ICANN analisa se um registro está oferecendo o acesso adequado aos dados de WHOIS, apresentando esses dados de forma consistente, atendendo os requisitos de frequência e seguindo as cláusulas referentes ao acesso em massa.

    Algumas cláusulas relevantes são as especificações 4 e 10 do contrato de registro de novos gTLDs e as recomendações da ICANN: 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).

  3. Depósito de dados

    Todos os registros devem selecionar um agente de depósito de dados (DEA) aprovado pela ICANN para fornecer esse serviço. A conformidade analisa se foram feitos depósitos válidos pelo DEA e se o registro enviou notificações de depósito à ICANN.

    Algumas cláusulas relevantes são a especificação 2 do contrato de registro de novos gTLDs.

  4. Uso de dados do registrador

    Os registros que assinaram o contrato de registro de novos gTLDs devem tomar medidas razoáveis para proteger os dados de registro coletados dos registradores. Os registros devem informar aos registradores as maneiras como usam as informações e que podem não usá-las por motivos não informados. A conformidade analisa a comunicação do registro com os registradores em relação a suas práticas ao lidar com dados pessoais e denúncias de processos enviadas por meio dos formulários da ICANN.

    Algumas cláusulas relevantes são as seções 2.14 e 2.18, e a especificação 9 do contrato de registro de novos gTLDs.

  5. Acesso equivalente a serviços de registro e código de conduta

    Essa área inclui a obrigação dos registros que assinaram o contrato de registro de novos gTLDs de oferecer acesso equivalente e igualitário a todos os registradores, além de usar um contrato uniforme e igualitário com todos os registradores. Além disso, se um registro também funcionar como provedor de serviços de registrador ou revendedor de registrador, é necessário conduzir análises internas de acordo com o Código de Conduta e fornecer os resultados dessas análises com um certificado de conformidade registrado à ICANN (se não houver isenção). A ICANN monitora essas cláusulas por meio do processamento de denúncias e de recursos externos, além de analisar as certificações anuais necessárias.

    Algumas cláusulas relevantes são a seção 2.9a e as especificações 9 e 13 (quando aplicável) do contrato de registro de novos gTLDs. As denúncias relacionadas aos requisitos do Código de Conduta podem ser enviadas usando o Formulário de denúncias do código de conduta, que pode ser encontrado em: https://www.icann.org/resources/pages/code-of-conduct-2014-01-29-en.

  6. Restrições de registro

    Alguns gTLDs são restritos por políticas de registro ou, no caso de gTLDs patrocinados, pelas restrições de seu regulamento (Apêndice S). Por exemplo, os gTLDs de uma comunidade devem seguir as restrições de registro relacionadas a essa comunidade. Registros restritos têm políticas de disputas que fornecem padrões para a resolução de disputas relacionadas a registros inapropriados.

    Por meio do RRDRP (procedimento de resolução de disputas de restrição de registros) a ICANN permite o envio de um relatório inicial alegando que um registro que assinou o contrato de registro de novos gTLDs não está em conformidade com suas restrições obrigatórias de registro, conforme disposto na Especificação 12 do seu contrato de registro. A ICANN também garante que o registro disponibilize os mecanismos adequados de resolução de disputas para os registrantes.

    Algumas cláusulas relevantes são a seção 2.19 e a especificação 12 do contrato de registro de novos gTLDs. As denúncias relacionadas às restrições de registro da Especificação 12 de um operador de registro podem ser enviadas usando o formulário do procedimento de resolução de disputas de restrição de registros, que pode ser encontrado em: https://www.icann.org/resources/pages/rrdrp-2013-10-31-en.

  7. Serviços de período experimental e reivindicações

    Os registros que assinaram o contrato de registro de novos gTLDs e seus registradores contratados devem trabalhar com o Centro de Informações de Marcas (TMCH) para fornecer serviços de período experimental e reivindicações. Esses serviços são mecanismos de proteção de direitos para proprietários de marcas inscritas no TMCH. Os serviços de período experimental permitem aos proprietários de marcas uma oportunidade de registrar os nomes de domínio correspondentes a suas marcas antes que esses nomes sejam disponibilizados ao público em geral. Durante o período dos serviços de reivindicação, os registradores devem fornecer uma notificação de reivindicação de marca registrada a qualquer pessoa que tente registrar um nome de domínio inscrito no TMCH. Caso a parte notificada registre o nome de domínio, o TMCH informará esse registro ao proprietário da marca.

    A ICANN aceita denúncias relacionadas a violações dos serviços de reivindicação e de período experimental depois que as reparações da política de resolução de disputas relacionada ao período experimental (SDRP) do registro forem esgotadas.

    Algumas cláusulas relevantes são a especificação 7 do contrato de registro de novos gTLDs e os requisitos do mecanismo de proteção de direitos do Centro de Informações de Marcas. Depois do esgotamento de uma SDRP, as denúncias podem ser enviadas usando o formulário de informação de procedimentos e processos do período experimental, que pode ser encontrado aqui: https://www.icann.org/resources/pages/sdrp-2013-10-31-en. As denúncias relacionadas aos requisitos dos serviços de reivindicação de um operador de registro podem ser enviadas usando o formulário de serviços de reivindicação, aqui: https://www.icann.org/resources/pages/claims-2014-01-29-en.

  8. Nomes reservados

    Todos os registros devem reservar os nomes especificados pelo contrato de registro. Para determinar a conformidade, a ICANN realiza um monitoramento técnico interno e resolve as denúncias externas. Os registros que assinaram o contrato de registro de novos gTLDs podem ativar até 100 nomes (inclusive suas variantes de IDN, se for o caso) necessários para a operação ou a promoção do gTLD. Não há restrições numéricas sobre o número de nomes que um registro pode reservar no gTLD, contanto que todos os outros requisitos do contrato de registro sejam atendidos.

    Algumas cláusulas relevantes são o apêndice 6 e a especificação 5 do contrato de registro de novos gTLDs. As denúncias relacionadas aos nomes reservados de um operador de registro ou a SLDs bloqueados podem ser enviadas usando o formulário de denúncia de SLDs reservados e bloqueados, aqui: https://www.icann.org/resources/pages/reserved-2013-06-28-en.

  9. Colisão de nomes

    Dependendo da data de delegação de cada gTLD (antes, em ou depois de 18 de agosto de 2014, à 0h UTC), os registros que assinaram o contrato de registro de novos gTLDs devem (1) bloquear a lista de domínios de segundo nível (SLDs) para bloquear ou implementar a interrupção controlada (CI) ou a CI com curinga por pelo menos 90 dias antes de ativar tais nomes ou (2) implementar a CI com curinga por pelo menos 90 dias antes de ativar qualquer nome dentro do TLD. A ICANN monitora e controla o tempo da implementação da CI principalmente usando os arquivos de zona transferidos à ICANN depois da delegação. As outras obrigações do registro continuam enquanto a CI estiver implementada (por exemplo, as Extensões de Segurança do Sistema de Nomes de Domínio, o fornecimento de serviços de RDDS em whois.nic.tld).

    Algumas cláusulas relevantes são a especificação 6 do contrato de registro de novos gTLDs, a estrutura de gerenciamento da ocorrência de colisão de nomes e documentos relacionados.

  10. Acesso de terceiros aos arquivos de zona

    Todos os registros devem dar acesso a terceiros a seu arquivo de zona. O contrato de arquivo de zona do registro deve ter o formato especificado no contrato de registro ou de patrocínio e, se for o caso, incluir seu uso no CZDS (serviço de dados de zona centralizado). A ICANN verificará se um registro alterou o contrato ou impôs mais condições através da análise dos contratos do arquivo de zona do registro e do processamento de denúncias de terceiros que usam o CZDS para ter acesso ao arquivo de zona.

    Algumas cláusulas relevantes são os termos e condições do CZDS e a especificação 4 do contrato de registro de novos gTLDs. É possível enviar denúncias relacionadas ao fornecimento de acesso ao arquivo de zona por um operador de registro a terceiros usando o formulário de denúncia de acesso ao arquivo de zona, aqui: https://www.icann.org/resources/pages/zfa-2013-06-28-en.

  11. Dados de contato de abuso

    Os registros que assinaram o contrato de registro de novos gTLDs devem fornecer à ICANN e publicar em seus sites um endereço de e-mail válido, um endereço físico válido e um contato principal para lidar com consultas relacionadas a abuso ou conduta mal-intencionada no gTLD. A ICANN analisará o site do registro para determinar se os contatos necessários foram publicados.

    Uma das cláusulas relevantes é a especificação 6 do contrato de registro de novos gTLDs. As denúncias relacionadas aos dados de contato de abuso de um operador de registro podem ser enviadas por meio do formulário de denúncia de dados de contato de abuso, aqui: https://www.icann.org/resources/pages/abuse-contact-2014-01-29-en.

  12. Compromissos de interesse público

    Os registros que assinaram o contrato de registro de novos gTLDs devem ter certos compromissos de interesse público obrigatórios e voluntários (se for o caso). Alguns compromissos obrigatórios são ter certas cláusulas no contrato registro-registrador (RRA) e conduzir análises técnicas periódicas. Essas obrigações podem ser aplicadas por meio do processo de resolução de disputas de compromisso de interesse público (PICDRP). A ICANN monitora a conformidade com esses requisitos por meio do processamento de denúncias e com recursos externos.

    Algumas cláusulas relevantes são a especificação 11 do contrato de registro de novos gTLDs e o PICDRP. É possível enviar uma denúncia relacionada à PICDRP por meio do formulário da PICDRP, aqui: https://www.icann.org/resources/pages/picdrp-2013-10-31-en.

  13. Sistema de Suspensão Rápida Uniforme (URS)

    Por meio do Procedimento de URS, a ICANN oferece um caminho mais rápido e econômico para uma resolução a proprietários de direitos que enfrentem casos evidentes de violação ocasionados por registros de nomes de domínio. A função da ICANN é garantir que os registros que assinaram o novo contrato de registro de novos gTLDs atendam aos requisitos do procedimento de URS durante e depois do processamento de uma denúncia de URS por um provedor de URS.

    Algumas cláusulas relevantes são os requisitos técnicos de alto nível de URS para registros e registradores, o procedimento de URS, e as regras e a especificação 7 do contrato de registro de novos gTLDs. É possível enviar uma denúncia de URS relacionada à não implementação de uma decisão de URS por um operador de registro usando o formulário de URS, que pode ser encontrado em: https://www.icann.org/resources/pages/urs-2013-10-31-en.

  14. Proibição de curingas

    Os registros que tenham assinado o contrato de registro de novos gTLDs estão proibidos de usar registros de recursos curinga do DNS, qualquer método para sintetizar registros de recursos do DNS ou usar o redirecionamento em todos os níveis dentro do DNS para nomes de domínio que não são registrados ou se não foram fornecidos registros de NS válidos. Quando consultados por esses nomes de domínio, os servidores de nomes autorizados devem retornar uma resposta "Erro de nome" (também conhecida como NXDOMAIN), RCODE 3, conforme descrito no RFC 1035 e RFCs relacionados. Para determinar a conformidade, a ICANN realiza um monitoramento técnico interno. Uma isenção temporária dessa proibição é concedida nos termos da avaliação de ocorrência de colisão de nomes.

    Uma das cláusulas relevantes é a especificação 6 do contrato de registro de novos gTLDs. As denúncias relacionadas à proibição de curinga de um operador de registro podem ser enviadas por meio do formulário de denúncia de proibição de curinga (redirecionamento de domínio), aqui: https://www.icann.org/resources/pages/wildcard-prohibition-2014-01-29-en.

  15. Pagamentos à ICANN

    Todos os registros devem pagar taxas à ICANN. Os dados sobre registros de pagamento podem ser disponibilizados pela contabilidade da ICANN. Os avisos e as notificações sobre pagamentos em atraso que estão em uso atualmente são integrados ao programa de conformidade, em coordenação com a equipe de contabilidade.

    Uma das cláusulas relevantes é o artigo 6 do contrato de registro de novos gTLDs.

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."