Detalhes
| Ref. Nome: AFPUB-2017-DNS-001-DRAFT-01 |
Versões: 1.0 Status: em discussão Itens obsoletos: CPM 3.0 - O desenvolvimento de políticas (PDP) |
Autor:
|
| Submetido: 11 de Abril de 2017 |
Histórico de Revisão
| 2017-03-15: Primeiro draft |
Proposta
1. Resumo do problema tratado nesta proposta
1.1. Contexto: O que é "Lame Delegation"?
No DNS, uma delegação lame é um tipo de erro de configuração incorreta do DNS que ocorre quando um servidor de nomes designado como servidor autoritativo para um nome de domínio não retorna dados autoritativos para esse nome, quando consultado. Por exemplo, se for delegada a um servidor de nomes a responsabilidade de fornecer um serviço de nomes para uma zona (por meio de registros NS) e não estiver realmente fazendo isso, ou seja, o servidor de nomes não está configurado como servidor primário nem secundário ou não responde, então o registro NS é considerado 'coxo' (RFC1912 [2]).
1.2. Impacto de Lame Delegations no DNS Global
Nas zonas in-addr.arpa e ip6.arpa, conforme aplicável a esta política, os registros DNS considerados são registros NS (como no exemplo acima), delegando autoridade mais abaixo na cadeia de autoridade. Com tal delegação resultando em respostas coxas, o problema mais óbvio é a falha completa da subzona específica .ARPA à qual está sendo delegada. Isso é semelhante a não ter nenhuma delegação em vigor: o subconjunto de registros .ARPA não pode ser encontrado e, portanto, as pesquisas reversas de DNS falharão para esse conjunto de recursos de endereço IP. Sem delegação, a falha é imediata e final. O cliente de consulta para uma zona específica obterá uma resposta negativa do servidor de nomes da zona pai e não fará mais pesquisas.
Mas comparando a uma delegação coxo, o cliente recebe uma referência ao (s) servidor (es) de nomes coxo (e inválido ou quebrado). Em seguida, ele deve procurá-los pelo nome antes de consultar um ou mais para o registro originalmente solicitado. Se o primeiro servidor de nomes do conjunto falhar, o cliente pode tentar o restante, um por um, se todos forem coxos.
Em alguns casos, a claudicação é o resultado de falta de autoridade ou registros ausentes, mas em outros o servidor de nomes coxo não existe ou não responde. Nesses casos, o cliente também precisa aguardar o tempo limite da solicitação antes de tentar o NS alternativo ou falhar completamente.
Em resumo, as delegações de servidor de nomes lame em comparação com nenhuma delegação resultam em tráfego DNS adicional e um tempo muito maior para responder para o cliente, com o mesmo resultado final prático. Além disso, as zonas pai de nível superior que contêm esses registros NS inúteis e efetivamente inválidos são desnecessariamente maiores do que o necessário. Também existe um impacto potencial em quaisquer dados estatísticos retirados das zonas principais.
2. Resumo de como esta proposta aborda o problema
2.1. Resumo
Esta política apresenta um processo para monitorar os registros do servidor de nomes responsáveis por delegações lame e uma abordagem em fases para remover esses registros do DNS.
2.2. Escopo da Política
Esta política deve ser aplicada apenas às zonas DNS em in-addr.arpa e ip6.arpa gerenciadas pela AFRINIC. As verificações devem ser feitas para cada registro NS como originado de objetos de "domínio" no AFRINIC WHOIS base de dados.
Mais especificamente, esta política é aplicável apenas a delegações de DNS reverso gerenciadas na região AFRINIC para maioria AFRINIC RIR Alocações e atribuições de IP.
Esta política não deve monitorar ou considerar delegações reversas de DNS para minorias RIR Recursos de endereço IP ou recursos de endereço IP herdados.
3. Proposta
3.1. Detalhe do Processo
O seguinte texto será adicionado ao Manual de Política Consolidado:
10.7 Processo para Lame Delegations
10.7.1 Monitoramento / Verificação
Todos os objetos de "domínio" no AFRINIC WHOIS o banco de dados deve ser examinado periodicamente e todos os atributos "nserver" extraídos para verificação. Cada "nserver" encontrado deve ser verificado para:
- Responda a consultas de DNS.
- Responda com um registro SOA válido para o domínio associado com no WHOIS base de dados.
Essa verificação periódica deve ser automatizada. As verificações devem ser relativamente frequentes, mas não tão frequentes a ponto de causar qualquer impacto operacional nos sistemas AFRINIC ou no DNS global. Se um servidor de nomes falhar na verificação pela primeira vez, isso será inicialmente apenas registrado. Somente após falhar em várias verificações de claudicação, um servidor de nomes deve ser sinalizado para ação futura.
10.7.2 Notificação
Depois que um ou mais servidores de nomes forem sinalizados como lame, uma tentativa razoável deve ser feita para contatar a (s) pessoa (s) responsável (is) pelo objeto "domínio" e pela delegação DNS.
Todos os contatos "admin-c", "tech-c" e "zone-c" devem ser tentados em paralelo.
Além disso, as informações de contato podem ser extraídas dos atributos associados "org" e / ou "mnt-by" quando apropriado.
Comunicações de notificação não respondidas também devem ser tentadas novamente mais de uma vez antes de prosseguir para outras ações.
A frequência de comunicação, método (s) de comunicação e número de tentativas devem ser padronizados e publicamente documentados.
10.7.3 Remoção de Delegação
Uma vez que um determinado servidor de nomes tenha sido considerado coxo para um determinado "domínio" DNS, e tentativas razoáveis tenham sido feitas para contatar uma pessoa responsável, o servidor de nomes deve então ser removido do "domínio" DNS dado.
O servidor de nomes não deve ser removido de todos WHOIS objetos e zonas DNS, uma vez que pode não ser uniformemente lame para outras zonas que atende.
Apenas os servidores de nomes marcados como lame devem ser removidos de um determinado domínio. O domínio não deve ter todos os atributos "nserver" removidos.
Essas remoções devem ser automatizadas. Uma linha opcional de "comentários" pode ser adicionada ao registro de "domínio" no banco de dados.
Caso um determinado domínio tenha todos os seus servidores de nomes identificados como coxos e, portanto, removidos, ele também deve ser removido do banco de dados, devido ao atributo "nserver" ser obrigatório para os objetos "domínio".
As informações históricas sobre os servidores de nomes e objetos de domínio removidos devem ser arquivadas por um período de tempo razoável e disponibilizadas ao membro para fins informativos.
10.7.4 Reinstalação
Depois que os servidores de nomes forem corrigidos ou servidores de nomes alternativos estiverem disponíveis para uma determinada zona DNS reversa, a (s) pessoa (s) responsável (is) adicionaria (m) delegação a eles da mesma maneira que uma nova delegação é feita para uma nova atribuição ou alocação de IP.
3.2 Possível (s) Impacto (s) Operacional (is)
Uma delegação DNS de uma zona-filha por registros NS lame na zona-pai resultará em falha parcial ou total da zona-filha.
Portanto, remover esses registros coxos do pai não terá mais efeitos adversos na zona filho.
No caso de falha parcial, em que nem todos os servidores de nomes são considerados coxos, o impacto será positivo: a remoção de delegações com falha resultará em nenhuma falha de DNS, em vez de parcial.
3.3 Exemplo de diretriz de operações de implementação
Os autores estão cientes de que haveria um trabalho significativo a ser feito para implementar esta política. Eles trabalharam em uma diretriz para implementação, caso a política seja aprovada.
Um exemplo de manual operacional está disponível online [9] como uma diretriz para uso da equipe da AFRINIC. A entrada e o texto são bem-vindos, mas observe que este é um exemplo para implementação e não faz parte da política.
4. Histórico de Revisões
2017-03-15: Primeiro draft
5. Referências
5.1 Políticas semelhantes em outras regiões
- ARIN: Política 2002-1: Delegações Lame em IN-ADDR.ARPA [4]
- APNIC: prop-038: Emendando a política de delegação reversa de DNS lame do APNIC [5]
- LACNIC: Política de Lame Delegation na Região de LACNIC [6]
- RIPE NCC: Nenhuma política conhecida no momento.
5.2 Estudos de configuração incorreta de DNS
- Delegação deficiente no banco de dados AFRINIC: quão fracas são nossas delegações reversas? [7]
- Erros de configuração incorreta de DNS: impacto dos erros de configuração na robustez do DNS [8]
5.3 URI's
[1]https://www.rfc-editor.org/rfc/rfc2119.txt
[2]https://www.ietf.org/rfc/rfc1912.txt
[4]https://www.arin.net/policy/proposals/2002_1.html
[5]https://www.apnic.net/community/policy/proposals/prop-038/
[6]http://www.lacnic.net/en/web/lacnic/manual-6
[7]http://afrinic.net/blog/165-how-lame-are-our-reverse-delegations
[8]http://web.cs.ucla.edu/~lixia/papers/09DNSConfig.pdf
5.4 Glossário
- DNS: Sistema de Nome de Domínio
- RIR: Registro regional da Internet
- Maioria RIR: Contém a alocação pai da IANA.
- Minoria RIR: Administra o espaço dentro da alocação majoritária.
- Recursos legados da Internet: recursos de números da Internet obtidos antes ou fora do sistema de registro hierárquico da Internet atual.
- Registro SOA: registro "Start Of Authority", no cabeçalho de cada zona DNS.
Avaliação da equipe
*** Avaliação da equipe ***
| Proposta | AFPUB-2017-DNS-001-DRAFT-01 |
| Título | Delegações coxas no DNS reverso AFRINIC |
| URL | |
| Avaliadas | 15 de maio de 2017 |
1.0 Entendimento da proposta pela equipe
-
A proposta tem como objetivo mitigar ou eliminar as delegações lame rdns do DNS associadas aos recursos emitidos (ou gerenciados administrativamente) pela AFRINIC.
-
A proposta estabelece um processo para monitorar os registros NS responsáveis por delegações coxas e uma abordagem em fases para remover esses registros do DNS.
-
É uma atualização (ou aprimoramento) do processo atual de rDNS descrito no Manual de Política Consolidado (Seção 10)
2.0 Comentários da equipe:
- O espaço de DNS reverso delegado de recursos AFRINIC IP é de aproximadamente 44% LAME de acordo com os dados analisados de http://ftp.afrinic.net/pub/zones/ em 12 2017 Maio.
- A proposta precisa declarar explicitamente que o AFRINIC não considerará os registros de recursos "minoritários" recebidos de outros RIRs, visto que esses registros são externos à AFRINIC e estão além do nosso controle.
- A proposta deve indicar explicitamente se os detentores de recursos legados estão incluídos / excluídos / afetados e como.
- Em relação às notificações - os autores devem permitir que o AFRINIC determine quem pode ser notificado e que processo usar. A expressão "comunicações não respondidas" também pode ser alterada para se referir à falta de resolução do problema após algum tempo, pois pode acontecer de uma comunicação ser atendida sem que o problema seja resolvido.
- Sobre a cláusula 10.7.4 - esta cláusula parece desnecessária.
3.0 Comentários do Consultor Jurídico:
- Nenhum observado
4.0 Implementação:
4.1 Cronograma e Impacto
O desenvolvimento e teste (de software) exigirá aproximadamente dois meses.
4.2 Requisitos de implementação
As seguintes ações são necessárias para implementar esta política conforme escrito:
- Implementar as verificações de "claudicação" automatizadas.
- Atualizar regras de negócios (internas) para executar verificações antes da criação / atualização do domínio.
- Automatização de notificações enviadas para contatos de registros associados a delegações coxas conforme especificado em 10.7.2, bem como relatórios mensais de delegação coxo e relatórios semestrais de limpeza de delegação coxo.
- Ferramenta pública de verificação de claudicação.
- Arquivo de objetos em WHOIS (desenvolvimento adicional também é necessário para exibir objetos arquivados em MyAFRINIC).
- Automatização de remoção de delegações coxas conforme especificado em 10.7.3
- Automação de reintegrações conforme especificado em 10.7.4
- Documentação (e publicação obrigatória) do processo detalhando como a frequência / tentativas de comunicação e método (s) serão implementados.
