Solicitam-se comentários sobre a política para glue na zona de raiz do DNS
5 de dezembro de 2006
A Autoridade da Internet para Atribuição de Números (Internet Assigned Numbers Authority - IANA), uma função desempenhada pela ICANN em conformidade com suas obrigações estabelecidas por contrato com o governo dos EUA, é responsável pela delegação de domínios de primeiro nível na raiz do DNS.
A ICANN está revendo a forma como ela mantém informações sobre endereços IP na zona de raiz, prática mais conhecida como “glue”.
Histórico
Quando administra alterações na zona de raiz do DNS, cada operador de domínios de primeiro nível fornece à IANA uma lista de servidores de nomes oficiais, juntamente com os endereços IP, de modo que possam ser inseridos como dados glue na zona de raiz. O propósito desses dados glue está definido na RFC 1034, a partir da seção 4.2.1.
A representação de um endereço IP oficial (ou conjunto de endereços oficiais) de um servidor de nomes no DNS deve ser congruente entre o endereço IP especificado na zona oficial para aquele host e o endereço relacionado como glue. Incoerências entre os dados glue podem resultar numa instabilidade técnica do DNS.
A IANA se baseia no operador de domínio de primeiro nível para enviar os dados glue corretos juntamente com um pedido de alteração. Como parte de seus testes técnicos, a IANA garantirá que os novos endereços IP propostos passem pelos testes técnicos correspondentes. Assim que esses testes estiverem concluídos, os contatos administrativos e técnicos do domínio devem aprovar a mudança, e depois de aprovada, a IANA irá inserir ou alterar os dados glue na zona de raiz.
Em algumas circunstâncias, um servidor de nomes oficial é partilhado por mais de um domínio de primeiro nível. Nessas situações, se houver uma iniciativa para alterar os dados glue, a IANA assume uma posição conservadora, exigindo que TODOS os operadores de domínios de primeiro nível afetados consintam expressamente com a alteração.
Na prática, esse procedimento resultou em sérios obstáculos a algumas mudanças nos dados da zona de raiz. Alguns servidores de nomes oficiais são partilhados por mais de 30 domínios diferentes de primeiro nível. Mudanças em seus dados glue exigiriam a aprovação expressa pelo contato administrativo e pelo contato técnico de cada um desses domínios, o que possivelmente significa mais de 60 pessoas. Um único administrador de domínio desse grupo que não responder pode obstruir as mudanças, e na prática isso ocorreu em várias ocasiões. A equipe da IANA faz o melhor possível para resolver essas situações, que em geral resultam em meses de pesquisa e intervenções significativas.
Obrigação para com operadores de DPNs
O atual sistema de confirmação ativa tem como objetivo garantir que o operador de DPN esteja inteiramente ciente da renumeração de um dos seus servidores de nomes oficiais. Isso lhe oferece a oportunidade de identificar possíveis mudanças de configuração que ele precisa fazer para assegurar a continuidade do serviço. É provável que mudanças nessa função considerem o impacto sobre operadores de DPNs, e deixem clara qual é a obrigação da IANA em informar os DPNs sobre as mudanças que poderão afetá-los.
Abordagens possíveis
Algumas das possíveis abordagens consideradas são:
Manter o mesmo sistema. A IANA não considera isso desejável, mas a comunidade pode sentir que é conveniente manter o mesmo sistema.
Reduzir o limite para aceitação. Ao invés de exigir que cada contato técnico e administrativo aprove as mudanças, o limite poderia ser no mínimo os contatos técnicos e administrativos solicitantes, ou um número menor do que 100%. Como ilustração, um critério hipotético poderia ser: "As mudanças devem ser aprovadas pelos contatos técnicos e administrativos de dois operadores de DPNs afetados, ou de 20% dos operadores de DPNs afetados – o número que for maior".
Permitir mudanças com um período obrigatório de consideração e espera. Uma vez que os critérios de aceitação tenham sido cumpridos, se as mudanças não forem aceitas por 100% das partes afetadas, a ICANN pode notificar os contatos técnicos e administrativos sobre a natureza da mudança e conceder-lhes um prazo fixo (p. ex., 30 dias) para fazer as alterações necessárias antes que a zona de raiz passe pelas mudanças.
Incluir operadores de servidores de nomes como participantes do processo. As mudanças são solicitadas e coordenadas com os contatos técnicos e administrativos de um domínio. Eles não são necessariamente as mesmas partes que operam os servidores de nomes oficiais de um domínio. No entanto, esses operadores podem autorizar mudanças, embora essa abordagem seja um desvio radical das atuais operações e exija um procedimento novo para definir as normas e responsabilidades desses operadores, além dos procedimentos da IANA para autenticar essas partes.
Essa lista não é exaustiva, e a IANA gostaria de receber sugestões de qualquer solução viável. Daremos atenção especial a soluções automatizáveis, alinhadas com a atividade da IANA que procura automatizar os processos de mudanças da rotina na zona de raiz do DNS.
Perguntas para orientação
1. Como a IANA deve aceitar pedidos de mudanças em glue de zona de raiz? (seja de modo geral, ou específico para glue compartilhado)
2. Quais devem ser os critérios para aprovar mudanças em zonas de raiz compartilhadas?
3. Se uma parte afetada contestar uma mudança, como resolver esse conflito e com base no que seria possível efetuar uma mudança ainda assim?
4. A renumeração de um servidor de nomes compartilhado poderia causar outras conseqüências não-intencionais que não foram consideradas?
Comentários sobre as perguntas acima ou sobre o assunto em geral podem ser enviados por e-mail para root-glue-comments@icann.org. Os comentários estarão disponíveis em http://forum.icann.org/lists/root-glue-comments.
O período para comentários ficará aberto até 31 de janeiro de 2007. No final desse período para comentários, a equipe elaborará um relatório sobre os comentários e recomendará um procedimento operacional.
Referências
· No momento, a IETF está elaborando um documento que procura esclarecer problemas técnicos com dados glue. Esse documento está em fase de elaboração, mas pode ser útil nessa discussão. A versão atual está disponível em http://www.ietf.org/internet-drafts/draft-koch-dns-glue-clarifications-02.txt.
Última modificação
deste arquivo em 5 de dezembro de 2006 |