|
|
||
|
|
||
do
Comitê Consultivo para Segurança e Estabilidade
SAC 005
Documento 005 Versão 1
1 de novembro de 2003
Confirmação de vários servidores independentes
Um dos elementos-chave da infraestrutura do DNS é a delegação de zonas. Começando com a raiz do DNS ("."), cada administrador de zona tem autoridade para delegar subzonas às outras partes responsáveis. Cada subzona passa a ser outro ponto de delegação na árvore da infraestrutura do DNS. A operação correta da hierarquia de delegação é essencial para a estabilidade do DNS.
Existem duas exigências fundamentais para a operação correta da delegação. Primeiro, a zona hierarquicamente superior de uma subzona deve apontar para o(s) servidor(es) de subzona. Em segundo lugar, o(s) servidor(es) deve(m) estar em operação e ser confiável/confiáveis.
Extrapolando a partir de diversas especificações do DNS, para os fins dessa recomendação podemos definir "operação correta" como segue:
1. Uma zona hierarquicamente superior ("zona-mãe") é responsável por definir seus pontos de delegação (subzonas), assegurando a disponibilidade de um servidor para responder com as referências adequadas (registros NS) para essas subzonas, atualizando rapidamente as informações de referência a pedido da subzona "filha", e garantindo que a "filha" cumpra suas responsabilidades.
2. A zona-filha é responsável por garantir a disponibilidade de um servidor para responder a consultas a seu respeito e por garantir que sua zona-mãe mantenha atualizadas as informações de referência que administra em nome da zona-filha.
A primeira exigência é objetiva e não oferece margens a ambigüidades. Se houver uma informação incorreta na zona hierarquicamente superior de uma zona, a zona será inacessível e estará fora de serviço. Portanto, a "mãe" da zona deve ter as informações de referência corretas para a zona-filha. Toda vez que se realocar um servidor de zona para outro endereço, a zona-mãe deverá ser imediatamente atualizada.
A segunda exigência é menos definida. Em conformidade com recomendações passadas, recomendamos que cada zona opere pelo menos dois servidores independentes a fim de oferecer um alto grau de confiabilidade e disponibilidade. Essa recomendação se aplica sobretudo à raiz e aos domínios de alto nível, mas recomendamos também que zonas com um grande volume de consultas no DNS e/ou zonas que pretendem ser altamente disponíveis também operem dois ou mais servidores independentes.
Nem sempre é fácil determinar se um conjunto de servidores é independente entre si. Além de usar equipamentos diferentes, o ideal é que os servidores estejam em redes e locais físicos diferentes.
A infraestrutura do DNS pode ser definida por seus pontos de delegação. Começando com a raiz do DNS ('."), cada administrador de zona tem a autoridade de delegar subzonas a outras partes responsáveis. Cada subzona passa a ser outro ponto de delegação na árvore da infraestrutura do DNS. A operação correta da hierarquia de delegação é essencial para a estabilidade do DNS. Em geral, as buscas sobre nomes de domínio desconhecidos começam com uma pesquisa na raiz, em seguida pesquisando cada um dos pontos de delegação de acordo com as referências que recebem, e continuam até chegar ao servidor da zona com a informação desejada.
Uma das exigências necessárias para assegurar a operação correta da hierarquia de delegação é assegurar que a zona-mãe de uma outra zona tenha as informações de referência corretas para responder às buscas sobre a zona. Uma zona e sua "mãe" devem funcionar em conjunto para assegurar que a zona-mãe sempre tenha a informação de referência correta e esta deve atualizar rapidamente a informação de referência quando se lhe solicitar. Se uma zona-mãe responder a uma busca com informações de referência incorretas, os servidores da zona-filha estarão indisponíveis, exatamente como se não existissem.
Um segundo requisito necessário para assegurar a operação correta da hierarquia de delegação é assegurar a disponibilidade de um servidor em cada um dos pontos de delegação (pelo menos um servidor para cada zona). Se não houver um servidor disponível para uma zona, todos os aplicativos e serviços que dependem do DNS para localizar outros serviços de Internet naquela zona e todas as subzonas daquela zona não poderão realizar suas funções. Originalmente, o DNS deveria exigir pelo menos dois servidores independentes para cada zona, com mecanismos para sincronizar os dados entre aqueles servidores, justamente por esse motivo.
Extrapolando a partir das especificações do DNS (RFCs 1034, 1035 e modificações subseqüentes) e vários documentos sobre as operações do DNS (RFC 1591, em particular), para os fins dessa recomendação podemos definir "operação correta" como segue:
1. Uma zona-mãe é responsável por definir seus pontos de delegação (subzonas), assegurando a disponibilidade de um servidor para responder com as referências adequadas (registros NS) para aquelas subzonas, atualizando rapidamente as informações de referência a pedido da subzona-filha, e garantindo que "filha" cumpra suas responsabilidades.
2. A zona-filha é responsável por garantir a disponibilidade de um servidor para responder a consultas a seu respeito e por garantir que sua zona-mãe mantenha atualizadas as informações de referência que administra em nome da "filha".
O primeiro requisito para assegurar a operação correta da hierarquia de delegação é manter as informações de referência no ponto de delegação. Uma zona-mãe e uma zona-filha precisam cooperar a fim de garantir que a mãe possua a informação de referência correta para responder a consultas sobre a zona-filha.
A estabilidade da infraestrutura do DNS é diretamente afetada se uma zona-mãe ou zona-filha não tiver a informação de referência correta. Se uma "filha" deixar de atualizar sua "mãe" quando suas informações de referência mudam, a "filha" corre o risco de ser desligada da Internet. Como a "filha" é independente da "mãe" e a "filha" só é responsável pela sua zona, a "mãe" não pode ser responsabilizada se a "filha" for desconectada da Internet por ter deixado de informar sua "mãe" sobre uma mudança em suas informações de referência. Se for apropriado e necessário (com base em critérios que estão fora do escopo dessa recomendação), uma zona-mãe poderá optar por transferir a delegação de uma determinada subzona a fim de melhorar a sua disponibilidade.
Por outro lado, contudo, uma zona-filha pode não ter a opção de mudar de zona se a sua zona-mãe falhar ou preferir não cumprir sua responsabilidade de atualizar as informações de referência rapidamente quando se lhe solicitar. Em muitos casos, uma zona-filha pode ser obrigada ou restrita a uma "mãe" específica. A estabilidade da infraestrutura do DNS exige que a "mãe" atualize as informações de referência a pedido da "filha". Se isso não acontecer, a "filha" será desconectada da Internet. Conclui-se que, a menos que o objetivo da "mãe" seja desconectar a "filha" da Internet (por motivos que estão além do escopo dessa recomendação), a "mãe" deve sempre cumprir sua responsabilidade de atualizar as informações de referência. Em geral, a "filha" e a "mãe" devem ter um entendimento claro e inequívoco sobre os critérios que levarão uma "mãe" a se recusar a atualizar as informações de referência de uma "filha".
No que se refere à exigência de disponibilidade de um servidor para uma zona, essa recomendação se concentra em dois pontos: se dois servidores independentes serão sempre necessários e se a definição precisa da palavra "independente". Por exemplo, analisemos o caso de uma zona que não delega nenhuma subzona.
Se uma zona não possuir subzonas, então a única parte afetada por uma falha no servidor da zona é a própria zona. Sem subzonas, a hierarquia de delegação do DNS não é afetada pelo ponto de falha isolado representado pelo servidor único que atende aquela zona.
Por outro lado, uma zona que possibilita a delegação de subzonas para partes responsáveis distintas tem uma responsabilidade maior de assegurar que existe um servidor disponível, tendo em vista que o número de partes afetadas é diretamente proporcional ao número de subzonas. Neste caso, aplica-se a exigência de diversos servidores independentes.
Mais especificamente, neste contexto o termo "independente" se define como segue. Uma política operacional que aumenta a estabilidade da infraestrutura do DNS para zonas que delegam subzonas é aquela que determina pelo menos dois servidores para a zona e para a qual se aplica o seguinte:
1. Os servidores encontram-se em locais geograficamente distintos.
2. Os servidores estão conectados fisicamente à Internet por vias diferentes, o que significa que os seus provedores de rede para a velocidade do tráfego de dados são diferentes ou que
Mais sucintamente, uma zona-mãe deve garantir que os seus próprios servidores e os servidores para cada uma das suas zonas-filhas que também possuem zonas-filhas delegadas não estejam vinculados a um único ponto de falha. Esses pontos incluem o seguinte:
Confirmação de vários servidores independentes
Infelizmente, não existe um método completamente automático para determinar se uma zona utiliza vários servidores independentes. Existem várias verificações automáticas que podem ser usadas para fornecer uma resposta parcial a essa dúvida.
1. Existem pelo menos dois registros NS para a zona?
Mesmo que uma zona-mãe tenha uma cópia dessas informações para cada subzona que delegar, é importante garantir a exatidão das informações, consultando diretamente os servidores para a subzona e comparar as informações com as da zona-mãe.
Se a subzona não tiver dois registros NS, saberemos que não há independência. Embora uma zona tenha de ter dois registros NS para ser independente, a existência desses dois registros NS não é conclusiva.
2. Os endereços IP de pelo menos dois servidores NS estão em redes diferentes?
Se houver os registros NS, a próxima medida é consultar o DNS novamente para obter seus endereços IP e observar se eles estão na mesma rede ou não.
Se os endereços IP estiverem na mesma rede, saberemos que não há independência. Embora os endereços IP tenham de estar em redes diferentes para que haja independência, um endereço IP oferece apenas uma referência virtual à topologia da sua rede física, e portanto a presença de redes diferentes não é conclusiva.
3. Existem pelo menos dois endereços IP em Sistemas Autônomos (ASs) diferentes?
Se os endereços IP estiverem em ASs diferentes, saberemos que há independência na conectividade de rede. Entretanto, não é possível chegar a uma conclusão em relação à independência geográfica. Se os endereços IP não estiverem em ASs diferentes, não será possível chegar a nenhuma conclusão.
Não existe um método automático para determinar se existe independência geográfica. As checagens 1 e 2 devem ser positivas, mas além disso é necessário confirmar manualmente a localização física dos servidores em questão.
Se a checagem 3 for negativa, a única maneira de determinar se há independência na conectividade de rede é confirmar manualmente a configuração física dos servidores em questão e a rede à qual cada servidor está conectado fisicamente.
Resumo e recomendações
Mais especificamente, como tanto a zona de Raiz (".") quanto as zonas de Domínios de Alto Nível (TLDs) delegam subzonas a várias partes independentes, a operação correta dos seus servidores é essencial para a estabilidade da infraestrutura do DNS. Conforme descreve o texto acima, a expressão "operação correta" sugere as duas recomendações seguintes:
1. Os administradores de zona devem adotar uma política que garanta a atualização rápida das informações de referência quando se lhes solicitar.
2. Os administradores de zona devem adotar uma política que exija vários servidores independentes para sua zona quando eles delegam subzonas a mais de uma parte responsável.
Note-se que nem uma transferência de zona nem o acesso a um arquivo de zona são necessários ou suficientes para verificar a estabilidade da hierarquia de delegação no DNS.
Os membros do Comitê Consultivo para Segurança e Estabilidade prepararam este documento.
Alain Aina (Consultor)
Jaap Akkerhuis (SIDN)
Doug Barton (IANA)
Steve Bellovin (ATT)
Rob Blokzijl (RIPE)
David Conrad (Nominum)
Steve Crocker (Shinkuro), presidente
Johan Ihrén (Autonomica)
Mark Kosters (VeriSign)
Allison Mankin (Lucent Bell Labs)
Ram Mohan (Afilias)
Russ Mundy (SPARTA, Inc.)
Jun Murai (Universidade de Keio)
Frederico Neves (registro.br)
Ray Plzak (ARIN)
Doron Shikmoni (ForeScout)
Ken Silva (VeriSign)
Bruce Tonkin (Melbourne IT)
Paul Vixie (ISC)
Rick Wesson (Alice's Registry)
O comitê recebe suporte técnico de Jim Galvin (eList eXpress).
|
Última modificação deste arquivo
em 29 de dezembro de 2003 |