|
|
Mensagem do Comitê Consultivo para Segurança e Estabilidade à Diretoria da ICANN 22 de setembro de 2003 |
|
|
Recomendações referentes à introdução do serviço de wildcard (coringas) pela VeriSign em resposta a domínios sem correspondência em COM e NET Comitê Consultivo da ICANN para Segurança e Estabilidade HISTÓRICO Em 15 de setembro de 2003, a VeriSign mudou a maneira pela qual seus servidores de nomes COM e NET respondem a uma busca por um nome de domínio em COM ou NET para o qual não existem dados no servidor de nomes [1]. Essa mudança havia sido noticiada em 5 [2] e 9 [3] de setembro de 2003, mas as implicações da mudança não foram amplamente reconhecidas até que ela fosse colocada em prática. Antes disso, essas buscas resultavam na resposta RCODE 3 ("erro de nome"), a resposta negativa definida na especificação do protocolo oficial do DNS, RFC1035 [4]. Agora a VeriSign envia um endereço IP para um servidor especial, dando assim a impressão de que o nome de domínio solicitado existe. O servidor especial trata os pedidos subseqüentes por serviços de níveis de aplicativos, p. ex., web, e-mail, etc. No momento, esse servidor especial atende a pedidos de transações de HTTP (Internet) na porta 80 e SMTP (e-mail) na porta 25. O servidor envia um AGE (attempt to generalize - tentativa de generalização) indicando que o nome de domínio não está registrado, e oferece serviços de busca e/ou registração. Originalmente, o servidor de e-mail recusava todos os e-mails com um código de erro 550, que indica um erro permanente e que fazia a mensagem voltar para o remetente. O seu comportamento exato ainda está sujeito a mudanças em resposta à reação da comunidade, essencialmente mudando a maneira pela qual os e-mails são organizados em fila, roteados e respondidos nos domínios COM e NET. Os aplicativos ou protocolos que antes se baseavam numa resposta RCODE 3 para um domínio não-existente foram afetados por essa mudança de comportamento em COM e NET. Tanto no nível de roteamento quanto do DNS, elaboraram-se dispositivos para interromper o efeito desses wildcards, e esses dispositivos são mais uma fonte de instabilidade em potencial. PROBLEMAS DE SEGURANÇA E ESTABILIDADE O Comitê Consultivo para Segurança e Estabilidade está examinando a situação sob vários pontos de vista.
Com o objetivo de obtermos informações a respeito das implicações sobre a segurança e a estabilidade, solicitamos sugestões e comentários de todas as partes interessadas. Favor enviar as contribuições para: Além disso, realizaremos um encontro público em Washington, D.C. em 7 de outubro de 2003, para que as partes interessadas apresentem as informações factuais relevantes para a segurança e a estabilidade da Internet. Os detalhes estarão disponíveis em breve. Embora continuemos solicitando contribuições, já temos informações suficientes para apoiar as seguintes opiniões e recomendações:
A mudança da VeriSign parece ter enfraquecido consideravelmente a estabilidade da Internet, tendo introduzido respostas ambíguas e imprecisas no DNS, e provocou uma reação em cadeia crescente de medidas e contra-medidas que contribuem ainda mais com a instabilidade. A mudança da VeriSign interferiu significativamente com alguns dos serviços existentes que dependem da operação precisa, estável e confiável do sistema de nomes de domínio.
A ação da VeriSign resultou em uma grande variedade de respostas de ISPs, vendedores de software e outras partes interessadas, todos interessados em diminuir os efeitos da mudança. O resultado final dessa séria de mudanças e contra-medidas aumenta a complexidade e reduz a estabilidade do sistema de nomes de domínio como um todo e dos aplicativos que o utilizam. Essa seqüência conduz para a direção exatamente contrária. Sempre que possível, um sistema deve ser simples e fácil de entender, com suas camadas estruturais claramente separadas. Nós observamos que algumas redes e aplicativos estavam realizando serviços semelhantes antes da alteração da VeriSign. Na verdade, alguns aplicativos e serviços de usuários funcionavam de maneira diferente, dependendo da rede que o usuário estava usando. Entretanto, a mudança da VeriSign coloca este serviço em uma camada muito mais baixa na "pilha" de protocolos e numa posição muito mas baixa na infraestrutura da Internet global, o que impede o usuário de escolher qual serviço deseja usar e como proceder no caso de uma busca a um domínio inexistente.
Reconhecendo as preocupações sobre o serviço de wildcard, solicitamos que a VeriSign suspenda voluntariamente o serviço e participe dos diversos processos de análise em curso. Solicitamos que ICANN examine os procedimentos para mudanças em serviços, incluindo as disposições para proteger os usuários contra alterações bruscas no serviço. Solicitamos que a IAB, a IETF e a comunidade operacional examinem as especificações para o sistema de nomes de domínio e verifiquem se especificações adicionais poderiam melhorar a estabilidade do sistema geral. Acima de tudo, solicitamos recomendações definitivas sobre o uso de operação de nomes coringa em TLDs e no domínio-raiz, de modo que as ações e expectativas se tornem universais. Em relação às questões estruturais mais amplas, solicitamos que a comunidade técnica esclareça o papel das respostas de erros e particularmente a separação de camadas arquitetônicas e sua interação com a segurança e estabilidade. [1] Anúncio da mudança pela VeriSign [2] Relatório do Wall Street Journal sobre a mudança da VeriSign [3] Relatório do New York Times sobre a mudança da VeriSign [4] RFC1035, Nomes de Domínio -- Implementação e especificação Comentários sobre o layout, estrutura e funcionalidade
deste site Página atualizada em 22 de setembro de 2003 |
||
