A missão e os valores centrais da ICANN exigem que a ICANN preserve e melhore a estabilidade operacional, a confiabilidade, a segurança e a interoperabilidade global do sistema de identificadores exclusivos da Internet (nomes, números de IP e parâmetros de protocolo). Para cumprir essas metas e seguir a orientação de sua Diretoria, além de levar em consideração os conselhos do Comitê Consultivo de Segurança e Estabilidade, a ICANN encomendou um estudo sobre os possíveis impactos das cadeias de caracteres solicitadas de novos gTLDs na segurança. O estudo tinha como objetivo considerar se as colisões de nomes poderiam ocorrer entre as cadeias de caracteres solicitadas de novos gTLDs e os nomes de domínios que podem estar sendo usados em espaços de nome privados ("TLDs não delegados"). O estudo também tinha como objetivo revisar a possibilidade de ocorrências de colisões de nomes decorrentes do uso de nomes internos para os quais foram emitidos certificados digitais X.509.
Uma colisão de nomes ocorre quando os usuários inadvertidamente acessam um nome que foi delegado no DNS público, quando a intenção do usuário era acessar um recurso identificado pelo mesmo nome em uma rede privada. Circunstâncias como essa, em que os limites administrativos de nomes de espaços privados e públicos se sobrepõe e a resolução de nomes produz resultados involuntários, apresentam preocupações e devem ser evitadas, se possível. Entretanto, as ocorrências de colisões em si não são a preocupação, mas sim se essas colisões causam danos ou comportamentos inesperados, a natureza do dano ou do comportamento inesperado e a gravidade da consequência.
Em 5 de agosto de 2013, a ICANN publicou e disponibilizou um estudo sobre colisão de nomes <http://www.icann.org/en/about/staff/security/ssr/name-collision-02aug13-en.pdf> [PDF, 3,34 MB] (o "Estudo") que identifica categorias de cadeias de caracteres de acordo com as ocorrências de consultas, conforme observado nas amostras de logs de servidores raiz obtidas com a iniciativa "Day in the Life of the Internet" (DITL – "Dia na Vida da Internet") da DNS-OARC. O Estudo usou como dados de entrada: 1) amostras de solicitações de DNS transmitidas aos servidores raiz (obtidas com a iniciativa DITL), complementadas por 2) informações de Autoridades de Certificação com relação à emissão de certificados de nomes internos (por exemplo, certificados de TLS/SSL para nomes não delegados). Uma descrição completa da metodologia do Estudo pode ser encontrada na seção 3.4 do Estudo.
O Estudo também incluiu opções para mitigar riscos. Contudo, ele não contém recomendações específicas para cada uma das categorias. Com base no Study, a equipe da ICANN publicou para comentários públicos, de 5 de agosto a 17 de setembro de 2013 <http://www.icann.org/en/about/staff/security/ssr/new-gtld-collision-mitigation-05aug13-en.pdf> [PDF, 166 KB] uma proposta para gerenciar o risco de colisão de nomes.
Em 7 de outubro de 2013, o Comitê do Programa de Novos gTLDs da Diretoria da ICANN adotou uma proposta revisada <http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-07oct13-en.htm#1.a> que descreve um plano para gerenciar ocorrências de colisão de nomes entre novos gTLDs e usos privados existentes de cadeias de caracteres iguais.
Seguem abaixo perguntas frequentes feitas sobre o plano e as respostas da ICANN.
-
Como a ICANN reuniu a lista de SLDs (Second-Level Domain Names, Nomes de Domínio de Segundo Nível) a serem bloqueados para o Caminho Alternativo de Delegação?
Para cada TLD, sua lista de SLDs a serem bloqueados é composta pelos SLDs consultados para o TLD durante as amostras da DITL de 2006 a 2013 e os conjuntos de dados lançados de DNSSEC em 2010.
-
Que critérios foram usados para considerar um novo gTLD não qualificado para o Caminho Alternativo de Delegação?
Esses novos gTLDs que exibiram um comportamento discrepante em termos de adições à sua lista de SLDs consultados a cada ano foram considerados não qualificados. Em outras palavras, a ICANN considera um novo TLD não qualificado para o Caminho Alternativo de Delegação nos casos em que a lista de SLDs altera de maneira frequente e abrangente.
As fontes de dados usadas para compilar a variação nas listas de SLDs são compostas por capturas anuais dos dados de consulta de DNS de 2006 a 2012. O conjunto de dados de 2013 não foi incluído, uma vez que as cadeias de caracteres já eram conhecidas (e várias atividades ou estudos realizados com as cadeias de caracteres conhecidas podem influenciar qualquer análise). Para essas cadeias de caracteres, o aumento a cada ano do número de SLDs consultados é um valor discrepante quando comparado à população de gTLDs propostos em: (a) pelo menos uma das comparações anuais e (b) 2012 (indica que há a ocorrência de rotação).
Por exemplo, um TLD que é um valor discrepante somente nas comparações de 2006-2007, ainda será considerado qualificado. No entanto, um TLD que é um valor discrepante nas comparações de 2009-2010 e de 2011-2012, não será qualificado para o caminho alternativo de delegação.
-
A lista de bloqueio de SLDs (Second-Level Domain Names, Nomes de Domínio de Segundo Nível) será corrigida em decorrência do uso de outros conjuntos de dados durante o trabalho na Estrutura de Gerenciamento de Ocorrências de Colisões de Nomes?
Não há planos para corrigir a lista de bloqueio de SLDs para novos gTLDs em decorrência do desenvolvimento da Estrutura. Contudo, caso haja uma nova descoberta durante o desenvolvimento da Estrutura, ela será levada em consideração.
-
O código fonte de criação das listas de bloqueio está disponível?
O processo para criar a lista de bloqueio é explicado em detalhes em cada relatório do Caminho Alternativo de Delegação de cada novo gTLD com contrato assinado e considerado como qualificado. Para ver um exemplo, acesse http://www.icann.org/en/about/agreements/registries/luxury/luxury-apd-report-12nov13-en.htm
O código usado para criar as listas é baseado no código publicado em https://github.com/JASdevteam/dns-oarc
-
Qual é a duração do bloqueio dos SLDs incluídos na lista de bloqueio?
O bloqueio estará em vigor até serem aplicadas as medidas de mitigação descritas na Avaliação de Ocorrência de Colisão de Nomes respectiva.
-
No caso de um TLD em particular, se o SLD "nic" aparecer nos dados da DITL (indicando que pode haver uma colisão de nomes), por que "nic" é permitido no gTLD, e por que esse risco é mais aceitável do que o risco de qualquer outra colisão de nomes?
O único nome cujo uso é exigido por contrato é "whois.nic.<tld>", a fim de oferecer o serviço de WHOIS de registro, ou seja, "whois.nic.<tld>". Considerando o risco de usar esse nome e a facilidade de utilização ao disponibilizar o serviço de WHOIS em um local conhecido, a ICANN decidiu não incluir "nic" na lista de SLDs a serem bloqueados por qualquer novo gTLD. Entretanto, o mecanismo de resposta para colisão de nomes <http://www.icann.org/pt/help/name-collision> está disponível, caso uma parte afetada deseja usá-lo para relatar um dano significativo causado por um determinado nome de domínio. É interessante observar também que o nome está disponível apenas para o operador do registro em si, o que significa que o registro tem o controle total do SLD.
-
A ICANN atualizará a lista de SLDs bloqueados a fim de incluir o ano em que os nomes foram consultados?
A ICANN não pretende atualizar a lista de SLDs bloqueados nem adicionar o ano em que os SLDs foram consultados? No entanto, se a comunidade demonstrar interesse nisso, a ICANN levará em consideração adicionar esses dados quando os recursos estiverem disponíveis.
-
O que será feito com os nomes na lista de bloqueio de SLD quando forem lançados no que diz respeito ao Período Experimental do TMCH (Trademark Clearinghouse, Centro de Informações de Marcas) e às Reivindicações?
Os nomes na lista de bloqueio de SLD de um TLD devem ser incluídos no Período Experimental e nas Reivindicações, sujeitos às políticas praticadas pelo registro, mas não podem ser ativados até as medidas de mitigação serem implementadas. Se um operador de registro alocar nomes na lista de bloqueio de SLDs durante o Período Experimental ou o período de Reivindicações, ele deverá informar ao registrante que o nome não poderá ser ativado e poderá nunca ser ativado, estando sujeito à Avaliação de Ocorrência de Colisão de Nomes do TLD.
Esse esclarecimento refere-se ao texto na seção 3.2 do Plano de Gerenciamento de Ocorrência de Colisão de Nomes. A intenção da lista de bloqueios é impedir o comportamento antes de um novo gTLD ser delegado (ou seja, uma resposta NXDOMAIN no DNS); esse resultado é obtido pela não ativação dos nomes na lista, independentemente da alocação.
-
O que constitui um dano que resulta na desativação de um nome de domínio de segundo nível responsável por colisões?
É possível que as ocorrências de colisões de nomes de alguns nomes de segundo nível não tenham aparecido no conjunto de dados usados para a lista de bloqueio de SLD após o início da operação de gTLDs solicitados. Para mitigar esse risco, a ICANN implementou um processo para permitir a uma parte afetada comunicar isso e solicitar o bloqueio temporário de um nome de domínio ativado recentemente que esteja causando sérios danos demonstráveis em decorrência de uma colisão de nomes.
A ICANN atuará como o ponto de contato inicial único nesses casos e coordenará a notificação ao operador de registro relevante a fim de garantir que esse problema seja resolvido de maneira rápida. A avaliação do dano será realizada inicialmente pela ICANN de acordo com cada caso até que o trabalho na Estrutura defina critérios uniformes.
-
Haverá algum portal dedicado à colisão de nomes?
A ICANN está planejando um portal que exibirá as informações disponíveis sobre esse tópico.
-
Os diferentes tipos de delegações experimentais estão incluídos no escopo da Estrutura de Gerenciamento de Ocorrência de Colisão de Nomes?
Sim, as delegações experimentais, tanto no nível de TLD (para os TLDs não qualificados para o caminho alternativo de delegação) quanto no segundo nível para SLDs de todos os novos gTLDs, serão consideradas durante o desenvolvimento da Estrutura. Caso seja adotada, espera-se que a Estrutura especifique a delegação experimental aplicável para um determinado tipo de colisão.
Além disso, durante seu encontro em Buenos Aires, a Diretoria da ICANN aprovou uma resolução que orienta a equipe a avaliar as recomendações do SAC 062 do SSAC (Security and Stability Advisory Committee, Comitê Consultivo de Segurança e Estabilidade), que solicitam explicitamente que a ICANN considere as delegações experimentais.
-
Qual é o processo para considerar o trabalho sendo realizado no desenvolvimento de uma Estrutura de Gerenciamento de Ocorrências de Colisões de Nomes e decidir se ela será adotada?
O fornecedor principal deverá trabalhar em uma Estrutura preliminar em cooperação com a comunidade, conforme explicado em <http://www.icann.org/pt/news/announcements/announcement-2-11nov13-pt.htm>. Depois disso, a Estrutura preliminar será disponibilizada para comentários públicos. Após o término do período de comentários públicos, os comentários serão resumidos e a Estrutura preliminar será atualizada com base nas informações fornecidas nesse período. Por último, o Comitê do Programa de Novos gTLDs da Diretoria da ICANN considerará a adoção da Estrutura final.
-
Como as pessoas podem participar no desenvolvimento da Estrutura de Gerenciamento de Ocorrências de Colisões de Nomes?
A participação de todos é bem-vinda no desenvolvimento da Estrutura. A Estrutura será discutida na lista de e-mails pública em <https://lists.dns-oarc.net/mailman/listinfo/collisions>.
-
O gerenciamento de colisões de nomes se estenderá aos ccTLDs?
A questão de colisões de nomes foi relatada primeiramente à ICANN com relação ao Programa de Novos gTLDs. Considerando o número esperado de novos gTLDs, a prioridade de trabalho foi dedicada aos novos gTLDs. Reconhecemos que esse assunto não é limitado aos gTLDs. Sendo assim, a ICANN está levantando essa questão com o Comitê de Riscos da Diretoria a fim de identificar um modo para resolver esse problema.